From nobody Tue May 2 00:18:13 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C3A12EC0A for ; Tue, 2 May 2017 00:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 qSvoTCh3aRN9 for ; Tue, 2 May 2017 00:18:09 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB3A912E05D for ; Tue, 2 May 2017 00:13:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ak6zlRehlVU1bu0hhNi6HsI56sx8CMiC+HAOaQjms6U=; b=FgVt7bb6B6MP1qKxwIoTO4YWYg2SIbYtRt0rUk/KAhbDYLuHc44iuSar0KNdz52Q1cZa2o0gC6KIlcGxOy/JEBdj6VuQ8du4UECBUmXgjc7KCRVvAPlav6By73iGLUHR+/WudIec9tPXE0Prb2ICu1LDlNIXUvg3BX19HqLKxT0= Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0055.outbound.protection.outlook.com [207.46.163.55]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-112-dIuUF6hRNk68x6MvFO01zg-1; Tue, 02 May 2017 03:13:01 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Tue, 2 May 2017 07:12:59 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1061.021; Tue, 2 May 2017 07:12:59 +0000 From: "Asveren, Tolga" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Thread-Index: AQHSwAW/bFONqGwgCkelI/jotUkR9KHgWM/g Date: Tue, 2 May 2017 07:12:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:BCNkB+QlUBKvlLwH41I4x64gDgyyISr/5wcW8ZOo+SaBJM8rUZOv9Ru4LdSIeNNFZG1wt+eEJn/MFJ1nw4r0+cM3y6CpoYxxE4ZQit9l2fC2t8k2NaXd721f7wIDxb27alqElQnfUUOrEdMuKuTN3R7x8XsmdPSFvMX0260Tbsn98Snxcu//x02kdu5bn8heFkej3MBSsYl93z835ZiInBCfzazV6TnTDbMMWYF+06HKZsyjHT15vP9DqOepVrTOcSSfUEq4UrZ7FGWyRz6DDdm9g/Q1EcvH8Ho5ynmJpduKwTW/8e/Y+GUFxCuepePlLwziXm6ZFIuzFUtcX4apog==; 20:wnglcB7EpGt+b+nx7QDI5Q4hQo7JjVRDgdHCAUkTPQUgj7k2O6LZ5tr4FmoEFZ8EAsUqhkSe2zFAn2oJgmWAFB3ODhQqqjvj8bWup8AxKs3VbRit3/BDjKf8Ru+lVhUP4WbUfKNyx8C9HkDAB9b8Rv/efIldBiI6knhvWVmaODM= x-ms-office365-filtering-correlation-id: 2761d494-18b3-451b-fe23-08d4912aaa40 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR03MB2349; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39400400002)(39450400003)(39830400002)(377454003)(8676002)(81166006)(53936002)(6436002)(38730400002)(6246003)(7696004)(8936002)(15650500001)(2906002)(10710500007)(189998001)(229853002)(2420400007)(66066001)(5660300001)(7110500001)(3280700002)(54896002)(6306002)(9686003)(6506006)(53546009)(3660700001)(99286003)(55016002)(25786009)(7736002)(77096006)(478600001)(3846002)(54356999)(74316002)(122556002)(50986999)(76176999)(86362001)(790700001)(6116002)(102836003)(2950100002)(2501003)(33656002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2017 07:12:59.5251 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 X-MC-Unique: dIuUF6hRNk68x6MvFO01zg-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350112A538A7075C4C4399DB2170SN2PR03MB2350namp_" Archived-At: Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 07:18:12 -0000 --_000_SN2PR03MB2350112A538A7075C4C4399DB2170SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable i- "rtcp-mux-exclusive" is a new capability/indication, not an update on RF= C5761/8035 per se. ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional. iii- rtcp-mux-exclusive is defined as bidirectional. Adding all these together, I fail to see the rationale behind the text. Therefore, I think "4) Do Nothing" is the way to go here. OTOH, I still think that draft-mux-exclusive explicitly should indicate tha= t "rtcp-mux-exclusive itself is bidirectional" and that RFC8035 updated RFC= 5761 to clarify that "rtcp-mux is birectional". Thanks, Tolga From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Friday, April 28, 2017 5:57 AM To: mmusic@ietf.org Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also u= pdates section 5.1.1 of RFC 8035. draft-mux-exclusive keeps the existing text, and adds some new (= ). Update to 4th paragraph of section 5.1.1 OLD TEXT (RFC 5761): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. NEW TEXT (RFC 8035): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. As we can see, the original text is identical in 5761 and 8035. So, there i= s no clash. So far so good. draft-mux-exclusive keeps the existing text, and adds some new (= ). NEW TEXT (draft-mux-exclusive): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signaled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. However, if the offerer indicated in the offer that it = is not able to send and receive RTCP on a separate port, the offerer MUST disable the media streams associated with the attribute. The mechanism for indicating that the offerer is not able to send and receive RTCP on a separate port is outside the scope of this specification. Now, the issue is that, following the update in RFC 8035, the text is no lo= nger within the 4th paragraph of section 5.1.1. So, should we: 1) within draft-mux-exclusive, indicate that both RFC 5761 and RFC 803= 5 are updated; or 2) within draft-mux-exclusive, add a note indicating which paragraph i= s affected following the update in RFC 8035 3) within draft-mux-exclusive, ONLY update RFC 8035; or 4) o nothing My first reaction would be to go for option 2), as there IMO is no reason t= o formally update the text in RFC 8035. Regards, Christer --_000_SN2PR03MB2350112A538A7075C4C4399DB2170SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

i- “rtcp-mux-exclusive” is a new capabil= ity/indication, not an update on RFC5761/8035 per se.

ii- RFC8035 updates RFC5761 so that rtcp-mux is used= only as bidirectional.

iii- rtcp-mux-exclusive is defined as bidirectional.=

 

Adding all these together, I fail to see the rationa= le behind the <new></new> text. Therefore, I think “4) Do= Nothing” is the way to go here.

 

OTOH, I still think that draft-mux-exclusive explici= tly should indicate that “rtcp-mux-exclusive itself is bidirectional&= #8221; and that RFC8035 updated RFC5761 to clarify that “rtcp-mux is = birectional”.

 

Thanks,

Tolga

 

From: mmusic [mailto:mmusic-bounces@ietf.org]= On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: mmusic@ietf.org
Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and R= FC 8035

 

Hi,
draft-mu=
x-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also updates s=
ection 5.1.1 of RFC 8035.
draft-mux-exclusive keeps the existing text, and a=
dds some new (<new></new>).
 <=
/o:p>
Update to=
 4th paragraph of section 5.1.1
 
 
OLD TEXT (RFC 5761):

 


   If the answer does not contai=
n an "a=3Drtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


NEW TEXT (RF=
C 8035):


  =
 If the answer does not contain an "a=3Drtcp-mux" attribute, the =
offerer


   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


As we can se=
e, the original text is identical in 5761 and 8035. So, there is no clash. =
So far so good.


draft-mux-ex=
clusive keeps the existing text, and adds some new (<new></new>=
).


 <=
/o:p>


NEW TEXT (draft-mux-exclusive):


 


   If the answer does not contain an "a=3Drtcp-mux"=
; attribute, the offerer


   MUST NOT multiplex RTP and RTCP packets on a single port.=
  Instead,


   it should send and receive RTCP on a port allocated accor=
ding to the


   usual port-selection rules (either the port pair, or a si=
gnaled port


   if the "a=3Drtcp:" attribute [10] is also inclu=
ded).  This will occur


   when talking to a peer that does not understand the "=
;a=3Drtcp-mux"


   attribute. <new> However,=
 if the offerer indicated in the offer that it is


   not able to send and receive RT=
CP on a separate port, the offerer


   MUST disable the media streams =
associated with the attribute. The


   mechanism for indicating that t=
he offerer is not able to send and


   receive RTCP on a separate port=
 is outside the scope of this


   specification.</new>




 






Now, the issue is that, following the upda=
te in RFC 8035, the text is no longer within the 4th paragraph of section 5=
.1.1. So, should we:






 






1) &nb=
sp;    within draft-mux-exclusive, indicate that both=
 RFC 5761 and RFC 8035 are updated; or






2)  &n=
bsp;   within draft-mux-exclusive, add a note indicating w=
hich paragraph is affected following the update in RFC 8035






3) &nb=
sp;    within draft-mux-exclusive, ONLY update RFC 80=
35; or






4) &nb=
sp;    o nothing






 






My first reaction would be to go for optio=
n 2), as there IMO is no reason to formally update the text in RFC 8035. 






 






Regards,






 






Christer






 






 
--_000_SN2PR03MB2350112A538A7075C4C4399DB2170SN2PR03MB2350namp_-- From nobody Tue May 2 01:31:38 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE7D12EBB3 for ; Tue, 2 May 2017 01:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cQrKTP9AY7QP for ; Tue, 2 May 2017 01:31:34 -0700 (PDT) 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 8D65913146C for ; Tue, 2 May 2017 01:26:43 -0700 (PDT) X-AuditID: c1b4fb2d-eff839a00000196b-29-590842c1d5af Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 57.AB.06507.1C248095; Tue, 2 May 2017 10:26:41 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Tue, 2 May 2017 10:25:22 +0200 From: Christer Holmberg To: "Asveren, Tolga" , "mmusic@ietf.org" Thread-Topic: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Thread-Index: AQHSwAW/bFONqGwgCkelI/jotUkR9KHgWM/ggAB0kIA= Date: Tue, 2 May 2017 08:25:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D52E1C271BEEEchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7qO5BJ45Ig6t3FC2mLn/MYjG78z2T A5PHkiU/mTwuff7PHsAUxWWTkpqTWZZapG+XwJXR2aZW8H4KY8XaNQENjMcbGLsYOTkkBEwk th/7yNbFyMUhJHCEUeLkjP1QzmJGiZurG5i7GDk42AQsJLr/aYM0iAgESzxv+MEEYgsLuEks XzibDSLuLtGydDEjhG0l0fPxETtIK4uAisTjVY4gJq+AtUTbQyOQCiGBPkaJZRMUQWxOgViJ aWcnsYPYjAJiEt9PrQGbziwgLnHryXwmiDMFJJbsOc8MYYtKvHz8jxXEFhXQk9j37ysbRFxR YufZdmaI3gSJ3z0nwK7hFRCUODnzCcsERpFZSMbOQlI2C0kZRNxA4v25+cwQtrbEsoWvoWx9 iY1fzjJC2NYSRy7PZkJWs4CRYxWjaHFqcXFuupGxXmpRZnJxcX6eXl5qySZGYKwd3PJbdwfj 6teOhxgFOBiVeHgT7NkjhVgTy4orcw8xSnAwK4nwzmbliBTiTUmsrEotyo8vKs1JLT7EKM3B oiTO67DvQoSQQHpiSWp2ampBahFMlomDU6qBcdVf3rksL37WuDI/41/MfkTz8g0L9lO2Bbna nSeNHt798Wm5xI55rx47nHm0UkuYKW5vj8DDs2ymn9sWOx8t23cq4c7h8uMvxKddN/+uw18Q l5SopGtr9vaGEePNCyE31fnZ/c9NuyMlrL7s+a/FfLtDbTzWNhk2blturmdZ6nDJZf0y7zvG QkosxRmJhlrMRcWJADbTczKxAgAA Archived-At: Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 08:31:37 -0000 --_000_D52E1C271BEEEchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >i- =93rtcp-mux-exclusive=94 is a new capability/indication, not an update = on RFC5761/8035 per se. >ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional= . >iii- rtcp-mux-exclusive is defined as bidirectional. > >Adding all these together, I fail to see the rationale behind the text. Therefore, I think =934) Do Nothing=94 is the way to go here. Note that the text is already in draft-mux-exclusive, and optio= n 4) would not remove it. The issue is that, based on the update in RFC8035, the text is no longer wi= thin the =934th paragraph=94, as RFC8035 adds new paragraphs, and my questi= on is whether we should somehow point that out within draft-mux-exclusive. >OTOH, I still think that draft-mux-exclusive explicitly should indicate th= at =93rtcp-mux-exclusive itself is bidirectional=94 and that RFC8035 update= d RFC5761 to clarify that =93rtcp-mux is birectional=94. I think we should look at that suggestion (which, btw, I think seems reason= able) as a separate thing. THIS issue is more administrative. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Friday, April 28, 2017 5:57 AM To: mmusic@ietf.org Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also u= pdates section 5.1.1 of RFC 8035. draft-mux-exclusive keeps the existing text, and adds some new (= ). Update to 4th paragraph of section 5.1.1 OLD TEXT (RFC 5761): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. NEW TEXT (RFC 8035): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. As we can see, the original text is identical in 5761 and 8035. So, there i= s no clash. So far so good. draft-mux-exclusive keeps the existing text, and adds some new (= ). NEW TEXT (draft-mux-exclusive): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signaled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. However, if the offerer indicated in the offer that it = is not able to send and receive RTCP on a separate port, the offerer MUST disable the media streams associated with the attribute. The mechanism for indicating that the offerer is not able to send and receive RTCP on a separate port is outside the scope of this specification. Now, the issue is that, following the update in RFC 8035, the text is no lo= nger within the 4th paragraph of section 5.1.1. So, should we: 1) within draft-mux-exclusive, indicate that both RFC 5761 and RFC 803= 5 are updated; or 2) within draft-mux-exclusive, add a note indicating which paragraph i= s affected following the update in RFC 8035 3) within draft-mux-exclusive, ONLY update RFC 8035; or 4) o nothing My first reaction would be to go for option 2), as there IMO is no reason t= o formally update the text in RFC 8035. Regards, Christer --_000_D52E1C271BEEEchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5AA4AFC3111841429FF12B055C5229DA@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>i- =93rtcp-mux-exclusive=94 is a new capability/= indication, not an update on RFC5761/8035 per se.

>ii- RFC8035 updates RFC5761 so that rtcp-mux is = used only as bidirectional.

>iii- rtcp-mux-exclusive is defined as bidirectio= nal.

> 

>Adding all these together, I fail to see the rat= ionale behind the <new></new> text. Therefore, I think =934) Do= Nothing=94 is the way to go here.

 
Note that the <new></new> text is already in draft-mux-exc= lusive, and option 4) would not remove it. 

The issue is that, based on the update in RFC8035, the text is no long= er within the =934th paragraph=94, as RFC8035 adds new paragraphs, and my q= uestion is whether we should somehow point that out within draft-mux-exclus= ive.

>OTOH, I still think that draft-mux-exclusive exp= licitly should indicate that =93rtcp-mux-exclusive itself is bidirectional= =94 and that RFC8035 updated RFC5761 to clarify that =93rtcp-mux is birecti= onal=94.

I think we should look at that suggestion (which, btw, I think seems r= easonable) as a separate thing. THIS issue is more administrative.

Regards,

Christer

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: mmusic@ietf.org
Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and R= FC 8035

 

Hi,
draft-mu=
x-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also updates s=
ection 5.1.1 of RFC 8035.
draft-mux-exclusive keeps the existing text, and a=
dds some new (<new></new>).
 <=
/o:p>
Update to=
 4th paragraph of section 5.1.1
 
 
OLD TEXT (RFC 5761):

 


   If the answer does not contai=
n an "a=3Drtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


NEW TEXT (RF=
C 8035):


  =
 If the answer does not contain an "a=3Drtcp-mux" attribute, the =
offerer


   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


As we can se=
e, the original text is identical in 5761 and 8035. So, there is no clash. =
So far so good.


draft-mux-ex=
clusive keeps the existing text, and adds some new (<new></new>=
).


 <=
/o:p>


NEW TEXT (draft-mux-exclusive):


 


   If the answer does not contain an "a=3Drtcp-mux"=
; attribute, the offerer


   MUST NOT multiplex RTP and RTCP packets on a single port.=
  Instead,


   it should send and receive RTCP on a port allocated accor=
ding to the


   usual port-selection rules (either the port pair, or a si=
gnaled port


   if the "a=3Drtcp:" attribute [10] is also inclu=
ded).  This will occur


   when talking to a peer that does not understand the "=
;a=3Drtcp-mux"


   attribute. <new> However,=
 if the offerer indicated in the offer that it is


   not able to send and receive RT=
CP on a separate port, the offerer


   MUST disable the media streams =
associated with the attribute. The


   mechanism for indicating that t=
he offerer is not able to send and


   receive RTCP on a separate port=
 is outside the scope of this


   specification.</new>




 






Now, the issue is that, following the upda=
te in RFC 8035, the text is no longer within the 4th paragraph of section 5=
.1.1. So, should we:






 






1) &nb=
sp;    within draft-mux-exclusive, indicate that both=
 RFC 5761 and RFC 8035 are updated; or






2)  &n=
bsp;   within draft-mux-exclusive, add a note indicating w=
hich paragraph is affected following the update in RFC 8035






3) &nb=
sp;    within draft-mux-exclusive, ONLY update RFC 80=
35; or






4) &nb=
sp;    o nothing






 






My first reaction would be to go for optio=
n 2), as there IMO is no reason to formally update the text in RFC 8035. 






 






Regards,






 






Christer






 






 
--_000_D52E1C271BEEEchristerholmbergericssoncom_-- From nobody Tue May 2 03:54:22 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE781316A0 for ; Tue, 2 May 2017 03:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 awyluwEZ0QQK for ; Tue, 2 May 2017 03:54:18 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726A213151E for ; Tue, 2 May 2017 03:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IcN4gcjk3w1/2IdMV5qMtR6hVHcZkvGwz941p55a+NA=; b=p+qzCAMuPXGncG2hMLP+7LbzethKd9NB8TGlT/Cw4e4F8hURGyhd1d/ogejlF/mx7+WW2cP2mYx1jRKWKuZu2C1CVi3czy80kTpUPwk36qca/KKCtFBznPyaVsYQDkkBqtcWuOn3r2uzajG7TF+duiqaCsMhBAEVWLL9vhghvqk= Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0020.outbound.protection.outlook.com [216.32.181.20]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-116-993At5uNOmC1HxcZfGD0Zg-1; Tue, 02 May 2017 06:50:49 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Tue, 2 May 2017 10:50:46 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1061.021; Tue, 2 May 2017 10:50:46 +0000 From: "Asveren, Tolga" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Thread-Index: AQHSwAW/bFONqGwgCkelI/jotUkR9KHgWM/ggAB0kICAABMnMA== Date: Tue, 2 May 2017 10:50:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:TTf95Lvy2e0Q7qznJMrGIheb/FgpSwlCdeUkgFK/KJlJs0sp2tzASyBj7KftsoBdMXDNU380ABLazXptwiflKDUw5u7wYZkJ/CfLsJQWRiIOs61uzaeHygBqj2r08NQFGQYZ6kiyO20H+/K2crZbbOUkOKXtl0/1C4hleusH4lsG1rpX9SD6ENitEBslQgKOkfsly9kw+UbvPxS961SYlnaMKvPZf+UgeFku9MKWXFrpQdcQiJ8BV0i8ezX13HepEDMG7+HH+HajnUWB/chybgPIXTsY+AQvSokNvYuNLwKu/EDYry3tPJ0DDOgFqaSTUaDDoXD4oVVaVsedfcDmlQ==; 20:lyWpWJc7sL1cp3OPg4fRGMne5EKA1QFNe09z7bRMt/wjNnBN0KlDSAWbLkVbfnoooX43f2zeNyZEYnzNz4cXpakJQGXGtb3KlhdcmGu/7skzPVNx/MbowxsA4aQBpE7upZ1HyrcGwBmxbVxyl+a1dLCXFjnBuzA/98kDJKFHtCw= x-ms-office365-filtering-correlation-id: 268758bb-b970-429e-1087-08d4914916ab x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN2PR03MB2351; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(39410400002)(39400400002)(39450400003)(377454003)(74316002)(50986999)(2906002)(10710500007)(54896002)(33656002)(9686003)(2950100002)(6306002)(189998001)(38730400002)(76176999)(8676002)(7110500001)(53936002)(55016002)(478600001)(7696004)(6506006)(81166006)(229853002)(77096006)(54356999)(66066001)(86362001)(53546009)(236005)(6436002)(99286003)(6246003)(25786009)(6116002)(3846002)(122556002)(102836003)(2420400007)(8936002)(15650500001)(5660300001)(790700001)(7736002)(3660700001)(3280700002)(230783001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2017 10:50:46.2259 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 X-MC-Unique: 993At5uNOmC1HxcZfGD0Zg-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB235088D834727A40C9F387D8B2170SN2PR03MB2350namp_" Archived-At: Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 10:54:21 -0000 --_000_SN2PR03MB235088D834727A40C9F387D8B2170SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I got your point but that made me think about a more fundamental issue: Doe= s draft-mux-exclusive indeed update RFC5761? IMHO it is not. It defines a new indicator with its own semantics. This is = a new capability, not something changing a capability already defined. And = it seems "backward compatibility concerns" are already addressed in a reaso= nable way by mux-exclusive and RFC8035 updates on RFC5761. So, I would: i- Remove "Updates: RFC5761" statement from the prologue ii- Remove Section 5. If you still want to keep rtcp-mux-exclusive as an "update on RFC5761", the= n 2) sounds reasonable to me as well. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 4:25 AM To: Asveren, Tolga ; mmusic@ietf.org Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, >i- "rtcp-mux-exclusive" is a new capability/indication, not an update on R= FC5761/8035 per se. >ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional= . >iii- rtcp-mux-exclusive is defined as bidirectional. > >Adding all these together, I fail to see the rationale behind the text. Therefore, I think "4) Do Nothing" is the way to go here. Note that the text is already in draft-mux-exclusive, and optio= n 4) would not remove it. The issue is that, based on the update in RFC8035, the text is no longer wi= thin the "4th paragraph", as RFC8035 adds new paragraphs, and my question i= s whether we should somehow point that out within draft-mux-exclusive. >OTOH, I still think that draft-mux-exclusive explicitly should indicate th= at "rtcp-mux-exclusive itself is bidirectional" and that RFC8035 updated RF= C5761 to clarify that "rtcp-mux is birectional". I think we should look at that suggestion (which, btw, I think seems reason= able) as a separate thing. THIS issue is more administrative. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Friday, April 28, 2017 5:57 AM To: mmusic@ietf.org Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also u= pdates section 5.1.1 of RFC 8035. draft-mux-exclusive keeps the existing text, and adds some new (= ). Update to 4th paragraph of section 5.1.1 OLD TEXT (RFC 5761): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. NEW TEXT (RFC 8035): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. As we can see, the original text is identical in 5761 and 8035. So, there i= s no clash. So far so good. draft-mux-exclusive keeps the existing text, and adds some new (= ). NEW TEXT (draft-mux-exclusive): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signaled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. However, if the offerer indicated in the offer that it = is not able to send and receive RTCP on a separate port, the offerer MUST disable the media streams associated with the attribute. The mechanism for indicating that the offerer is not able to send and receive RTCP on a separate port is outside the scope of this specification. Now, the issue is that, following the update in RFC 8035, the text is no lo= nger within the 4th paragraph of section 5.1.1. So, should we: 1) within draft-mux-exclusive, indicate that both RFC 5761 and RFC 803= 5 are updated; or 2) within draft-mux-exclusive, add a note indicating which paragraph i= s affected following the update in RFC 8035 3) within draft-mux-exclusive, ONLY update RFC 8035; or 4) o nothing My first reaction would be to go for option 2), as there IMO is no reason t= o formally update the text in RFC 8035. Regards, Christer --_000_SN2PR03MB235088D834727A40C9F387D8B2170SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

I got your point but that made me think about a more= fundamental issue: Does draft-mux-exclusive indeed update RFC5761?

IMHO it is not. It defines a new indicator with its = own semantics. This is a new capability, not something changing a capabilit= y already defined. And it seems “backward compatibility concerns̶= 1; are already addressed in a reasonable way by mux-exclusive and RFC8035 updates on RFC5761.

 

So, I would:

i- Remove “Updates: RFC5761” statement f= rom the prologue

ii- Remove Section 5.

 

If you still want to keep rtcp-mux-exclusive as an &= #8220;update on RFC5761”, then 2) sounds reasonable to me as well.

 

Thanks,

Tolga

 

From: Christer Holmberg [mailto:christer.holm= berg@ericsson.com]
Sent: Tuesday, May 2, 2017 4:25 AM
To: Asveren, Tolga <tasveren@sonusnet.com>; mmusic@ietf.org Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 80= 35

 

Hi,

&n= bsp;

>i- “rtcp-mux-e= xclusive” is a new capability/indication, not an update on RFC5761/80= 35 per se.

>ii- RFC8035 updates = RFC5761 so that rtcp-mux is used only as bidirectional.

>iii- rtcp-mux-exclus= ive is defined as bidirectional.

> 

>Adding all these tog= ether, I fail to see the rationale behind the <new></new> text.= Therefore, I think “4) Do Nothing” is the way to go here.=

 =

Note th= at the <new></new> text is already in draft-mux-exclusive, and = option 4) would not remove it. 

&n= bsp;

The iss= ue is that, based on the update in RFC8035, the text is no longer within th= e “4th paragraph”, as RFC8035 adds new paragraphs, and my quest= ion is whether we should somehow point that out within draft-mux-exclusive.

&n= bsp;

>OTOH, I still think = that draft-mux-exclusive explicitly should indicate that “rtcp-mux-ex= clusive itself is bidirectional” and that RFC8035 updated RFC5761 to = clarify that “rtcp-mux is birectional”.

&n= bsp;

I think= we should look at that suggestion (which, btw, I think seems reasonable) a= s a separate thing. THIS issue is more administrative.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

 =

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: mmusic@ietf.org
Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and R= FC 8035

 = 

Hi,
draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 al=
so updates section 5.1.1 of RFC 8035.
draft-mux-exclusive keeps the existing text, and a=
dds some new (<new></new>).<=
o:p>
 <=
/o:p>
Update to=
 4th paragraph of section 5.1.1=

 
 
OLD TEXT (RFC 5761):

 


   If the answer does not contai=
n an "a=3Drtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


NEW TEXT (RF=
C 8035):


  =
 If the answer does not contain an "a=3Drtcp-mux" attribute, the =
offerer


   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


As we can se=
e, the original text is identical in 5761 and 8035. So, there is no clash. =
So far so good.


draft-mux-ex=
clusive keeps the existing text, and adds some new (<new></new>=
).


 <=
/o:p>


NEW TEXT (dr=
aft-mux-exclusive):


 


   If the answer does not contai=
n an "a=3Drtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signaled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute. <new> However, if the offerer indicated in the offer t=
hat it is


   not able to send and receive RT=
CP on a separate port, the offerer<=
/o:p>


   MUST disable the media streams =
associated with the attribute. The<=
/o:p>


   mechanism for indicating that t=
he offerer is not able to send and<=
/o:p>


   receive RTCP on a separate port=
 is outside the scope of this=



   specification.</new>




 






Now, the issue is that, following the upda=
te in RFC 8035, the text is no longer within the 4th paragraph of section 5=
.1.1. So, should we:






 






1) &nb=
sp;    within draft-mux-exclusive, indicate that both=
 RFC 5761 and RFC 8035 are updated; or






2)  &n=
bsp;   within draft-mux-exclusive, add a note indicating w=
hich paragraph is affected following the update in RFC 8035






3) &nb=
sp;    within draft-mux-exclusive, ONLY update RFC 80=
35; or






4) &nb=
sp;    o nothing






 






My first reaction would be to go for optio=
n 2), as there IMO is no reason to formally update the text in RFC 8035. 






 






Regards,






 






Christer






 






 
--_000_SN2PR03MB235088D834727A40C9F387D8B2170SN2PR03MB2350namp_-- From nobody Tue May 2 04:12:45 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD83131512 for ; Tue, 2 May 2017 04:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 pMFniuGXy9ns for ; Tue, 2 May 2017 04:12:43 -0700 (PDT) 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 3F1901315DE for ; Tue, 2 May 2017 04:09:35 -0700 (PDT) X-AuditID: c1b4fb3a-f56d89a000005025-e5-590868ed0379 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id EB.4C.20517.DE868095; Tue, 2 May 2017 13:09:33 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0339.000; Tue, 2 May 2017 13:09:32 +0200 From: Christer Holmberg To: "Asveren, Tolga" , "mmusic@ietf.org" Thread-Topic: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Thread-Index: AQHSwAW/bFONqGwgCkelI/jotUkR9KHgWM/ggAB0kICAABMnMIAAGreA Date: Tue, 2 May 2017 11:09:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D52E41101BF40christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7se7bDI5IgwvXRS2mLn/MYjG78z2T A5PHkiU/mTwuff7PHsAUxWWTkpqTWZZapG+XwJWx9cc6xoJVpxgrPj7fwtrAuHY9YxcjJ4eE gInEl89HWbsYuTiEBI4wSmxeMZcJwlnMKLHg01m2LkYODjYBC4nuf9ogDSICwRLPG34wgdjC Am4SyxfOZoOIu0u0LF3MCGG7SexYtQ4sziKgIvHk8xuwel4Ba4kTrw6xQ8yfzCTxa9t9sPmc ArESb35Kg9QwCohJfD+1BqyeWUBc4taT+UwQhwpILNlznhnCFpV4+fgfK4gtKqAnse/fVzaI uKLEx1f7GCF6EySO9Mxkg9grKHFy5hOWCYwis5CMnYWkbBaSMoi4gcT7c/OZIWxtiWULX0PZ +hIbv5xlnAV0NTPQO/tfCCIrWcDIsYpRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMOIObvlt tYPx4HPHQ4wCHIxKPLwJ9uyRQqyJZcWVuYcYJTiYlUR4ZXw4IoV4UxIrq1KL8uOLSnNSiw8x SnOwKInzOuy7ECEkkJ5YkpqdmlqQWgSTZeLglGpg7DYMit8l9XGl6qqnLxaIOV1Q6j3pJCoR sLD/5w8Jw6gPnJUR82SF1qk+/S0hmtQXqxSu7v3C71BgzAt+yegAlzCJhwI3VW+stAtjCz/h fuLBNa6fRx2irut3RSxkez4pWptN33adprHpUde8eVqR5wI8VFT1mCfeqkg8rvg9w5tznu2m SFklluKMREMt5qLiRAABqeoQtAIAAA== Archived-At: Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 11:12:45 -0000 --_000_D52E41101BF40christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >I got your point but that made me think about a more fundamental issue: Do= es draft-mux-exclusive indeed update RFC5761? >IMHO it is not. It defines a new indicator with its own semantics. This is= a new capability, not something changing a capability already defined. And >it seems =93backward compatibility concerns=94 are already addressed in a = reasonable way by mux-exclusive and RFC8035 updates on RFC5761. > >So, I would: >i- Remove =93Updates: RFC5761=94 statement from the prologue >ii- Remove Section 5. > >If you still want to keep rtcp-mux-exclusive as an =93update on RFC5761=94= , then 2) sounds reasonable to me as well. It was previously agreed to add the text to draft-mux-exclusive= , so I don=92t want to change that at this point. At the end of the day, it= =92s just a clarification specifying that if there is SOME mechanism to ind= icate that separate ports cannot be used, the stream must be disabled. Unfo= rtunately, the RFC8035 update does not add such specification. Option 2) would be adding something like this to draft-mux-exclusive: "NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the paragraph u= pdated in this document is not updated by RFC8035, the location of the para= graph within section 5.1.1 is moved." Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 4:25 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, >i- =93rtcp-mux-exclusive=94 is a new capability/indication, not an update = on RFC5761/8035 per se. >ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional= . >iii- rtcp-mux-exclusive is defined as bidirectional. > >Adding all these together, I fail to see the rationale behind the text. Therefore, I think =934) Do Nothing=94 is the way to go here. Note that the text is already in draft-mux-exclusive, and optio= n 4) would not remove it. The issue is that, based on the update in RFC8035, the text is no longer wi= thin the =934th paragraph=94, as RFC8035 adds new paragraphs, and my questi= on is whether we should somehow point that out within draft-mux-exclusive. >OTOH, I still think that draft-mux-exclusive explicitly should indicate th= at =93rtcp-mux-exclusive itself is bidirectional=94 and that RFC8035 update= d RFC5761 to clarify that =93rtcp-mux is birectional=94. I think we should look at that suggestion (which, btw, I think seems reason= able) as a separate thing. THIS issue is more administrative. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Friday, April 28, 2017 5:57 AM To: mmusic@ietf.org Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also u= pdates section 5.1.1 of RFC 8035. draft-mux-exclusive keeps the existing text, and adds some new (= ). Update to 4th paragraph of section 5.1.1 OLD TEXT (RFC 5761): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. NEW TEXT (RFC 8035): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. As we can see, the original text is identical in 5761 and 8035. So, there i= s no clash. So far so good. draft-mux-exclusive keeps the existing text, and adds some new (= ). NEW TEXT (draft-mux-exclusive): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signaled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. However, if the offerer indicated in the offer that it = is not able to send and receive RTCP on a separate port, the offerer MUST disable the media streams associated with the attribute. The mechanism for indicating that the offerer is not able to send and receive RTCP on a separate port is outside the scope of this specification. Now, the issue is that, following the update in RFC 8035, the text is no lo= nger within the 4th paragraph of section 5.1.1. So, should we: 1) within draft-mux-exclusive, indicate that both RFC 5761 and RFC 803= 5 are updated; or 2) within draft-mux-exclusive, add a note indicating which paragraph i= s affected following the update in RFC 8035 3) within draft-mux-exclusive, ONLY update RFC 8035; or 4) o nothing My first reaction would be to go for option 2), as there IMO is no reason t= o formally update the text in RFC 8035. Regards, Christer --_000_D52E41101BF40christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <35A08E6EC02A7F46AE996A260C743050@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

>I got your point but that made me think about a = more fundamental issue: Does draft-mux-exclusive indeed update RFC5761?

>IMHO it is not. It defines a new indicator with = its own semantics. This is a new capability, not something changing a capab= ility already defined. And

>it seems =93backward compatibilit= y concerns=94 are already addressed in a reasonable way by mux-exclusive an= d RFC8035 updates on RFC5761.

> 

>So, I would:

>i- Remove =93Updates: RFC5761=94 statement from = the prologue

>ii- Remove Section 5.

>

>If you still want to keep rtcp-mux-exclusive as = an =93update on RFC5761=94, then 2) sounds reasonable to me as well.

 
It was previously agreed to add the <new></new> text to dr= aft-mux-exclusive, so I don=92t want to change that at this point. At the e= nd of the day, it=92s just a clarification specifying that if there is SOME= mechanism to indicate that separate ports cannot be used, the stream must be disabled. Unfortunately, the RFC8035 update do= es not add such specification.

Option 2) would be adding something like this to draft-mux-exclusive:<= /div>

"NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the p= aragraph updated in this document is not updated by RFC8035, the location o= f the paragraph within section 5.1.1 is moved."

Regards,

Christer



 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, May 2, 2017 4:25 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 80= 35

 

Hi,

&n= bsp;

>i- =93rtcp-mux-exclu= sive=94 is a new capability/indication, not an update on RFC5761/8035 per s= e.

>ii- RFC8035 updates = RFC5761 so that rtcp-mux is used only as bidirectional.

>iii- rtcp-mux-exclus= ive is defined as bidirectional.

> 

>Adding all these tog= ether, I fail to see the rationale behind the <new></new> text.= Therefore, I think =934) Do Nothing=94 is the way to go here.

 =

Note th= at the <new></new> text is already in draft-mux-exclusive, and = option 4) would not remove it. 

&n= bsp;

The iss= ue is that, based on the update in RFC8035, the text is no longer within th= e =934th paragraph=94, as RFC8035 adds new paragraphs, and my question is w= hether we should somehow point that out within draft-mux-exclusive.

&n= bsp;

>OTOH, I still think = that draft-mux-exclusive explicitly should indicate that =93rtcp-mux-exclus= ive itself is bidirectional=94 and that RFC8035 updated RFC5761 to clarify = that =93rtcp-mux is birectional=94.

&n= bsp;

I think= we should look at that suggestion (which, btw, I think seems reasonable) a= s a separate thing. THIS issue is more administrative.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

 =

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: mmusic@ietf.org
Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and R= FC 8035

 = 

Hi,
draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 al=
so updates section 5.1.1 of RFC 8035.
draft-mux-exclusive keeps the existing text, and a=
dds some new (<new></new>).<=
o:p>
 <=
/o:p>
Update to=
 4th paragraph of section 5.1.1=

 
 
OLD TEXT (RFC 5761):

 


   If the answer does not contai=
n an "a=3Drtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


NEW TEXT (RF=
C 8035):


  =
 If the answer does not contain an "a=3Drtcp-mux" attribute, the =
offerer


   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


As we can se=
e, the original text is identical in 5761 and 8035. So, there is no clash. =
So far so good.


draft-mux-ex=
clusive keeps the existing text, and adds some new (<new></new>=
).


 <=
/o:p>


NEW TEXT (dr=
aft-mux-exclusive):


 


   If the answer does not contai=
n an "a=3Drtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signaled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute. <new> However, if the offerer indicated in the offer t=
hat it is


   not able to send and receive RT=
CP on a separate port, the offerer<=
/o:p>


   MUST disable the media streams =
associated with the attribute. The<=
/o:p>


   mechanism for indicating that t=
he offerer is not able to send and<=
/o:p>


   receive RTCP on a separate port=
 is outside the scope of this=



   specification.</new>




 






Now, the issue is that, following the upda=
te in RFC 8035, the text is no longer within the 4th paragraph of section 5=
.1.1. So, should we:






 






1) &nb=
sp;    within draft-mux-exclusive, indicate that both=
 RFC 5761 and RFC 8035 are updated; or






2)  &n=
bsp;   within draft-mux-exclusive, add a note indicating w=
hich paragraph is affected following the update in RFC 8035






3) &nb=
sp;    within draft-mux-exclusive, ONLY update RFC 80=
35; or






4) &nb=
sp;    o nothing






 






My first reaction would be to go for optio=
n 2), as there IMO is no reason to formally update the text in RFC 8035. 






 






Regards,






 






Christer






 






 
--_000_D52E41101BF40christerholmbergericssoncom_-- From nobody Tue May 2 05:01:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB251316AB for ; Tue, 2 May 2017 05:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1GPm-00gxfP9 for ; Tue, 2 May 2017 05:01:16 -0700 (PDT) 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 6628F12EC29 for ; Tue, 2 May 2017 04:57:51 -0700 (PDT) X-AuditID: c1b4fb3a-b7dff70000005025-8f-5908743c2ca6 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id FE.97.20517.C3478095; Tue, 2 May 2017 13:57:49 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0339.000; Tue, 2 May 2017 13:57:47 +0200 From: Christer Holmberg To: "Asveren, Tolga" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? Thread-Index: AQHSvOgCNt6Dk7x2uEaNj1LXZRgEJKHUeB1AgAyW1oA= Date: Tue, 2 May 2017 11:57:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D52E4EF71BF88christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyM2K7ja5tCUekQdcULYupyx+zWMzufM/k wOSxZMlPJo9Ln/+zBzBFcdmkpOZklqUW6dslcGVMfzSbsWBmTcW56zNYGxjn5nYxcnJICJhI vDp3kRXEFhI4wijx8ol+FyMXkL2YUWLHkmdACQ4ONgELie5/2iA1IgLBEs8bfjCB2MICQRK3 10xnhIlfW7QfyraSuDD9P1gNi4CKxNKe2ewgNq+AtUTPhFVMEPP7GCXuvHvGBpLgFIiV2Df7 DQuIzSggJvH91BqwZmYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf2BHiwroSez795UNIq4ocXX6 ciaQm5kFEiR+vw+C2CsocXLmE5YJjCKzkEydhVA1C0kVRImBxPtz85khbG2JZQtfQ9n6Ehu/ nGWEsK0lGjc2MiGrWcDIsYpRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMNYObvlttYPx4HPH Q4wCHIxKPLwJ9uyRQqyJZcWVuYcYJTiYlUR4ZXw4IoV4UxIrq1KL8uOLSnNSiw8xSnOwKInz Ouy7ECEkkJ5YkpqdmlqQWgSTZeLglGpgzPw7o+jOxI+aMzsNOZatTVnlwl7U+2SuX05h3Vve kl2BW3cY/S1bv4Jtm5sFp66SmOddraO5MaJn+4/x7VMslGS/pVhg9GOdR8OEtv9q/w7lpC0R OSh8bQv/glWpvvo7ilf9nvpAXNJnwwr+MwvmGb13TinXUOG64iCZM1dZ/LGn7e+y5OBbSizF GYmGWsxFxYkAi7bvorECAAA= Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 12:01:23 -0000 --_000_D52E4EF71BF88christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I took a look at this again. I am not sure I understand what it meant by rt= cp-mux-only being bidirectional. If rtp/rtcp-mux is negotiated, it will be bidirectional according to RFC803= 5. Note that, with rtcp-mux-only, you still need to include a=3Drtcp-mux, s= o the bidirectional rules associated with rtcp-mux still apply. Regards, Christer From: Tolga Asveren > Date: Monday 24 April 2017 at 21:29 To: Christer Holmberg >, "mmusic@ietf.org" > Subject: RE: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Thanks for pointing this out. The issue still would be applicable for alrea= dy deployed RFC5761 compliant/RFC8035 non-compliant entities. Therefore IMH= O it could be a good idea to explicitly mention that =93rtcp-mux-only=94 is= bidirectional as =93rtcp-mux=94 per RFC8035. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, April 24, 2017 6:46 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Hi, RFC 5761 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.t= xt), where we clarify that negotiated mux is always bidirectional. "This document updates RFC 5761 [RFC5761] by clarifying that an answerer can only include an "a=3Drtcp-mux" attribute in an answer if the associated offer contained the attribute. It also clarifies that the negotiation of RTP and RTCP multiplexing is for usage in both directions." Regards, Christer From: mmusic > on b= ehalf of Tolga Asveren = > Date: Monday 24 April 2017 at 13:24 To: "mmusic@ietf.org" > Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional= ? It seems draft-ietf-mmusic-mux-exclusive-11 assumes that mux support will b= e always bidirectional. OTOH, I think RFC5761 allows unidirectional semanti= cs: 5.1.1. SDP Signaling =85 When SDP is used in a declarative manner, the presence of an "a=3Drtcp- mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth. Actually this part of RFC5761 sounds a bit odd as in declarative mode I tho= ught an attribute would convey information about the =93receipt properties= =94 therefore =93rtcp-mux=94 would mean that the sender wants to receive RT= P/RTCP multiplexed on the same port. It could be good to explicitly state in draft-ietf-mmusic-mux-exclusive tha= t unidirectional multiplexing with declarative mode is not supported. Example scenario: A sends rtcp-mux/rtcp-mux-only B does not support rtcp-mux-only and ignores it. It interprets rtcp-mux in = declarative mode and is ready to receive RTP/RTCP on the same port. OTOH, i= t does not want to send multiplexed RTP/RTCP hence does not include rtcp-mu= x in the reply. A terminates the session because the answer does not contain rtcp-mux. It c= an=92t determine whether multiplexing is not supported at all or whether B = wants to use it in a unidirectional way. Thanks, Tolga --_000_D52E4EF71BF88christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I took a look at this again. I am not sure I understand what it meant = by rtcp-mux-only being bidirectional.

If rtp/rtcp-mux is negotiated, it will be bidirectional according to R= FC8035. Note that, with rtcp-mux-only, you still need to include a=3Drtcp-m= ux, so the bidirectional rules associated with rtcp-mux still apply.

Regards,

Christer


From: Tolga Asveren <tasveren@sonusnet.com>
Date: Monday 24 April 2017 at 21:29=
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" = <mmusic@ietf.org>
Subject: RE: [MMUSIC] draft-ietf-mm= usic-mux-exclusive-11 / always bidirectional?

Thanks for pointing this out. The issue still would = be applicable for already deployed RFC5761 compliant/RFC8035 non-compliant = entities. Therefore IMHO it could be a good idea to explicitly mention that= =93rtcp-mux-only=94 is bidirectional as =93rtcp-mux=94 per RFC8035.

 

Thanks,

Tolga

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, April 24, 2017 6:46 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

 

Hi,

&n= bsp;

RFC 576= 1 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.txt), where we clarify that = negotiated mux is always bidirectional.

&n= bsp;

  =
 "This document updates RFC 5761 [RFC5761] by clarifying that an<=
/o:p>
   answerer can only include an =
"a=3Drtcp-mux" attribute in an answer if
   the associated offer containe=
d the attribute.  It also clarifies that
   the negotiation of RTP and RT=
CP multiplexing is for usage in both
   directions."<=
/span>

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

From: mmusic <mmusic-bounces@ietf.org> on behalf of Tolga Asveren <tasveren@sonusnet.com>
Date: Monday 24 April 2017 at 13:24
To: "mmusic@ietf.org&quo= t; <mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidire= ctional?

&n= bsp;

It seems draft-ietf-mmus= ic-mux-exclusive-11 assumes that mux support will be always bidirectional. = OTOH, I think RFC5761 allows unidirectional semantics:

 =

5.1.1. SDP Signaling

=85

 =

   When SDP is used in a declarative= manner, the presence of an "a=3Drtcp-

   mux" attribute signals that = the sender will multiplex RTP and RTCP on

   the same port.  The receiver= MUST be prepared to receive RTCP packets

   on the RTP port, and any resource= reservation needs to be made=

   including the RTCP bandwidth.

 =

Actually this part of RF= C5761 sounds a bit odd as in declarative mode I thought an attribute would = convey information about the =93receipt properties=94 therefore =93rtcp-mux= =94 would mean that the sender wants to receive RTP/RTCP multiplexed on the same port.

 =

It could be good to expl= icitly state in draft-ietf-mmusic-mux-exclusive that unidirectional multipl= exing with declarative mode is not supported.

 =

Example scenario:

A sends rtcp-mux/rtcp-mu= x-only

B does not support rtcp-= mux-only and ignores it. It interprets rtcp-mux in declarative mode and is = ready to receive RTP/RTCP on the same port. OTOH, it does not want to send = multiplexed RTP/RTCP hence does not include rtcp-mux in the reply.

A terminates the session= because the answer does not contain rtcp-mux. It can=92t determine whether= multiplexing is not supported at all or whether B wants to use it in a uni= directional way.

 =

Thanks,

Tolga<= /p>

--_000_D52E4EF71BF88christerholmbergericssoncom_-- From nobody Tue May 2 07:44:20 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE45129B72 for ; Tue, 2 May 2017 07:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 fU3fU1k2pEUL for ; Tue, 2 May 2017 07:44:15 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32E82129B79 for ; Tue, 2 May 2017 07:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GIYJGdpDrZmpya203NC/hkpTrpoC4Mt+dI+vfTxISp4=; b=mZr0kQPDPADutMFrXgUyYF+SV9x2YECczFJEGWhv0I+cTNCaOZC0SWgPGob8PcqQp66sYGALDXGgyHCqPCfMKbylA4LR0rbsGA1aZrL/2qcCUAVaUBHsI0mkh3E5k9eJQHwFbJTATIV3j+DmFRePtkNJItRsR+loiWlGEzChTFY= Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0047.outbound.protection.outlook.com [207.46.163.47]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-58-irkVASb4NGezm8GEnerYmw-1; Tue, 02 May 2017 10:40:21 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Tue, 2 May 2017 14:40:18 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1061.021; Tue, 2 May 2017 14:40:18 +0000 From: "Asveren, Tolga" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? Thread-Index: AQHSvOgCNt6Dk7x2uEaNj1LXZRgEJKHUeB1AgAyW1oCAABq+MA== Date: Tue, 2 May 2017 14:40:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:cehlIzR679s5k1p7wGMwdikyygJw9DQr4iMLtXfDbDYcL5Ex99Pr4tLJpfrANsmlEZV3J+HwAiTdrGN9SFneG/TXNTnUEDFdEsylEbPXk8uFjAgU5kqcOjyQvL9dABJ8MRLyf0Jcjd+j098LxpJyrR3mw07jhXUy+VW5J+FCOUtl1u3JUuM0uyTB1LYEaulY8rLgwZPnn2LLO9Mb6yhDwKS2JKp10GB5D9gb9V2rHjDiGBot4RAF/VHiVvRliqRu71s1SfEK7i2iva6v6/w26WtVO8o2YDjHVnNEpR+0VVsjRw1iou8bfoIcF5wxSXWGroyFS2vWlV6n91cwlLHu+w==; 20:ISLe8XyHgHy0Z84CvZzXvsNUD6u8I+SCZzWLiJ5N0TM3miQCRfEkVL7X7wpqrr1F8QQmA7e+GOLCUADUhN5uM2HEOIXLZHK7KlErw/QI6lamcq12rVKTWpvSSjo6BFKqPAGIoc/bU0dGCPKN8b5dyu2Kf0O1UZDoeeS3nrqKrq0= x-ms-office365-filtering-correlation-id: 1267d1fc-ee52-4f7e-768a-08d49169278b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN2PR03MB2352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39830400002)(39410400002)(39450400003)(377454003)(229853002)(77096006)(55016002)(7696004)(99286003)(6506006)(7906003)(2950100002)(189998001)(50986999)(54356999)(8676002)(236005)(478600001)(2501003)(606005)(6436002)(66066001)(53936002)(5660300001)(38730400002)(122556002)(9686003)(6306002)(54896002)(6246003)(53546009)(25786009)(74316002)(102836003)(7736002)(76176999)(81166006)(230783001)(2900100001)(33656002)(8936002)(86362001)(3660700001)(2906002)(6116002)(3280700002)(3846002)(790700001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2017 14:40:18.5305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: irkVASb4NGezm8GEnerYmw-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350FEB938119CDE6E1CCBADB2170SN2PR03MB2350namp_" Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 14:44:17 -0000 --_000_SN2PR03MB2350FEB938119CDE6E1CCBADB2170SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Yes agreed. All I am asking for is a sentence to prevent confusion: "It should be noted that both rtcp-mux (per updates in RFC8035) and rtcp-mu= x-only have bidirectional semantics. They are either accepted and used by b= oth sides or not at all." Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 7:58 AM To: Asveren, Tolga ; mmusic@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Hi, I took a look at this again. I am not sure I understand what it meant by rt= cp-mux-only being bidirectional. If rtp/rtcp-mux is negotiated, it will be bidirectional according to RFC803= 5. Note that, with rtcp-mux-only, you still need to include a=3Drtcp-mux, s= o the bidirectional rules associated with rtcp-mux still apply. Regards, Christer From: Tolga Asveren > Date: Monday 24 April 2017 at 21:29 To: Christer Holmberg >, "mmusic@ietf.org" > Subject: RE: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Thanks for pointing this out. The issue still would be applicable for alrea= dy deployed RFC5761 compliant/RFC8035 non-compliant entities. Therefore IMH= O it could be a good idea to explicitly mention that "rtcp-mux-only" is bid= irectional as "rtcp-mux" per RFC8035. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, April 24, 2017 6:46 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Hi, RFC 5761 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.t= xt), where we clarify that negotiated mux is always bidirectional. "This document updates RFC 5761 [RFC5761] by clarifying that an answerer can only include an "a=3Drtcp-mux" attribute in an answer if the associated offer contained the attribute. It also clarifies that the negotiation of RTP and RTCP multiplexing is for usage in both directions." Regards, Christer From: mmusic > on b= ehalf of Tolga Asveren = > Date: Monday 24 April 2017 at 13:24 To: "mmusic@ietf.org" > Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional= ? It seems draft-ietf-mmusic-mux-exclusive-11 assumes that mux support will b= e always bidirectional. OTOH, I think RFC5761 allows unidirectional semanti= cs: 5.1.1. SDP Signaling ... When SDP is used in a declarative manner, the presence of an "a=3Drtcp- mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth. Actually this part of RFC5761 sounds a bit odd as in declarative mode I tho= ught an attribute would convey information about the "receipt properties" t= herefore "rtcp-mux" would mean that the sender wants to receive RTP/RTCP mu= ltiplexed on the same port. It could be good to explicitly state in draft-ietf-mmusic-mux-exclusive tha= t unidirectional multiplexing with declarative mode is not supported. Example scenario: A sends rtcp-mux/rtcp-mux-only B does not support rtcp-mux-only and ignores it. It interprets rtcp-mux in = declarative mode and is ready to receive RTP/RTCP on the same port. OTOH, i= t does not want to send multiplexed RTP/RTCP hence does not include rtcp-mu= x in the reply. A terminates the session because the answer does not contain rtcp-mux. It c= an't determine whether multiplexing is not supported at all or whether B wa= nts to use it in a unidirectional way. Thanks, Tolga --_000_SN2PR03MB2350FEB938119CDE6E1CCBADB2170SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Yes agreed. All I am asking for is a sentence to pre= vent confusion:

 

“It should be noted that both rtcp-mux (per up= dates in RFC8035) and rtcp-mux-only have bidirectional semantics. They are = either accepted and used by both sides or not at all.”

 

Thanks,

Tolga

 

From: Christer Holmberg [mailto:christer.holm= berg@ericsson.com]
Sent: Tuesday, May 2, 2017 7:58 AM
To: Asveren, Tolga <tasveren@sonusnet.com>; mmusic@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

 

Hi,

&n= bsp;

I took = a look at this again. I am not sure I understand what it meant by rtcp-mux-= only being bidirectional.

&n= bsp;

If rtp/= rtcp-mux is negotiated, it will be bidirectional according to RFC8035. Note= that, with rtcp-mux-only, you still need to include a=3Drtcp-mux, so the b= idirectional rules associated with rtcp-mux still apply.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

&n= bsp;

From: Tolga Asveren <tasveren@sonusnet.com>
Date: Monday 24 April 2017 at 21:29
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: RE: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

&n= bsp;

Thanks for pointing this= out. The issue still would be applicable for already deployed RFC5761 comp= liant/RFC8035 non-compliant entities. Therefore IMHO it could be a good ide= a to explicitly mention that “rtcp-mux-only” is bidirectional as “rtcp-mux” per RFC8035. =

 =

Thanks,

Tolga<= /p>

 =

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, April 24, 2017 6:46 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

 =

Hi,

 <= /span>

RFC 576= 1 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.txt), where we clarify that = negotiated mux is always bidirectional.<= o:p>

 <= /span>

  =
 "This document updates RFC 5761 [RFC5761] by clarifying that an<=
/o:p>
   answerer can only include an =
"a=3Drtcp-mux" attribute in an answer if
   the associated offer containe=
d the attribute.  It also clarifies that
   the negotiation of RTP and RT=
CP multiplexing is for usage in both
   directions."<=
/span>

 <= /span>

Regards= ,

 <= /span>

Christe= r

 <= /span>

From: mmusic <mmusic-bounces@ietf.org> on behalf of Tolga Asveren <tasveren@sonusnet.com>
Date: Monday 24 April 2017 at 13:24
To: "mmusic@ietf.org&quo= t; <mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidire= ctional?

 <= /span>

It seems draft-ietf-mmus= ic-mux-exclusive-11 assumes that mux support will be always bidirectional. = OTOH, I think RFC5761 allows unidirectional semantics:

 =

5.1.1. SDP Signaling

…

 =

   When SDP is used in a declarative= manner, the presence of an "a=3Drtcp-

   mux" attribute signals that = the sender will multiplex RTP and RTCP on

   the same port.  The receiver= MUST be prepared to receive RTCP packets

   on the RTP port, and any resource= reservation needs to be made=

   including the RTCP bandwidth.

 =

Actually this part of RF= C5761 sounds a bit odd as in declarative mode I thought an attribute would = convey information about the “receipt properties” therefore = 220;rtcp-mux” would mean that the sender wants to receive RTP/RTCP multiplexed on the same port.

 =

It could be good to expl= icitly state in draft-ietf-mmusic-mux-exclusive that unidirectional multipl= exing with declarative mode is not supported.

 =

Example scenario:

A sends rtcp-mux/rtcp-mu= x-only

B does not support rtcp-= mux-only and ignores it. It interprets rtcp-mux in declarative mode and is = ready to receive RTP/RTCP on the same port. OTOH, it does not want to send = multiplexed RTP/RTCP hence does not include rtcp-mux in the reply.

A terminates the session= because the answer does not contain rtcp-mux. It can’t determine whe= ther multiplexing is not supported at all or whether B wants to use it in a= unidirectional way.

 =

Thanks,

Tolga<= /p>

--_000_SN2PR03MB2350FEB938119CDE6E1CCBADB2170SN2PR03MB2350namp_-- From nobody Tue May 2 07:56:04 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDC413164F for ; Tue, 2 May 2017 07:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 pOLzkZHfQcIx for ; Tue, 2 May 2017 07:56:00 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [216.205.24.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB671294DF for ; Tue, 2 May 2017 07:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tTOpnj1cA3ItyL9xIxAvXVKgjBpy0RbOLgY7UJBT6xA=; b=Klird9ArTUeZPs/1otvIfaNnXOO6zHtZJ1s0Zdgzkhs7vwzXSpKqhD1kQygEjkXL+CDX/UskuaHRbJBv4IMIG2XDzKBejbgERaPOWV4uBb2YNd2JKOUWf5fjtPvj4pbJxpWWaGdQyCw0tZVrbgyV9BVmzh9DZ1UPt9h36t97xM0= Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0022.outbound.protection.outlook.com [207.46.163.22]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-161-GbDKd4B-Ne2hKG89-OPKVA-1; Tue, 02 May 2017 10:51:37 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1061.12; Tue, 2 May 2017 14:51:35 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1061.021; Tue, 2 May 2017 14:51:35 +0000 From: "Asveren, Tolga" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Thread-Index: AQHSwAW/bFONqGwgCkelI/jotUkR9KHgWM/ggAB0kICAABMnMIAAGreAgAAoz6A= Date: Tue, 2 May 2017 14:51:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:gCuxX4oh8uFm6rIKo88LWJ1LomLq+jL4xbcuJd7cOi9InpIWgybDPn7fUpAopzG2BvgdAnONHtfavNg37vrVVsJ8Y2eHHBSSHAiLFx0IMb62Tm9Hf2856sL/mOkAmDL26Y5Lbm69i6pIqFMaWOoVhLgYzvlcaM4JXXkEcLqTjZmi2IrL2UFAJzE/EqCubO2bT50SRNQ82a8IxnMvt3vl/UHVFrgiDdk3eaqm52XYlfr/1uI/IaKwm8QrewI/G7L/5/92f3ooNZMbp22PzoNLDYA/+s6aDm04zgEHz5YCp2iRd4Lp9bOKFzqrh+iI4s1egB6O/zUz0Dr0VXjdZzPDsw==; 20:cEaZKL3qPXo6ZhB2hk8w31pfCouAMd9D5nu6upZGOT95+ixgefM1GeHS9khHEEA7sXI953GUVoEAQOjRUk5rOlZwB+xRZwu/tesuyYcyLQa+JiQb0Bn5KwroR1rbQHt6PjX3H6kUoKbrZVBuPRHtyo02zoUmCE6cikQrais9MS8= x-ms-office365-filtering-correlation-id: c4217fc1-b34e-469b-4447-08d4916abaec x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN2PR03MB2352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39830400002)(39410400002)(39450400003)(377454003)(229853002)(77096006)(55016002)(7696004)(99286003)(6506006)(2950100002)(7110500001)(189998001)(50986999)(54356999)(8676002)(236005)(478600001)(2501003)(6436002)(15650500001)(2420400007)(66066001)(53936002)(5660300001)(38730400002)(122556002)(9686003)(6306002)(54896002)(6246003)(53546009)(25786009)(74316002)(102836003)(7736002)(76176999)(81166006)(230783001)(2900100001)(33656002)(93886004)(8936002)(86362001)(3660700001)(10710500007)(2906002)(6116002)(3280700002)(3846002)(790700001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2017 14:51:35.2017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: GbDKd4B-Ne2hKG89-OPKVA-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB235005FC1457A7225FBFC6BFB2170SN2PR03MB2350namp_" Archived-At: Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 14:56:03 -0000 --_000_SN2PR03MB235005FC1457A7225FBFC6BFB2170SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Honestly that agreement sounds a bit weird to me. Certain semantics associa= ted with a non-specified indicator is added as an update to RFC5761 but the= actual indicator and the rest of semantics are missing. If one wants to pu= rsue the "update RFC5761" path, IMHO the more reasonable approach would be = to define the whole content of rtcp-mux-exclusive as an update to RFC5761. = And just to reiterate, I would say that not updating RFC5761 and keeping ev= erything as newly defined capability in rtcp-mux-only would be my preferenc= e. I am also not sure whether RFC8035 update wouldn't imply that stream must b= e disabled in such a case. What else could be done? Isn't this the standard= behavior if negotiation for any stream fails? RFC4566 6 Generating the Answer .... An offered stream MAY be rejected in the answer, for any reason. If a stream is rejected, the offerer and answerer MUST NOT generate media (or RTCP packets) for that stream. To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 7:10 AM To: Asveren, Tolga ; mmusic@ietf.org Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, >I got your point but that made me think about a more fundamental issue: Do= es draft-mux-exclusive indeed update RFC5761? >IMHO it is not. It defines a new indicator with its own semantics. This is= a new capability, not something changing a capability already defined. And >it seems "backward compatibility concerns" are already addressed in a reas= onable way by mux-exclusive and RFC8035 updates on RFC5761. > >So, I would: >i- Remove "Updates: RFC5761" statement from the prologue >ii- Remove Section 5. > >If you still want to keep rtcp-mux-exclusive as an "update on RFC5761", th= en 2) sounds reasonable to me as well. It was previously agreed to add the text to draft-mux-exclusive= , so I don't want to change that at this point. At the end of the day, it's= just a clarification specifying that if there is SOME mechanism to indicat= e that separate ports cannot be used, the stream must be disabled. Unfortun= ately, the RFC8035 update does not add such specification. Option 2) would be adding something like this to draft-mux-exclusive: "NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the paragraph u= pdated in this document is not updated by RFC8035, the location of the para= graph within section 5.1.1 is moved." Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 4:25 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, >i- "rtcp-mux-exclusive" is a new capability/indication, not an update on R= FC5761/8035 per se. >ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional= . >iii- rtcp-mux-exclusive is defined as bidirectional. > >Adding all these together, I fail to see the rationale behind the text. Therefore, I think "4) Do Nothing" is the way to go here. Note that the text is already in draft-mux-exclusive, and optio= n 4) would not remove it. The issue is that, based on the update in RFC8035, the text is no longer wi= thin the "4th paragraph", as RFC8035 adds new paragraphs, and my question i= s whether we should somehow point that out within draft-mux-exclusive. >OTOH, I still think that draft-mux-exclusive explicitly should indicate th= at "rtcp-mux-exclusive itself is bidirectional" and that RFC8035 updated RF= C5761 to clarify that "rtcp-mux is birectional". I think we should look at that suggestion (which, btw, I think seems reason= able) as a separate thing. THIS issue is more administrative. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Friday, April 28, 2017 5:57 AM To: mmusic@ietf.org Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also u= pdates section 5.1.1 of RFC 8035. draft-mux-exclusive keeps the existing text, and adds some new (= ). Update to 4th paragraph of section 5.1.1 OLD TEXT (RFC 5761): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. NEW TEXT (RFC 8035): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. As we can see, the original text is identical in 5761 and 8035. So, there i= s no clash. So far so good. draft-mux-exclusive keeps the existing text, and adds some new (= ). NEW TEXT (draft-mux-exclusive): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signaled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. However, if the offerer indicated in the offer that it = is not able to send and receive RTCP on a separate port, the offerer MUST disable the media streams associated with the attribute. The mechanism for indicating that the offerer is not able to send and receive RTCP on a separate port is outside the scope of this specification. Now, the issue is that, following the update in RFC 8035, the text is no lo= nger within the 4th paragraph of section 5.1.1. So, should we: 1) within draft-mux-exclusive, indicate that both RFC 5761 and RFC 803= 5 are updated; or 2) within draft-mux-exclusive, add a note indicating which paragraph i= s affected following the update in RFC 8035 3) within draft-mux-exclusive, ONLY update RFC 8035; or 4) o nothing My first reaction would be to go for option 2), as there IMO is no reason t= o formally update the text in RFC 8035. Regards, Christer --_000_SN2PR03MB235005FC1457A7225FBFC6BFB2170SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Honestly that agreement sounds a bit weird to me. Ce= rtain semantics associated with a non-specified indicator is added as an up= date to RFC5761 but the actual indicator and the rest of semantics are miss= ing. If one wants to pursue the “update RFC5761” path, IMHO the more reasonable approach would be to define = the whole content of rtcp-mux-exclusive as an update to RFC5761. And just t= o reiterate, I would say that not updating RFC5761 and keeping everything a= s newly defined capability in rtcp-mux-only would be my preference.

 

I am also not sure whether RFC8035 update wouldnR= 17;t imply that stream must be disabled in such a case. What else could be = done? Isn’t this the standard behavior if negotiation for any stream = fails?

 

RFC4566

 

6 Generating the Answer

 

….

   An offered stream MAY be rejected in the= answer, for any reason.  If

   a stream is rejected, the offerer and answere= r MUST NOT generate

   media (or RTCP packets) for that stream. = ; To reject an offered

   stream, the port number in the corresponding = stream in the answer

   MUST be set to zero.

 

 

Thanks,

Tolga

 

From: Christer Holmberg [mailto:christer.holm= berg@ericsson.com]
Sent: Tuesday, May 2, 2017 7:10 AM
To: Asveren, Tolga <tasveren@sonusnet.com>; mmusic@ietf.org Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 80= 35

 

Hi,

&n= bsp;

>I got your point but= that made me think about a more fundamental issue: Does draft-mux-exclusiv= e indeed update RFC5761?

>IMHO it is not. It d= efines a new indicator with its own semantics. This is a new capability, no= t something changing a capability already defined. And

>it seems “backward compatibility conc= erns” are already addressed in a reasonable way by mux-exclusive and = RFC8035 updates on RFC5761.

> 

>So, I would:

>i- Remove “Upd= ates: RFC5761” statement from the prologue

>ii- Remove Section 5= .

> 

>If you still want to= keep rtcp-mux-exclusive as an “update on RFC5761”, then 2) sou= nds reasonable to me as well.

 =

It was = previously agreed to add the <new></new> text to draft-mux-excl= usive, so I don’t want to change that at this point. At the end of th= e day, it’s just a clarification specifying that if there is SOME mechanism to indicate that separate ports cannot be used, the stre= am must be disabled. Unfortunately, the RFC8035 update does not add such sp= ecification.

&n= bsp;

Option = 2) would be adding something like this to draft-mux-exclusive:

&n= bsp;

"N= OTE: RFC8035 also updates section 5.1.1 of RFC5761. While the paragraph upd= ated in this document is not updated by RFC8035, the location of the paragr= aph within section 5.1.1 is moved."

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

&n= bsp;

&n= bsp;

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, May 2, 2017 4:25 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 80= 35

 =

Hi,

 <= /span>

>i- “rtcp-mux-e= xclusive” is a new capability/indication, not an update on RFC5761/80= 35 per se.

>ii- RFC8035 updates = RFC5761 so that rtcp-mux is used only as bidirectional.

>iii- rtcp-mux-exclus= ive is defined as bidirectional.

> 

>Adding all these tog= ether, I fail to see the rationale behind the <new></new> text.= Therefore, I think “4) Do Nothing” is the way to go here.=

 =

Note th= at the <new></new> text is already in draft-mux-exclusive, and = option 4) would not remove it. 

 <= /span>

The iss= ue is that, based on the update in RFC8035, the text is no longer within th= e “4th paragraph”, as RFC8035 adds new paragraphs, and my quest= ion is whether we should somehow point that out within draft-mux-exclusive.<= /span>

 <= /span>

>OTOH, I still think = that draft-mux-exclusive explicitly should indicate that “rtcp-mux-ex= clusive itself is bidirectional” and that RFC8035 updated RFC5761 to = clarify that “rtcp-mux is birectional”.

 <= /span>

I think= we should look at that suggestion (which, btw, I think seems reasonable) a= s a separate thing. THIS issue is more administrative.

 <= /span>

Regards= ,

 <= /span>

Christe= r

 <= /span>

 =

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: mmusic@ietf.org
Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and R= FC 8035

 = 

Hi,
draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 al=
so updates section 5.1.1 of RFC 8035.
draft-mux-exclusive keeps the existing text, and a=
dds some new (<new></new>).<=
o:p>
 <=
/o:p>
Update to=
 4th paragraph of section 5.1.1=

 
 
OLD TEXT (RFC 5761):

 


   If the answer does not contai=
n an "a=3Drtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


NEW TEXT (RF=
C 8035):


  =
 If the answer does not contain an "a=3Drtcp-mux" attribute, the =
offerer


   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


As we can se=
e, the original text is identical in 5761 and 8035. So, there is no clash. =
So far so good.


draft-mux-ex=
clusive keeps the existing text, and adds some new (<new></new>=
).


 <=
/o:p>


NEW TEXT (dr=
aft-mux-exclusive):


 


   If the answer does not contai=
n an "a=3Drtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signaled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute. <new> However, if the offerer indicated in the offer t=
hat it is


   not able to send and receive RT=
CP on a separate port, the offerer<=
/o:p>


   MUST disable the media streams =
associated with the attribute. The<=
/o:p>


   mechanism for indicating that t=
he offerer is not able to send and<=
/o:p>


   receive RTCP on a separate port=
 is outside the scope of this=



   specification.</new>




 






Now, the issue is that, following the upda=
te in RFC 8035, the text is no longer within the 4th paragraph of section 5=
.1.1. So, should we:






 






1) &nb=
sp;    within draft-mux-exclusive, indicate that both=
 RFC 5761 and RFC 8035 are updated; or






2)  &n=
bsp;   within draft-mux-exclusive, add a note indicating w=
hich paragraph is affected following the update in RFC 8035






3) &nb=
sp;    within draft-mux-exclusive, ONLY update RFC 80=
35; or






4) &nb=
sp;    o nothing






 






My first reaction would be to go for optio=
n 2), as there IMO is no reason to formally update the text in RFC 8035. 






 






Regards,






 






Christer






 






 
--_000_SN2PR03MB235005FC1457A7225FBFC6BFB2170SN2PR03MB2350namp_-- From nobody Tue May 2 09:57:45 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F043D1200FC for ; Tue, 2 May 2017 09:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zicMDJ7NarJc for ; Tue, 2 May 2017 09:57:41 -0700 (PDT) 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 839BA127B52 for ; Tue, 2 May 2017 09:55:19 -0700 (PDT) X-AuditID: c1b4fb25-0a3ff70000006049-16-5908b9f5e5a3 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EF.E5.24649.5F9B8095; Tue, 2 May 2017 18:55:17 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0339.000; Tue, 2 May 2017 18:55:17 +0200 From: Christer Holmberg To: "Asveren, Tolga" , "mmusic@ietf.org" Thread-Topic: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Thread-Index: AQHSwAW/bFONqGwgCkelI/jotUkR9KHgWM/ggAB0kICAABMnMIAAGreAgAAoz6CAACVHwA== Date: Tue, 2 May 2017 16:55:16 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB8F933@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB8F933ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbHdUvfrTo5Ig9O7zSymLn/MYjG78z2T A5PHkiU/mTwuff7PHsAUxWWTkpqTWZZapG+XwJXR9aqbrWDpAqaKNWumMzUwfvnN2MXIySEh YCJx7fZj5i5GLg4hgSOMElMOPWUDSQgJLGaUeDYhrIuRg4NNwEKi+582SFhEIFjiecMPJhBb WMBNonfLBWaIuLtEy9LFjBB2mMT5JSvBalgEVCRmt/4Cq+EV8JU4fGU2G8SuGcwSj85sB2vg FIiV+HuoH2wvo4CYxPdTa8CamQXEJW49mc8EcaiAxJI955khbFGJl4//sULYShKNS56wQtTn Szy59BJqmaDEyZlPWCYwCs9CMmoWkrJZSMog4joSC3Z/YoOwtSWWLXzNDGOfOfCYCVl8ASP7 KkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAGDq45bfqDsbLbxwPMQpwMCrx8CbYs0cKsSaW FVfmHmKU4GBWEuH13MwRKcSbklhZlVqUH19UmpNafIhRmoNFSZzXcd+FCCGB9MSS1OzU1ILU IpgsEwenVANj2KeFDso/MjKLtLfn6P97tmRJh9aRpY0u6cG1Gwo91vRWWX52qjXSL03zqXfM n+Z7RYnTMvzxR/PUi4du/fAKWxWVcvjyudz4RpuEv9JqEt4tStyK4rWd3G1/Jkz/fnz1kgWH 5/JpPzq9LP1n9E7XxiP96cfm1e9ZY8cfb17qIHOhc/Md5TwlluKMREMt5qLiRABWOC8pnQIA AA== Archived-At: Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 16:57:44 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB8F933ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Previously in 5761 the offerer must always be able to fallback to non-mux. = The text was added to clarify that there may be cases where that is not the= case. Regards, Christer From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: 02 May 2017 16:52 To: Christer Holmberg ; mmusic@ietf.org Subject: RE: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Honestly that agreement sounds a bit weird to me. Certain semantics associa= ted with a non-specified indicator is added as an update to RFC5761 but the= actual indicator and the rest of semantics are missing. If one wants to pu= rsue the "update RFC5761" path, IMHO the more reasonable approach would be = to define the whole content of rtcp-mux-exclusive as an update to RFC5761. = And just to reiterate, I would say that not updating RFC5761 and keeping ev= erything as newly defined capability in rtcp-mux-only would be my preferenc= e. I am also not sure whether RFC8035 update wouldn't imply that stream must b= e disabled in such a case. What else could be done? Isn't this the standard= behavior if negotiation for any stream fails? RFC4566 6 Generating the Answer .... An offered stream MAY be rejected in the answer, for any reason. If a stream is rejected, the offerer and answerer MUST NOT generate media (or RTCP packets) for that stream. To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 7:10 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, >I got your point but that made me think about a more fundamental issue: Do= es draft-mux-exclusive indeed update RFC5761? >IMHO it is not. It defines a new indicator with its own semantics. This is= a new capability, not something changing a capability already defined. And >it seems "backward compatibility concerns" are already addressed in a reas= onable way by mux-exclusive and RFC8035 updates on RFC5761. > >So, I would: >i- Remove "Updates: RFC5761" statement from the prologue >ii- Remove Section 5. > >If you still want to keep rtcp-mux-exclusive as an "update on RFC5761", th= en 2) sounds reasonable to me as well. It was previously agreed to add the text to draft-mux-exclusive= , so I don't want to change that at this point. At the end of the day, it's= just a clarification specifying that if there is SOME mechanism to indicat= e that separate ports cannot be used, the stream must be disabled. Unfortun= ately, the RFC8035 update does not add such specification. Option 2) would be adding something like this to draft-mux-exclusive: "NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the paragraph u= pdated in this document is not updated by RFC8035, the location of the para= graph within section 5.1.1 is moved." Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 4:25 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, >i- "rtcp-mux-exclusive" is a new capability/indication, not an update on R= FC5761/8035 per se. >ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional= . >iii- rtcp-mux-exclusive is defined as bidirectional. > >Adding all these together, I fail to see the rationale behind the text. Therefore, I think "4) Do Nothing" is the way to go here. Note that the text is already in draft-mux-exclusive, and optio= n 4) would not remove it. The issue is that, based on the update in RFC8035, the text is no longer wi= thin the "4th paragraph", as RFC8035 adds new paragraphs, and my question i= s whether we should somehow point that out within draft-mux-exclusive. >OTOH, I still think that draft-mux-exclusive explicitly should indicate th= at "rtcp-mux-exclusive itself is bidirectional" and that RFC8035 updated RF= C5761 to clarify that "rtcp-mux is birectional". I think we should look at that suggestion (which, btw, I think seems reason= able) as a separate thing. THIS issue is more administrative. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Friday, April 28, 2017 5:57 AM To: mmusic@ietf.org Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also u= pdates section 5.1.1 of RFC 8035. draft-mux-exclusive keeps the existing text, and adds some new (= ). Update to 4th paragraph of section 5.1.1 OLD TEXT (RFC 5761): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. NEW TEXT (RFC 8035): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. As we can see, the original text is identical in 5761 and 8035. So, there i= s no clash. So far so good. draft-mux-exclusive keeps the existing text, and adds some new (= ). NEW TEXT (draft-mux-exclusive): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signaled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. However, if the offerer indicated in the offer that it = is not able to send and receive RTCP on a separate port, the offerer MUST disable the media streams associated with the attribute. The mechanism for indicating that the offerer is not able to send and receive RTCP on a separate port is outside the scope of this specification. Now, the issue is that, following the update in RFC 8035, the text is no lo= nger within the 4th paragraph of section 5.1.1. So, should we: 1) within draft-mux-exclusive, indicate that both RFC 5761 and RFC 803= 5 are updated; or 2) within draft-mux-exclusive, add a note indicating which paragraph i= s affected following the update in RFC 8035 3) within draft-mux-exclusive, ONLY update RFC 8035; or 4) o nothing My first reaction would be to go for option 2), as there IMO is no reason t= o formally update the text in RFC 8035. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4CB8F933ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Previously in 5761 the offerer must always be able to fallback to non-= mux. The text was added to clarify that there may be cases where that is no= t the case.

 

Regards,

 

Christer

 

From: Asveren, Tolga [mailto:tasveren@sonusnet.com]
Sent: 02 May 2017 16:52
To: Christer Holmberg <christer.holmberg@ericsson.com>; mmusic= @ietf.org
Subject: RE: RFC 5761 updated by both draft-mux-exclusive and RFC 80= 35

 

Honestly that agreement sounds = a bit weird to me. Certain semantics associated with a non-specified indica= tor is added as an update to RFC5761 but the actual indicator and the rest = of semantics are missing. If one wants to pursue the “update RFC5761” path, IMHO the more reasonable = approach would be to define the whole content of rtcp-mux-exclusive as an u= pdate to RFC5761. And just to reiterate, I would say that not updating RFC5= 761 and keeping everything as newly defined capability in rtcp-mux-only would be my preference.

 

I am also not sure whether RFC8= 035 update wouldn’t imply that stream must be disabled in such a case= . What else could be done? Isn’t this the standard behavior if negoti= ation for any stream fails?

 

RFC4566

 

6 Generating the Answer

 

….

 

   An offered stream MAY be = rejected in the answer, for any reason.  If

   a stream is rejected, the offe= rer and answerer MUST NOT generate

   media (or RTCP packets) for th= at stream.  To reject an offered

   stream, the port number in the= corresponding stream in the answer

   MUST be set to zero.

 

 

Thanks,

Tolga

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, May 2, 2017 7:10 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 80= 35

 

Hi,

 

>I got= your point but that made me think about a more fundamental issue: Does dra= ft-mux-exclusive indeed update RFC5761?

>IMHO = it is not. It defines a new indicator with its own semantics. This is a new= capability, not something changing a capability already defined. And

>it seems R= 20;backward compatibility concerns” are already addressed in a reason= able way by mux-exclusive and RFC8035 updates on RFC5761.

> = ;

>So, I= would:

>i- Re= move “Updates: RFC5761” statement from the prologue<= /span>

>ii- R= emove Section 5.

>=  

>If yo= u still want to keep rtcp-mux-exclusive as an “update on RFC5761̶= 1;, then 2) sounds reasonable to me as well.

 

It was previously agreed to add the <new></new> text to= draft-mux-exclusive, so I don’t want to change that at this point. A= t the end of the day, it’s just a clarification specifying that if there is SOME mechanism to indicate that separate ports cannot be = used, the stream must be disabled. Unfortunately, the RFC8035 update does n= ot add such specification.

 

Option 2) would be adding something like this to draft-mux-exclusiv= e:

 

"NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While th= e paragraph updated in this document is not updated by RFC8035, the locatio= n of the paragraph within section 5.1.1 is moved."

 

Regards,

 

Christer

 

 

 

 =

From:<= /span> Christer Holmberg [mailto:christer.holmberg@er= icsson.com]
Sent: Tuesday, May 2, 2017 4:25 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 80= 35

 

Hi,

 =

>i- &#= 8220;rtcp-mux-exclusive” is a new capability/indication, not an updat= e on RFC5761/8035 per se.

>ii- R= FC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional.=

>iii- = rtcp-mux-exclusive is defined as bidirectional.

> = ;

>Addin= g all these together, I fail to see the rationale behind the <new><= ;/new> text. Therefore, I think “4) Do Nothing” is the way t= o go here.

 

Note that the <new></new> text is already in draft-mux-= exclusive, and option 4) would not remove it. 

 =

The issue is that, based on the update in RFC8035, the text is no l= onger within the “4th paragraph”, as RFC8035 adds new paragraph= s, and my question is whether we should somehow point that out within draft-mux-exclusive.

 =

>OTOH,= I still think that draft-mux-exclusive explicitly should indicate that = 220;rtcp-mux-exclusive itself is bidirectional” and that RFC8035 upda= ted RFC5761 to clarify that “rtcp-mux is birectional”.

 =

I think we should look at that suggestion (which, btw, I think seem= s reasonable) as a separate thing. THIS issue is more administrative.

 =

Regards,

 =

Christer

 =

 

From:<= /span> mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: mmusic@ietf.org
Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and R= FC 8035

 

Hi,<=
/span>
draft-mux-exclusive updates section 5.1.1 of RFC 5761. N=
ow, RFC 8035 also updates section 5.1.1 of RFC 8035.
draft-mux-exclusive keeps the exist=
ing text, and adds some new (<new></new>).
 
Update to 4th paragraph of section 5.1.1
 

 

OLD TEXT (RFC 5761):


 

   If the answer =
does not contain an "a=3Drtcp-mux" attribute, the offerer


   MUST NOT multi=
plex RTP and RTCP packets on a single port.  Instead,


   it should send=
 and receive RTCP on a port allocated according to the

   usual port-sel=
ection rules (either the port pair, or a signalled port

   if the "a=
=3Drtcp:" attribute [10] is also included).  This will occur=



   when talking t=
o a peer that does not understand the "a=3Drtcp-mux"


   attribute.


 


NEW TEXT (RFC 8035):


   If the answer does not contain an "a=3Drtcp-mux" =
attribute, the offerer


   MUST NOT multi=
plex RTP and RTCP packets on a single port.  Instead,


   it should send=
 and receive RTCP on a port allocated according to the

   usual port-sel=
ection rules (either the port pair, or a signalled port

   if the "a=
=3Drtcp:" attribute [10] is also included).  This will occur=



   when talking t=
o a peer that does not understand the "a=3Drtcp-mux"


   attribute.


 


As we can see, the original text is identical in 5761 and 8035. So, ther=
e is no clash. So far so good.


draft-mux-exclusive keeps the existing text, and adds some new (<new&=
gt;</new>).


 


NEW TEXT (draft-mux-exclusive):


 

   If the answer =
does not contain an "a=3Drtcp-mux" attribute, the offerer


   MUST NOT multi=
plex RTP and RTCP packets on a single port.  Instead,


   it should send=
 and receive RTCP on a port allocated according to the

   usual port-sel=
ection rules (either the port pair, or a signaled port

   if the "a=
=3Drtcp:" attribute [10] is also included).  This will occur=



   when talking t=
o a peer that does not understand the "a=3Drtcp-mux"


   attribute. <=
;new> However, if the of=
ferer indicated in the offer that it is


   not able to send=
 and receive RTCP on a separate port, the offerer


   MUST disable the=
 media streams associated with the attribute. The


   mechanism for in=
dicating that the offerer is not able to send and


   receive RTCP on =
a separate port is outside the scope of this


   specification.&l=
t;/new>




 





Now, the issue is that, fol=
lowing the update in RFC 8035, the text is no longer within the 4th paragra=
ph of section 5.1.1. So, should we:






 





1)      within draft-mux-exclusive, ind=
icate that both RFC 5761 and RFC 8035 are updated; or





2)      within draft-mux-exclusive, add a no=
te indicating which paragraph is affected following the update in RFC 8035<=
o:p>






3)      within draft-mux-exclusive, ONL=
Y update RFC 8035; or






4)      o nothing





 





My first reaction would be =
to go for option 2), as there IMO is no reason to formally update the text =
in RFC 8035. 






 





Regards,<=
/pre>





 





Christer<=
/pre>





 





 
--_000_7594FB04B1934943A5C02806D1A2204B4CB8F933ESESSMB109erics_-- From nobody Tue May 2 10:01:52 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1464B126CF9 for ; Tue, 2 May 2017 10:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 rNU5yS1hg5Mx for ; Tue, 2 May 2017 10:01:47 -0700 (PDT) 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 6F7AA12EBF7 for ; Tue, 2 May 2017 09:58:47 -0700 (PDT) X-AuditID: c1b4fb30-663149a00000015f-35-5908bac5ffe3 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D8.72.00351.5CAB8095; Tue, 2 May 2017 18:58:45 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0339.000; Tue, 2 May 2017 18:58:42 +0200 From: Christer Holmberg To: "Asveren, Tolga" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? Thread-Index: AQHSvOgCNt6Dk7x2uEaNj1LXZRgEJKHUeB1AgAyW1oCAABq+MIAAJkiw Date: Tue, 2 May 2017 16:58:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB8F961@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB8F961ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbHdUvfoLo5Ig+7dphZTlz9msZjd+Z7J gcljyZKfTB6XPv9nD2CK4rJJSc3JLEst0rdL4Mp4MPM5Y0HHasaKB9MuMzYwfp7O2MXIySEh YCLx+eQT5i5GLg4hgSOMEs0HNzFCOIsZJXomrGHtYuTgYBOwkOj+pw3SICIQLPG84QcTiC0s ECSxavlxNpj4tUX7GSFsN4n7bV9YQGwWARWJpR2rWEDG8Ar4SuydJwAxfjKTxPzDM8DqOQVi JT6dOMIKYjMKiEl8P7UGbD6zgLjErSfzmSAOFZBYsuc8M4QtKvHy8T9WCFtJonHJE1aI+nyJ qU3TwGxeAUGJkzOfsExgFJ6FZNQsJGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2 VYyixanFSbnpRkZ6qUWZycXF+Xl6eaklmxiBMXRwy2+DHYwvnzseYhTgYFTi4U2wZ48UYk0s K67MPcQowcGsJMLruZkjUog3JbGyKrUoP76oNCe1+BCjNAeLkjiv474LEUIC6YklqdmpqQWp RTBZJg5OqQbGwGvPrbg5HK02X1BrnCs0QYJ5cUj8tP4p2dJiu7SOHmeV2iw799wcseaLkTyf +upa1liW//1WnHpQ9RSfiIJHQmNRZ1Sv489Z32Y7WYX877/8vSe9kym0ad3ZtgkMtdIpux13 mGl2PUy99prrhtfluiDWoIoNC+bURkxcNrOFafeLDXfC3/1WYinOSDTUYi4qTgQAvu/XU50C AAA= Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 17:01:51 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB8F961ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, >Yes agreed. All I am asking for is a sentence to prevent confusion: > >"It should be noted that both rtcp-mux (per updates in RFC8035) and rtcp-m= ux-only >have bidirectional semantics. They are either accepted and used by= both sides or not at >all." The only semantics of a=3Drtcp-mux-only is to indicate that one is not able= to fallback to non-mux. a=3Drtcp-mux is used to negotiate the actual mux. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 7:58 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Hi, I took a look at this again. I am not sure I understand what it meant by rt= cp-mux-only being bidirectional. If rtp/rtcp-mux is negotiated, it will be bidirectional according to RFC803= 5. Note that, with rtcp-mux-only, you still need to include a=3Drtcp-mux, s= o the bidirectional rules associated with rtcp-mux still apply. Regards, Christer From: Tolga Asveren > Date: Monday 24 April 2017 at 21:29 To: Christer Holmberg >, "mmusic@ietf.org" > Subject: RE: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Thanks for pointing this out. The issue still would be applicable for alrea= dy deployed RFC5761 compliant/RFC8035 non-compliant entities. Therefore IMH= O it could be a good idea to explicitly mention that "rtcp-mux-only" is bid= irectional as "rtcp-mux" per RFC8035. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, April 24, 2017 6:46 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Hi, RFC 5761 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.t= xt), where we clarify that negotiated mux is always bidirectional. "This document updates RFC 5761 [RFC5761] by clarifying that an answerer can only include an "a=3Drtcp-mux" attribute in an answer if the associated offer contained the attribute. It also clarifies that the negotiation of RTP and RTCP multiplexing is for usage in both directions." Regards, Christer From: mmusic > on b= ehalf of Tolga Asveren = > Date: Monday 24 April 2017 at 13:24 To: "mmusic@ietf.org" > Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional= ? It seems draft-ietf-mmusic-mux-exclusive-11 assumes that mux support will b= e always bidirectional. OTOH, I think RFC5761 allows unidirectional semanti= cs: 5.1.1. SDP Signaling ... When SDP is used in a declarative manner, the presence of an "a=3Drtcp- mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth. Actually this part of RFC5761 sounds a bit odd as in declarative mode I tho= ught an attribute would convey information about the "receipt properties" t= herefore "rtcp-mux" would mean that the sender wants to receive RTP/RTCP mu= ltiplexed on the same port. It could be good to explicitly state in draft-ietf-mmusic-mux-exclusive tha= t unidirectional multiplexing with declarative mode is not supported. Example scenario: A sends rtcp-mux/rtcp-mux-only B does not support rtcp-mux-only and ignores it. It interprets rtcp-mux in = declarative mode and is ready to receive RTP/RTCP on the same port. OTOH, i= t does not want to send multiplexed RTP/RTCP hence does not include rtcp-mu= x in the reply. A terminates the session because the answer does not contain rtcp-mux. It c= an't determine whether multiplexing is not supported at all or whether B wa= nts to use it in a unidirectional way. Thanks, Tolga --_000_7594FB04B1934943A5C02806D1A2204B4CB8F961ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

>Yes agreed. All I am asking for is a sentence to p= revent confusion:

> 

>“It should be noted that both rtcp-mux (per = updates in RFC8035) and rtcp-mux-only >have bidirectional semantics. They= are either accepted and used by both sides or not at >all.”

&n= bsp;

The onl= y semantics of a=3Drtcp-mux-only is to indicate that one is not able to fal= lback to non-mux. a=3Drtcp-mux is used to negotiate the actual mux.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, May 2, 2017 7:58 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

 

Hi,

 

I took a look at this again. I am not sure I understand what it mea= nt by rtcp-mux-only being bidirectional.

 

If rtp/rtcp-mux is negotiated, it will be bidirectional according t= o RFC8035. Note that, with rtcp-mux-only, you still need to include a=3Drtc= p-mux, so the bidirectional rules associated with rtcp-mux still apply.

 

Regards,

 

Christer

 

 

From: = Tolga Asveren <tasveren@sonusnet.com>
Date: Monday 24 April 2017 at 21:29
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: RE: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

 

Thanks fo= r pointing this out. The issue still would be applicable for already deploy= ed RFC5761 compliant/RFC8035 non-compliant entities. Therefore IMHO it coul= d be a good idea to explicitly mention that “rtcp-mux-only” is bidirectional as “rtcp-mux”= ; per RFC8035.

 

Thanks,

Tolga

 

From:<= /span> Christer Holmberg [mailto:christer.holmberg@er= icsson.com]
Sent: Monday, April 24, 2017 6:46 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

 

Hi,

 =

RFC 5761 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.txt), where w= e clarify that negotiated mux is always bidirectional.

 = 

   "This document updates RFC 5761 [RFC5761] by clarifyin=
g that an
   answerer can o=
nly include an "a=3Drtcp-mux" attribute in an answer if
   the associated=
 offer contained the attribute.  It also clarifies that
   the negotiatio=
n of RTP and RTCP multiplexing is for usage in both
   directions.&qu=
ot;

 =

Regards,

 =

Christer

 =

From: = mmusic <mmusic-bounces@ietf.org> on behalf = of Tolga Asveren <tasveren@sonu= snet.com>
Date: Monday 24 April 2017 at 13:24
To: "mmusic@ietf.org&quo= t; <mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidire= ctional?

 =

It seems = draft-ietf-mmusic-mux-exclusive-11 assumes that mux support will be always = bidirectional. OTOH, I think RFC5761 allows unidirectional semantics:<= /o:p>

 

5.1.1. SD= P Signaling

…

 

   When SDP is used i= n a declarative manner, the presence of an "a=3Drtcp-

   mux" attribut= e signals that the sender will multiplex RTP and RTCP on

   the same port.&nbs= p; The receiver MUST be prepared to receive RTCP packets

   on the RTP port, a= nd any resource reservation needs to be made

   including the RTCP= bandwidth.

 

Actually = this part of RFC5761 sounds a bit odd as in declarative mode I thought an a= ttribute would convey information about the “receipt properties”= ; therefore “rtcp-mux” would mean that the sender wants to receive RTP/RTCP multiplexed on the same port.<= /p>

 

It could = be good to explicitly state in draft-ietf-mmusic-mux-exclusive that unidire= ctional multiplexing with declarative mode is not supported.

 

Example s= cenario:

A sends r= tcp-mux/rtcp-mux-only

B does no= t support rtcp-mux-only and ignores it. It interprets rtcp-mux in declarati= ve mode and is ready to receive RTP/RTCP on the same port. OTOH, it does no= t want to send multiplexed RTP/RTCP hence does not include rtcp-mux in the reply.

A termina= tes the session because the answer does not contain rtcp-mux. It can’= t determine whether multiplexing is not supported at all or whether B wants= to use it in a unidirectional way.

 

Thanks,

Tolga

--_000_7594FB04B1934943A5C02806D1A2204B4CB8F961ESESSMB109erics_-- From nobody Tue May 2 16:43:27 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0916129AE3 for ; Tue, 2 May 2017 16:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 G7_mTX0FMtMv for ; Tue, 2 May 2017 16:43:23 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 6BD20129BA2 for ; Tue, 2 May 2017 16:42:04 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id e55so62778554uaa.2 for ; Tue, 02 May 2017 16:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=1iSTAw3jvC9m96sNJcp6wxhQym4DskJQAv4wUsilgUo=; b=PxJLXFKCuzR5Cmn7Zu+jI5BKpZ0VnLqAGNzMSXmMfBd3bMfh4cmVLuDLXSAR8vRbvM Tl2/XSDkZUoDzb87V8iUoWnF/1Sij5DxWunlFKd7SCFH8yi0n2HvSfz6ReivN54lxpFj 7vKDJHNwAW8kUByUJhWoM7CbXlQZXCNFvXZqgBYBQk2TByhpTlNP5X6vDAR6XGPiO0So cAlCCKP9guj2zAADfcvH50fBOx8RXJEYWFwgzGTl/redBeQ2pZ2/hgaBsKKZMwZecXTE 0O5VO0ZjNzSatr+HKsPCE2oUPLa4nm9K5zwV4RKIvbrgyRXFZzO0988FaeVCLq6kiQA1 NdpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=1iSTAw3jvC9m96sNJcp6wxhQym4DskJQAv4wUsilgUo=; b=XI+dP/NmyGXc4Vebr/nab87O9VEesg74qxsXwwWpd+HwrMaC5MWh0grtIYFOd8I00w tOFeSZ32ImuOBlk5VGIkwi4xctd3VPGttlaTv0rSSFPJi3FkOdaJy7h4l0GTZ/RLVXXE OyLIdPj7eTGH07Aok7858cfpiRRM99Z98Nseaj3csVYRkWqRng1yhUHqO/KQ3YD66Hq9 VRfB+9lVYUd4dmipyOhoxt3W7cuz/9G79742/7zUTb66PyikgNOTr5CpT5JzNJ6/TrqU OUmMZwqQ/j+5e7ixMp1g3gOvb8l0V+D6dU0uHtyAR4Ur17c4JmLS5jv57lOsgjQvxR3t BEgg== X-Gm-Message-State: AN3rC/5jSIe8R9r0VNXz/PyKwcL1yB7UCcUzfVY+LQjBS6AHC7Mto7bn v6uxPrlOfETTxCclMAlbzk6GfFDU0g== X-Received: by 10.159.34.196 with SMTP id 62mr16960507uan.42.1493768523200; Tue, 02 May 2017 16:42:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.49.18 with HTTP; Tue, 2 May 2017 16:41:42 -0700 (PDT) From: Bernard Aboba Date: Tue, 2 May 2017 16:41:42 -0700 Message-ID: To: mmusic@ietf.org Content-Type: multipart/alternative; boundary=94eb2c03c91033c009054e9316e2 Archived-At: Subject: Re: [MMUSIC] starting DTLS handshake before the answer is received (dtls-sdp draft) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 May 2017 23:43:27 -0000 --94eb2c03c91033c009054e9316e2 Content-Type: text/plain; charset=UTF-8 Roman Shpount said: "We also are planning to update the dtls-sdp draft which will prohibit to start DTLS handshake until the answer is received." [BA] The logic here is that in WebRTC an incoming DTLS packet cannot be responded to until "consent" is provided, which requires an ICE request and response, which needs the remote ICE ufrag/password, which is in the answer. While I can understand explaining this in the dratf, a prohibition seems redundant, because it already follows from other requirements (such as consent and full ICE). It's a bit like passing a law prohibiting objects in earth's gravity from "falling up" - gravity just doesn't work that way, so no need for a law. Also, there can be situations with ICE lite, or with ORTC where ICE O/A could be separated from DTLS O/A), so consent could exist prior to receipt of the DTLS answer, where the original logic wouldn't hold. --94eb2c03c91033c009054e9316e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Roman Shpount said:=C2=A0

"We also= are planning to update the dtls-sdp draft which will prohibit to start DTL= S handshake until the answer is received."

[B= A] The logic here is that in WebRTC an incoming DTLS packet cannot be respo= nded to until "consent" is provided, which requires an ICE reques= t and response, which needs the remote ICE ufrag/password, which is in the = answer.=C2=A0

While I can understand explaining th= is in the dratf, =C2=A0a prohibition seems redundant, because it already fo= llows from other requirements (such as consent and full ICE).=C2=A0 It'= s a bit like passing a law prohibiting objects in earth's gravity from = "falling up" - gravity just doesn't work that way, so no need= for a law.

Also, there can be situations with ICE= lite, or with ORTC where ICE O/A could be separated from DTLS O/A), so con= sent could exist prior to receipt of the DTLS answer, where the original lo= gic wouldn't hold.=C2=A0
--94eb2c03c91033c009054e9316e2-- From nobody Tue May 2 17:52:14 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC1D12E055 for ; Tue, 2 May 2017 17:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.51 X-Spam-Level: X-Spam-Status: No, score=0.51 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 1a5JYKG2W2Ag for ; Tue, 2 May 2017 17:52:09 -0700 (PDT) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 DCE2C126DEE for ; Tue, 2 May 2017 17:49:25 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id e64so4798920pfd.1 for ; Tue, 02 May 2017 17:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4bTeZ9nwVwD81fXtlc77LtSS0JpsFTbCSANMdE5b/4M=; b=OEX65faDclW8vuN21qTdhMtvHiBHPG45UIO4xeRXi9D5ImXN4fLhJxrNd3oR+TbJ6s jA6spY+UbJC4VRhs7dAp6P+38hv86Wi/xlAoE1eWVOtf/sSsvwXYFHdvEqvUpTiEz/JR MScosMPKrzz85LQGXFTgh464l/b8hDsoCxNEVQLdfUe/tqsIp2Fci+6mjOZmTHADL04A w3dMNignxHh9aV07CBOrsYVLFzIsFDHaG6JEtPezaf6NboOvazAvAXMHz5yO63DRqbks aE5kh6naYdOBuMdZ2N69jSw5J3fLxl8SJ89Zk9NPUegw4WKRxhH3VR2cKnpFbubI3F1k UwqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4bTeZ9nwVwD81fXtlc77LtSS0JpsFTbCSANMdE5b/4M=; b=ZN/LuDszxv/uwyTBrcEfMwXbJPeCqHCuL0hfoZ1aF49w2UaZANDJe82Y6KBUwfjtdY VvVZ7lDV/MhL1J7KrsgKyx/PbnUCaYGSw/EQNuoGoVYinQ4V8Wrc+lU7MAhtOvckTT77 gLdjxnuqksBDsts5wylEHQnoyuYt1i1SbCDz0n+w/C9gAoQ5CJEV0nkn7f21SCEb4llx B/pyS20I0ntmIXxkY21rtJ7nXn+PPOlCmwHCXWJqTFPYBP5wkNtyJWPAPqgwJt0tRtp5 tL6QIqgHkvZsgUoIDerSeqzJ0aCs5MtONTdN1UWFturdNQkj5zcuIlahofrfee3zcy6l dl/Q== X-Gm-Message-State: AN3rC/6QKxNB+25zIvGzRVQExOurMtH6NnuAF4iZmtyHwG8hAPGkBKcn 5agiST7cYocZU4h0 X-Received: by 10.99.61.134 with SMTP id k128mr1134056pga.201.1493772565212; Tue, 02 May 2017 17:49:25 -0700 (PDT) Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com. [209.85.192.173]) by smtp.gmail.com with ESMTPSA id 63sm1029205pfg.35.2017.05.02.17.49.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 17:49:24 -0700 (PDT) Received: by mail-pf0-f173.google.com with SMTP id e64so4798754pfd.1 for ; Tue, 02 May 2017 17:49:24 -0700 (PDT) X-Received: by 10.98.85.6 with SMTP id j6mr1882343pfb.31.1493772564179; Tue, 02 May 2017 17:49:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.150 with HTTP; Tue, 2 May 2017 17:49:23 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Tue, 2 May 2017 20:49:23 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Bernard Aboba Cc: "mmusic@ietf.org" , Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c0cc6dc103860054e9407ac Archived-At: Subject: Re: [MMUSIC] starting DTLS handshake before the answer is received (dtls-sdp draft) X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 00:52:11 -0000 --94eb2c0cc6dc103860054e9407ac Content-Type: text/plain; charset=UTF-8 On Tue, May 2, 2017 at 7:41 PM, Bernard Aboba wrote: > Roman Shpount said: > > "We also are planning to update the dtls-sdp draft which will prohibit to > start DTLS handshake until the answer is received." > > [BA] The logic here is that in WebRTC an incoming DTLS packet cannot be > responded to until "consent" is provided, which requires an ICE request and > response, which needs the remote ICE ufrag/password, which is in the > answer. > > While I can understand explaining this in the dratf, a prohibition seems > redundant, because it already follows from other requirements (such as > consent and full ICE). It's a bit like passing a law prohibiting objects > in earth's gravity from "falling up" - gravity just doesn't work that way, > so no need for a law. > > Also, there can be situations with ICE lite, or with ORTC where ICE O/A > could be separated from DTLS O/A), so consent could exist prior to receipt > of the DTLS answer, where the original logic wouldn't hold. > This is exactly the reason we are adding this restriction. In cases of ICE-lite or symmetric UDP, it is possible for DTLS handshake to complete before the answer is received. This brings up the question of handling unverified media. This also does not work well with https://datatracker.ietf.org/doc/html/draft-thomson-mmusic-sdp-uks. It can cause end point to go through an handshake with potential attacker which did not place the call, which creates an interesting possibility for DOS attack where end point can be sprayed with ClientHello messages which will cause handshake, but will not be associated with the actual call. Our assumption was, since DTLS handshake cannot continue in most common cases (full ICE and "proper" UDP where remote IP is not known until answer is received), in order to make protocol negotiation more consistent we should prohibit DTLS handshake before the answer is received in less common cases such as ICE-lite and "symmetric" UDP. Regards, _____________ Roman Shpount --94eb2c0cc6dc103860054e9407ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 2, 2017 at 7:41 PM, Bernard Abo= ba <bernard.aboba@gmail.com> wrote:
=
Roman Shpount said:=C2=A0

"We also= are planning to update the dtls-sdp draft which will prohibit to start DTL= S handshake until the answer is received."

[B= A] The logic here is that in WebRTC an incoming DTLS packet cannot be respo= nded to until "consent" is provided, which requires an ICE reques= t and response, which needs the remote ICE ufrag/password, which is in the = answer.=C2=A0

While I can understand explaining th= is in the dratf, =C2=A0a prohibition seems redundant, because it already fo= llows from other requirements (such as consent and full ICE).=C2=A0 It'= s a bit like passing a law prohibiting objects in earth's gravity from = "falling up" - gravity just doesn't work that way, so no need= for a law.

Also, there can be situations with ICE= lite, or with ORTC where ICE O/A could be separated from DTLS O/A), so con= sent could exist prior to receipt of the DTLS answer, where the original lo= gic wouldn't hold.=C2=A0

This is exactly the= reason we are adding this restriction. In cases of ICE-lite or symmetric U= DP, it is possible for DTLS handshake to complete before the answer is rece= ived. This brings up the question of handling unverified media. This also d= oes not work well with=C2=A0https://datatracker.ietf.org/doc/html/draft-thom= son-mmusic-sdp-uks. It can cause end point to go through an handsh= ake with potential attacker which did not place the call, which creates an = interesting possibility for DOS attack where end point can be sprayed with = ClientHello messages which will cause handshake, but will not be associated= with the actual call.

Our assumption was, since DTLS handshake cannot continue i= n most common cases (full ICE and "proper" UDP where remote IP is= not known until answer is received), in order to make protocol negotiation= more consistent we should prohibit DTLS handshake before the answer is rec= eived in less common cases such as ICE-lite and "symmetric" UDP.<= /div>

Regard= s,
_____________
Roman Shpount

<= /div>
--94eb2c0cc6dc103860054e9407ac-- From nobody Wed May 3 09:16:55 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90C2129516; Wed, 3 May 2017 09:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 EoSUJYv9Sw9i; Wed, 3 May 2017 09:16:50 -0700 (PDT) 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 1CF0C129B23; Wed, 3 May 2017 09:14:48 -0700 (PDT) X-AuditID: c1b4fb3a-f56d89a000005025-76-590a01f7b3da Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3F.04.20517.7F10A095; Wed, 3 May 2017 18:14:47 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.339.0; Wed, 3 May 2017 18:14:46 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qoF2pxTDYqebetf4ONpkcliycn93tIsP0e7pGO6XAYw=; b=DcvODzIJ7r/KkC42uS5JNizVdaKxmaJU1zkHK7Q+IEwmBuxf9dD3PrTLtNiCN2icFUKM47QJSsP1PZJiU5d1kpgqFN31guO/4sypSMOD5adFH7vRVW9YN9ZjeK4y9xSV2gvJysf6pqdsp11ArM+5N1i6ltqvFzf0ztRU7HdSyhc= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2580.eurprd07.prod.outlook.com (10.173.92.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.1; Wed, 3 May 2017 16:14:45 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.1075.010; Wed, 3 May 2017 16:14:45 +0000 From: Bo Burman To: "Arun Arunachalam (carunach)" , "mmusic (mmusic@ietf.org)" CC: "Flemming Andreasen (fandreas)" , "draft-ietf-mmusic-sdp-simulcast.authors@ietf.org" Thread-Topic: Review: draft-ietf-mmusic-sdp-simulcast Thread-Index: AQHSqZ1LgElfJhuy3UubAvb9EhsTOqGt6dmAgA8E2ICAJefu4A== Date: Wed, 3 May 2017 16:14:45 +0000 Message-ID: References: <6351CDC7-7925-4448-A39E-56FCC9F2B12C@cisco.com> <991504f1-bb9c-17c7-432f-a53154d2da33@cisco.com> <344988B5-DEF9-41A4-BC15-7D8E07A22448@cisco.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2580; 7:YXWWyyyzrkZzjmGVroknJ2d16Vr/DWTQYT7LV8P4IGzLU6G2r+4N7gzEIrbhFwBDvuUdruTadjZPx5EcYgDUrt1Ivlc8ObrKYEGZYjJV7CE9SjWSYHkq/IV36AIQzYLGiLKfjnYjzibMd0FIemZFORu2BHoCZzPJBSjkT78GAK3gwY9sZSJxTG35ekGo+3xORgxNI06EWG5aOYNvv+GT4acIlcRHuGqPddwqgodmthX3UPhESPZzks0noNcVUwYygbMaM3K84tPtejFrlrQwnfSqrm5dSaDB+R+HFG9Ri5Gh0fZr1vE6fKTcjyPVej+Tv3UHG1myMyIH85045KoeLw== x-ms-office365-filtering-correlation-id: 752648ea-e3a2-4c06-0296-08d4923f83b2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2580; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(6072148); SRVR:AM5PR0701MB2580; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2580; x-forefront-prvs: 029651C7A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39450400003)(39410400002)(39840400002)(39850400002)(39860400002)(24454002)(377454003)(86362001)(50986999)(7696004)(76176999)(236005)(93886004)(561944003)(54356999)(99286003)(55016002)(6306002)(54906002)(122556002)(6506006)(2900100001)(77096006)(33656002)(7736002)(5660300001)(54896002)(9686003)(53546009)(345774005)(74316002)(7906003)(606005)(4326008)(2950100002)(25786009)(6436002)(9326002)(478600001)(8936002)(2906002)(3660700001)(229853002)(53936002)(189998001)(3280700002)(19609705001)(790700001)(6116002)(102836003)(3846002)(230783001)(38730400002)(8676002)(6246003)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2580; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2577062A8CC8B4FEAEFA563D8D160AM5PR0701MB2577_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2017 16:14:45.4597 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2580 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHPbv3urvR4OTrkybViFDTmWa0wkIjSIgg+qSC6Mib707uVUs/ qRGZNt+tlJlKi2GaophvmTVTUkGb4ktlU2taWoR+0HQNtG13hd/+z/n/zv85z8OhCadOyoNO TMtg2DRFitRRTFZHdHn6byFx5Imp2kPyvMUHQnnf53FSvqb3l1dpjWQoGV5pbqPCNRqT4Kog ShwSx6QkZjFswPlYccJsSz5Kb54R3OrS1gpzUceYoBCJaMDBUFpdgQqRmHbCgwjGTI/txTsE 49UblLUgsYqAtcUVknceCWCua5n4j03p39jCHLE31HUbLPdp2gXfAG1BgJUh8BMEE0OLyMo4 WxpOdo1SPHMKtk0yXl4AQ3eSlSDxUXi1XGdLlOBYMAyPUHyraQS103pbjAifg6ahGUerRtgL FrbmSasmsDt8Wqqzz4ZB0/ee4LUrrBp3bEEIqxA0NpodeeMwLPypsENeMFlXZJsfcDEBZbP1 Qt64AurBZpI3chFUaYwUbyihYbUA8ToZ1FslBA/9FsD2XIk99iAYX2rssTsU3G4zE/wuPMAw dQ+VIp+aPW/ntRJm75YJa2xL2A8j1UtkjWVPBPaB1t4AHjkClUVfhLz2hjvqWuHe83okfIZc OYbjUuODgmQMm3id45RpsjQmox1ZfpOuw3y2G+m+hw0gTCPpPknsV1GkE6XI4rJTBxDQhNRF wq5bjiRxiuwchlXGsJkpDDeAPGlS6i4J7ddHOOF4RQaTzDDpDPvPFdAij1yUlDehi6qv2N64 qA0LGTb7Hg9uj7ja8kHH+SWUBPqrl/rcOl+05HeqQlSn5X73oyn2wOveovUA3U2u9VJPtLNM /hSvPIwp35W7nvx5ZnOhYTSn59u1Eue3LnM6h4ZfqvjNsLji3dbnEw6RysiZzHlU1l8eaLyc 4LZr+th07Edms5TkEhSBvgTLKf4C/qCCXEkDAAA= Archived-At: Subject: Re: [MMUSIC] Review: draft-ietf-mmusic-sdp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 16:16:54 -0000 --_000_AM5PR0701MB2577062A8CC8B4FEAEFA563D8D160AM5PR0701MB2577_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQXJ1biwNCg0KVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMhIFBsZWFzZSBzZWUgbXkgcmVz cG9uc2VzIGlubGluZSBiZWxvdy4NCg0KQ2hlZXJzLA0KL0JvDQoNCkZyb206IEFydW4gQXJ1bmFj aGFsYW0gKGNhcnVuYWNoKSBbbWFpbHRvOmNhcnVuYWNoQGNpc2NvLmNvbV0NClNlbnQ6IGRlbiA5 IGFwcmlsIDIwMTcgMTM6MDQNClRvOiBCbyBCdXJtYW4gPGJvLmJ1cm1hbkBlcmljc3Nvbi5jb20+ DQpDYzogRmxlbW1pbmcgQW5kcmVhc2VuIChmYW5kcmVhcykgPGZhbmRyZWFzQGNpc2NvLmNvbT47 IEFydW4gQXJ1bmFjaGFsYW0gKGNhcnVuYWNoKSA8Y2FydW5hY2hAY2lzY28uY29tPg0KU3ViamVj dDogUmU6IFJldmlldzogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdA0KDQpIaSBCbywN Cg0KUmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBoYXZlIGEgZmV3IGNvbW1lbnRzIGFuZCBxdWVzdGlv bnMgKHNob3duIGJlbG93KS4NCg0KVGhhbmtzIQ0KQXJ1bg0KDQpDb21tZW50cyAvIFF1ZXN0aW9u czoNCg0KKDEpIFNlY3Rpb24gMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTE+DQoNCiAgIHRyYW5zcG9ydCBvdmVy IFJUUC4gIFRoZSBtZWRpYSB0cmFuc3BvcnQgdG9wb2xvZ2llcyBjb25zaWRlcmVkIGFyZQ0KICAg cG9pbnQgdG8gcG9pbnQgUlRQIHNlc3Npb25zIGFzIHdlbGwgYXMgY2VudHJhbGl6ZWQgbXVsdGkt cGFydHkgUlRQDQogICBzZXNzaW9ucywgd2hlcmUgYSBtZWRpYSBzZW5kZXIgd2lsbCBwcm92aWRl IHRoZSBzaW11bGNhc3RlZCBzdHJlYW1zDQogICB0byBhbiBSVFAgbWlkZGxlYm94IG9yIGVuZHBv aW50LCBhbmQgbWlkZGxlYm94ZXMgbWF5IGZ1cnRoZXINCiAgIGRpc3RyaWJ1dGUgdGhlIHNpbXVs Y2FzdCBzdHJlYW1zIHRvIG90aGVyIG1pZGRsZWJveGVzIG9yIGVuZHBvaW50cy4NCg0KU2V2ZXJh bCBwbGFjZXMgaW4gdGhlIGRvYyB1c2UgdGhlIHRlcm0g4oCcUlRQIFNlc3Npb27igJ0gYW5kIOKA nFJUUCBzdHJlYW1z4oCdIGhlbmNlIGl0IHdvdWxkIGJlIHVzZWZ1bCB0byBwcm92aWRlIGEgcmVm ZXJlbmNlIHNvIHRoYXQgcmVhZGVycyBjYW4ga25vdyB0aGUgZGlmZmVyZW5jZS4NCg0KUlRQIFNl c3Npb24g4oCUPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzU1MCNzZWN0aW9uLTEu MQ0KW0JvQl0gQXMgc2FpZCBhdCB0aGUgc3RhcnQgb2Ygc2VjdGlvbiAyLjEg4oCcVGVybWlub2xv Z3nigJ0sIHRoZSBkcmFmdCBnZW5lcmFsbHkgdXNlcyB0ZXJtcyBmcm9tIFJUUCBUYXhvbm9teSAo UkZDIDc2NTYpLiBCb3RoIFJUUCBzdHJlYW0gYW5kIFJUUCBzZXNzaW9uIGFyZSB0ZXJtcyBkZXNj cmliZWQgdGhlcmUuIFJUUCBzZXNzaW9uIGlzLCBhcyB5b3Ugc2F5LCBhbHNvIGRlZmluZWQgYnkg UkZSQyAzNTUwLCBidXQgdGhlcmUgaGFzIGJlZW4gc2lnbmlmaWNhbnQgY29uZnVzaW9uIGFyb3Vu ZCB3aGF0IHRoZSB0ZXJtIHJlYWxseSBtZWFucywgc28gYWRkaXRpb25hbCBjbGFyaWZpY2F0aW9u IHdhcyBhZGRlZCBpbiBSRkMgNzY1Ni4gSSBoYXZlIG5vIHByb2JsZW0gYWRkaW5nIHRoZW0gYXMg ZXhwbGljaXQgdGVybXMgaW4gc2VjdGlvbiAyLjEsIGJ1dCB3aWxsIHRoZW4gbW9yZSBvciBsZXNz IGp1c3QgcmVmZXJlbmNlIFJGQyAzNTUwIGFuZCBSRkMgNzY1NiBmcm9tIHRoZXJlLg0KDQoNCigy KSBTZWN0aW9uIDMuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVz aWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTMuMT4NCg0KDQogICBCaXRyYXRlOiAgVGhpcyBy ZWxhdGVzIHRvIHRoZSBhbW91bnQgb2YgYml0cyBzcGVudCBwZXIgc2Vjb25kIHRvDQoNCiAgICAg IHRyYW5zbWl0IHRoZSBtZWRpYSBzb3VyY2UgYXMgYW4gUlRQIHN0cmVhbSwgd2hpY2ggdHlwaWNh bGx5IGFsc28NCg0KICAgICAgYWZmZWN0cyB0aGUgUXVhbGl0eSBvZiBFeHBlcmllbmNlIChRb0Up IGZvciB0aGUgcmVjZWl2aW5nIHVzZXIuDQoNCkkgdGhpbmsgdGhlIGF1dGhvcnMgbWF5IGhhdmUg aW50ZW5kZWQgdG8gdXNlIOKAnHNlbnTigJ0gaW5zdGVhZCBvZiDigJxzcGVudCIuDQpbQm9CXSBJ IHRoaW5rIGEgc2VuZGVyIGNhbiDigJxzcGVuZOKAnSBiaXRzIGl0IOKAnGhhcyBhdmFpbGFibGXi gJ0gdG8gc2VuZCwgYnV0IEkgYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY2hhbmdl IHRvIOKAnHNlbnTigJ0uDQoNCigzKSBTZWN0aW9uIDYuMTxodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTYuMT4NCg0K ICAgZGlyZWN0aW9uYWxpdHkgaXMgcmV2ZXJzZWQuICBUaGlzIGV4YW1wbGUgYW5zd2VyIGhhcyBy ZW1vdmVkIGFsbA0KICAgb2ZmZXJlZCBhbHRlcm5hdGl2ZSBmb3JtYXRzIGZvciB0aGUgZmlyc3Qg c2ltdWxjYXN0IHN0cmVhbSAoa2VlcGluZw0KICAgb25seSBTQ0lEIDEpLCBidXQga2VwdCBhbHRl cm5hdGl2ZSBmb3JtYXRzIGZvciB0aGUgc2Vjb25kIHNpbXVsY2FzdA0KICAgc3RyZWFtIGluIHJl Y2VpdmUgZGlyZWN0aW9uICg0LCA1KS4gIFRoZSBhbnN3ZXIgdGh1cyBhY2NlcHRzIHRvIHNlbmQN CiAgIHR3byBzaW11bGNhc3Qgc3RyZWFtcywgd2l0aG91dCBhbHRlcm5hdGl2ZXMuICBUaGUgYW5z d2VyIGRvZXMgbm90DQogICBhY2NlcHQgaW5pdGlhbCBwYXVzZSBvZiBhbnkgc2ltdWxjYXN0IHN0 cmVhbXMsIGluIGVpdGhlciBkaXJlY3Rpb24uDQogICBNb3JlIGV4YW1wbGVzIGNhbiBiZSBmb3Vu ZCBpbiBTZWN0aW9uIDYuNi4NCg0KUGxlYXNlIHJlbW92ZSB0aGUgd29yZCDigJx0aHVz4oCdIHNp bmNlIHRoZXJlIGlzIG5vIHJlYXNvbiBwcm92aWRlZCBwcmlvciB0byB0aGlzIHNlbnRlbmNlLg0K W0JvQl0gT0suDQoNCg0KKDQpIFNlY3Rpb24gNi4yPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3NlY3Rpb24tNi4yPg0KDQogICBp bnN0ZWFkIG9mIG1ha2luZyBpdCBlcXVpdmFsZW50IHRvIGltcGxpY2l0bHkgc2VuZGluZyBhIHBh dXNlDQogICByZXF1ZXN0LCBpcyBiZWNhdXNlIHRoZSBwYXVzaW5nIFJUUCBzZW5kZXIgY2Fubm90 IGtub3cgd2hpY2gNCiAgIHJlY2VpdmluZyBTU1JDIG93bnMgdGhlIHJlc3RyaWN0aW9uIHdoZW4g VE1NQlIvVE1NQk4gYXJlIHVzZWQgZm9yDQogICBwYXVzZS9yZXN1bWUgc2lnbmFsaW5nIHNpbmNl IHRoZSBSVFAgcmVjZWl2ZXIncyBTU1JDIGluIHNlbmQNCiAgIGRpcmVjdGlvbiBpcyBzb21ldGlt ZXMgbm90IHlldCBrbm93bi4NCg0KSXQgd291bGQgYmUgZ29vZCB0byBhIGdpdmUgcmVmZXJlbmNl IGZvciBUTU1CUi9UTU1CTiBwb2ludGluZyB0byBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNzcyOCNzZWN0aW9uLTIuMSBvciBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzcy OCNzZWN0aW9uLTUuNi4NCltCb0JdIE9LLiBQcmVmZXIgc2VjdGlvbiA1LjYgb2YgUkZDIDc3Mjgu IEhvd2V2ZXIsIHRoZSBkcmFmdCBzb3VyY2UgaXMgWE1MIGFuZCBJIGRvbuKAmXQgdGhpbmsgeG1s MnJmYyA8eHJlZj4gc3VwcG9ydHMgcmVmZXJlbmNpbmcgYSBwYXJ0aWN1bGFyIHNlY3Rpb24sIHNv IEnigJltIG5vdCBzdXJlIGhvdyB0byBhY2hpZXZlIHRoYXQuDQoNCg0KKDUpIFNlY3Rpb24gNi4z LjI8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11 bGNhc3QtMDgjc2VjdGlvbi02LjMuMj4NCg0KICAgQW4gYW5zd2VyZXIgdGhhdCByZWNlaXZlcyBp bmRpY2F0aW9uIGluIGFuIG9mZmVyIG9mIGFuIFNDSUQgYmVpbmcNCiAgIGluaXRpYWxseSBwYXVz ZWQgU0hPVUxEIG1hcmsgdGhhdCBTQ0lEIGFzIGluaXRpYWxseSBwYXVzZWQgYWxzbyBpbg0KICAg dGhlIGFuc3dlciwgcmVnYXJkbGVzcyBvZiBkaXJlY3Rpb24sIHVubGVzcyBpdCBoYXMgZ29vZCBy ZWFzb24gZm9yDQogICB0aGUgU0NJRCBub3QgYmVpbmcgaW5pdGlhbGx5IHBhdXNlZC4gIE9uZSBz dWNoIHJlYXNvbiBjb3VsZCwgZm9yDQogICBleGFtcGxlLCBiZSB0aGF0IHRoZSBhbnN3ZXJlciB3 b3VsZCBvdGhlcndpc2UgaW5pdGlhbGx5IG5vdCByZWNlaXZlDQogICBhbnkgbWVkaWEgb2YgdGhh dCB0eXBlIGF0IGFsbC4NCg0KVHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIGV4YW1wbGUuIENhbiB5 b3UgcGxlYXNlIGV4cGxhaW4gYSBzY2VuYXJpbyBpbiB3aGljaCB0aGUgZXhhbXBsZSBhcHBsaWVz Pw0KW0JvQl0gU2F5IHRoYXQgeW91IGhhdmUgYSBzaW11bGNhc3Qgd2l0aCBzZXZlcmFsIGRpZmZl cmVudCBtZWRpYSBxdWFsaXR5IGxldmVscyBiZWluZyBvZmZlcmVkLiBUaGUgb2ZmZXJlciBleHBl Y3RzIG1vc3QgcmVjZWl2ZXJzIHRvIGFjY2VwdCB0aGUgaGlnaGVzdCBxdWFsaXR5IGxldmVsLCBh bmQgdGhhdCB0aGV5IGFyZSB0aGVuIHVuaW50ZXJlc3RlZCB0byByZWNlaXZlIHRoZSBsb3dlciBx dWFsaXR5IGxldmVscy4gVGhlIG9mZmVyZXIgaGFzIHRoZXJlZm9yZSBzZXQgdGhlIGxvd2VyIHF1 YWxpdHkgc2ltdWxjYXN0IHN0cmVhbXMgdG8gaW5pdGlhbGx5IHBhdXNlZC4gRnVydGhlciBhc3N1 bWUgYSBzb21ld2hhdCByZXN0cmljdGVkIGFuc3dlcmVyIHRoYXQgY2Fubm90IGNvcGUgd2l0aCB0 aGUgaGlnaGVzdCBxdWFsaXR5IGxldmVsLiBJdCB0aGVyZWZvcmUgd2FudHMgdG8gYWNjZXB0IGEg bG93ZXIgcXVhbGl0eSBsZXZlbCBzaW11bGNhc3Qgc3RyZWFtIGFuZCB3b3VsZCBub3QgcmVjZWl2 ZSBhbnl0aGluZyBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzZXNzaW9uICh1bnRpbCBpc3N1aW5n IGFuIFJGQyA3NzI4IFJFU1VNRSkgaWYgaXQgYWNjZXB0cyB0aGlzIGxvd2VyIHF1YWxpdHkgc2lt dWxjYXN0IHN0cmVhbSBhcyBpbml0aWFsbHkgcGF1c2VkLiBXaXRob3V0IGluY2x1ZGluZyBzdWNo IGZhaXJseSBleHRlbnNpdmUgZXhhbXBsZSB0ZXh0LCBJIGRvbuKAmXQga25vdyBob3cgdG8gYmVz dCBtYWtlIGEgY2xhcmlmaWNhdGlvbi4gRG8geW91IGhhdmUgYSBwcm9wb3NhbD8NCg0KDQooNikg U2VjdGlvbiA3LjIuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVz aWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTcuMi4xPg0KDQogICBUaGlzIHdpbGwgcmVzdWx0 IGluIGEgc2luZ2xlIFJUUCBzdHJlYW0gYmVpbmcgdXNlZCBmb3IgYSBwYXJ0aWN1bGFyDQogICBv ZiB0aGUgUlRQIG1peGVy4oCZcyBtZWRpYSBzb3VyY2VzLg0KDQoNClRoaXMgc2VudGVuY2Ugc2Vl bXMgdG8gYmUgbWlzc2luZyBhIHdvcmQgLSDigJzigKZ0b3IgYSBwYXJ0aWN1bGFyIF9fX19fX18g b2YgdGhlIFJUUCBtaXhlcuKAmXPigKYu4oCdDQpbQm9CXSBXaGF0IGFib3V0IHJlcGxhY2luZyDi gJxhIHBhcnRpY3VsYXIgb2bigJ0gd2l0aCDigJxlYWNoIG9uZSBvZuKAnT8NCg0KDQooNykgU2Vj dGlvbiA3LjIuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMt c2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTcuMi4xPg0KDQogICAgVGhpcyBhcyB0aGVyZSBpcyBu b3RoaW5nIGluIHRoZSBzaWduYWxsaW5nIGJldHdlZW4gdGhlIG1peGVyIGFuZCB0aGUgcmVjZWl2 ZXIgdGhhdCBpcyBzdHJ1Y3R1cmVkIGFyb3VuZCB0aGUgb3JpZ2luYXRpbmcgbWVkaWEgc291cmNl cywgb25seSB0aGUgbWl4ZXLigJlzIG1lZGlhIHNvdXJjZXMuDQoNCiBJIHRoaW5rIOKAnFRoaXMg YXPigJ0gbmVlZHMgdG8gYmUgY2hhbmdlZCB0byDigJxUaGF0IGlz4oCdLg0KW0JvQl0gT0suIEkg YXNzdW1lIOKAnFRoYXQgaXMsIOKAnCAod2l0aCBhIGNvbW1hKT8NCg0KDQooOCkgU2VjdGlvbiA3 LjIuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNp bXVsY2FzdC0wOCNzZWN0aW9uLTcuMi4xPg0KDQogICBJZiBSdHBTdHJlYW1JZHMgYXJlIHVzZWQg aW4gdGhpcyBzY2VuYXJpbywgaXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQNCiAgIHRoZSBSdHBTdHJl YW1JZCBvbiBhIHBhcnRpY3VsYXIgU1NSQyB3aWxsIGNoYW5nZSBiYXNlZCBvbiB0aGUgYWN0dWFs DQogICBzaW11bGNhc3Qgc3RyZWFtIHNlbGVjdGVkIGZvciBzd2l0Y2hpbmcuICBUaGVzZSBSdHBT dHJlYW1JZA0KICAgaWRlbnRpZmllcnMgd2lsbCBiZSBsb2NhbCB0byB0aGlzIGxlZ+KAmXMgc2ln bmFsbGluZyBjb250ZXh0LiAgSW4NCiAgIGFkZGl0aW9uLCB0aGUgZGVmaW5lZCBSdHBTdHJlYW1J ZHMgYW5kIHRoZWlyIHBhcmFtZXRlcnMgbmVlZCB0byBjb3Zlcg0KICAgYWxsIHRoZSBtZWRpYSBz b3VyY2VzIGFuZCBzaW11bGNhc3Qgc3RyZWFtcyB0aGF0IGNhbiBiZSBzd2l0Y2hlZCBpbnRvDQog ICB0aGlzIG1lZGlhIHNvdXJjZS4NCg0KSW4gdGhlIGFib3ZlIHBhcmFncmFwaCB3aGF0IGRvZXMg 4oCcdGhpcyBzY2VuYXJpb+KAnSByZWZlciB0bz8gSXMgaXQgdGhlIHNjZW5hcmlvIG9mIHVzaW5n IG1lZGlhIHNvdXJjZeKAmXMgcnRwIHN0cmVhbSBTU1JDIGluIHRoZSBDU1JDIG9mIHRoZSBydHAg bWl4ZXLigJlzIHJ0cCBzdHJlYW0gKG9yKSBpcyBpdCByZWZlcnJpbmcgdG8g4oCcUlRQIE1peGVy IC0gUmVjZWl2ZXLigJ0gc2NlbmFyaW9zIGluIGdlbmVyYWw/DQpbQm9CXSDigJxUaGlzIHNjZW5h cmlv4oCdIG1lYW5zIHRvIHJlZmVyIHRvIHRoaXMgc2VjdGlvbiAoNy4yLjEpLiBXaWxsIGNsYXJp ZnkuDQoNCkRvZXMg4oCcdGhpcyBsZWfigJlzIHNpZ25hbGluZyBjb250ZXh04oCdIHJlZmVyIHRv IHRoZSDigJxSVFAgbWl4ZXIgLSBSZWNlaXZlcuKAnSBjYWxsIGxlZz8NCltCb0JdIE5vdCBuZWNl c3NhcmlseSBqdXN0IFJUUCBzdHJlYW0gcmVjZWl2ZXIsIGl0IGNvdWxkIGFsc28gYmUgUlRQIHN0 cmVhbSBzZW5kZXIsIG90aGVyd2lzZSB5ZXMuIEl0IGlzIHRoZSBjb250ZXh0IG9mIGEgc2luZ2xl IFNEUCBvZmZlci9hbnN3ZXIgYmV0d2VlbiB0d28gcGFydGljaXBhbnRzIChSVFAgbWl4ZXIgYW5k IHdoYXRldmVyIGVuZHBvaW50IGlzIHRoZSBjb3VudGVycGFydCDigJMgcG9zc2libHkgZXZlbiBh bm90aGVyIFJUUCBtaXhlcikuDQoNClRoZSBzZW50ZW5jZSDigJxJbiBhZGRpdGlvbiwgdGhlIGRl ZmluZWQgUnRwU3RyZWFtSWRz4oCmLnRoYXQgY2FuIGJlIHN3aXRjaGVkIGludG8gdGhpcyBtZWRp YSBzb3VyY2UiIGlzIG5vdCBjbGVhciB0byBtZS4gU3BlY2lmaWNhbGx5IHdoeSB3b3VsZCB3ZSBz d2l0Y2hpbmcgYW4gUlRQIHN0cmVhbSBpbnRvIGEgbWVkaWEgc291cmNlLiBXYXMgaXQgaW50ZW5k ZWQgdG8gYmUg4oCcc3dpdGNoZWQgZnJvbSB0aGlzIG1lZGlhIHNvdXJjZeKAnSBvciDigJxzd2l0 Y2hlZCB0byBhIFJUUCByZWNlaXZlcuKAnT8gUGxlYXNlIGV4cGxhaW4uDQpbQm9CXSBUaGUgUlRQ IG1peGVyIHJlY2VpdmVzIChwb3RlbnRpYWxseSBzaW11bGNhc3QpIFJUUCBzdHJlYW1zIGZyb20g b3JpZ2luYXRpbmcgbWVkaWEgc291cmNlcyBhbmQgc3dpdGNoZXMgdGhvc2UgUlRQIHBhY2tldHMg aW50ZXJuYWxseSB0byBwcm92aWRlIGRhdGEgZm9yIHRoZSBSVFAgbWl4ZXLigJlzIG93biBtZWRp YSBzb3VyY2VzIGFuZCBSVFAgc3RyZWFtcywgYXMgc2VlbiBieSB0aGUgZmluYWwgcmVjZWl2ZXIg b2YgdGhlIFJUUCBzdHJlYW1zIGZyb20gdGhlIFJUUCBtaXhlci4gV2hhdCBhYm91dCByZS1mb3Jt dWxhdGluZyB0byDigJxJbiBhZGRpdGlvbiwgdGhlIGRlZmluZWQgUnRwU3RyZWFtSWRzIGFuZCB0 aGVpciBwYXJhbWV0ZXJzIG5lZWQgdG8gY292ZXIgYWxsIHRoZSBtZWRpYSBzb3VyY2VzIGFuZCBz aW11bGNhc3Qgc3RyZWFtcyByZWNlaXZlZCBieSB0aGUgUlRQIG1peGVyIHRoYXQgY2FuIGJlIHN3 aXRjaGVkIGludG8gdGhpcyBtZWRpYSBzb3VyY2UsIHNlbnQgYnkgdGhlIFJUUCBtaXhlcuKAnT8N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpPbiBNYXIgMzAsIDIwMTcsIGF0IDU6NDIgUE0sIEFydW4g QXJ1bmFjaGFsYW0gKGNhcnVuYWNoKSA8Y2FydW5hY2hAY2lzY28uY29tPG1haWx0bzpjYXJ1bmFj aEBjaXNjby5jb20+PiB3cm90ZToNCg0KSGkgRmxlbW1pbmcsDQoNCkkgdGhpbmsgaW4gYWJvdXQg YSB3ZWVrIGkuZSBieSBFT0IgNC83Lg0KDQpUaGFua3MhDQpBcnVuDQpTZW50IGZyb20gbXkgaVBo b25lDQoNCk9uIE1hciAzMCwgMjAxNywgYXQgNDozMyBQTSwgRmxlbW1pbmcgQW5kcmVhc2VuIChm YW5kcmVhcykgPGZhbmRyZWFzQGNpc2NvLmNvbTxtYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tPj4g d3JvdGU6DQpUaGFua3MgQXJ1biAtIHdoZW4gZG8geW91IHRoaW5rIHlvdSB3aWxsIGhhdmUgdGhl IHJldmlldyByZWFkeSA/DQoNCi0tIEZsZW1taW5nDQpPbiAzLzMwLzE3IDQ6MzAgUE0sIEFydW4g QXJ1bmFjaGFsYW0gKGNhcnVuYWNoKSB3cm90ZToNCkhpIEZsZW1taW5nLA0KDQpBcyBkaXNjdXNz ZWQsIGkgd291bGQgYmUgZ2xhZCB0byByZXZpZXcgZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVs Y2FzdDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbW11 c2ljLXNkcC1zaW11bGNhc3Q+IGRyYWZ0Lg0KDQpUaGFua3MhDQpBcnVuDQoNCg0KLg0KDQoNCg== --_000_AM5PR0701MB2577062A8CC8B4FEAEFA563D8D160AM5PR0701MB2577_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1 cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IaSBBcnVuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGFuayB5 b3UgZm9yIHRoZSBjb21tZW50cyEgUGxlYXNlIHNlZSBteSByZXNwb25zZXMgaW5saW5lIGJlbG93 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4vQm8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBcnVuIEFydW5hY2hhbGFtIChjYXJ1bmFj aCkgW21haWx0bzpjYXJ1bmFjaEBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDkg YXByaWwgMjAxNyAxMzowNDxicj4NCjxiPlRvOjwvYj4gQm8gQnVybWFuICZsdDtiby5idXJtYW5A ZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRmxlbW1pbmcgQW5kcmVhc2VuIChmYW5k cmVhcykgJmx0O2ZhbmRyZWFzQGNpc2NvLmNvbSZndDs7IEFydW4gQXJ1bmFjaGFsYW0gKGNhcnVu YWNoKSAmbHQ7Y2FydW5hY2hAY2lzY28uY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog UmV2aWV3OiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQm8sIDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBoYXZlIGEg ZmV3IGNvbW1lbnRzIGFuZCBxdWVzdGlvbnMgKHNob3duIGJlbG93KS4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzITxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXJ1bjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiNGRjZBMDAiPkNvbW1lbnRzIC8gUXVlc3Rpb25zPC9zcGFu PjwvYj46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4oMSkmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTEiPlNlY3Rpb24gMTwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDt0cmFuc3BvcnQgb3ZlciBSVFAuICZuYnNwO1RoZSBtZWRpYSB0 cmFuc3BvcnQgdG9wb2xvZ2llcyBjb25zaWRlcmVkIGFyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3BvaW50IHRvIHBvaW50 IDxiPlJUUCBzZXNzaW9uczwvYj4gYXMgd2VsbCBhcyBjZW50cmFsaXplZCBtdWx0aS1wYXJ0eSBS VFA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDtzZXNzaW9ucywgd2hlcmUgYSBtZWRpYSBzZW5kZXIgd2lsbCBwcm92aWRlIHRo ZSBzaW11bGNhc3RlZCBzdHJlYW1zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dG8gYW4gUlRQIG1pZGRsZWJveCBvciBlbmRw b2ludCwgYW5kIG1pZGRsZWJveGVzIG1heSBmdXJ0aGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ZGlzdHJpYnV0ZSB0aGUg c2ltdWxjYXN0IHN0cmVhbXMgdG8gb3RoZXIgbWlkZGxlYm94ZXMgb3IgZW5kcG9pbnRzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlNldmVyYWwgcGxhY2VzIGluIHRoZSBkb2MgdXNlIHRoZSB0ZXJtIOKAnFJUUCBTZXNzaW9u4oCd IGFuZCDigJxSVFAgc3RyZWFtc+KAnSBoZW5jZSBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gcHJvdmlk ZSBhIHJlZmVyZW5jZSBzbyB0aGF0IHJlYWRlcnMgY2FuIGtub3cgdGhlIGRpZmZlcmVuY2UuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJUUCBT ZXNzaW9uIOKAlCZndDsmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjMzU1MCNzZWN0aW9uLTEuMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTAj c2VjdGlvbi0xLjE8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPltCb0JdIEFzIHNhaWQgYXQgdGhlIHN0YXJ0IG9mIHNlY3Rpb24g Mi4xIOKAnFRlcm1pbm9sb2d54oCdLCB0aGUgZHJhZnQgZ2VuZXJhbGx5IHVzZXMgdGVybXMgZnJv bSBSVFAgVGF4b25vbXkgKFJGQyA3NjU2KS4gQm90aCBSVFAgc3RyZWFtIGFuZCBSVFAgc2Vzc2lv biBhcmUgdGVybXMgZGVzY3JpYmVkDQogdGhlcmUuIFJUUCBzZXNzaW9uIGlzLCBhcyB5b3Ugc2F5 LCBhbHNvIGRlZmluZWQgYnkgUkZSQyAzNTUwLCBidXQgdGhlcmUgaGFzIGJlZW4gc2lnbmlmaWNh bnQgY29uZnVzaW9uIGFyb3VuZCB3aGF0IHRoZSB0ZXJtIHJlYWxseSBtZWFucywgc28gYWRkaXRp b25hbCBjbGFyaWZpY2F0aW9uIHdhcyBhZGRlZCBpbiBSRkMgNzY1Ni4gSSBoYXZlIG5vIHByb2Js ZW0gYWRkaW5nIHRoZW0gYXMgZXhwbGljaXQgdGVybXMgaW4gc2VjdGlvbiAyLjEsIGJ1dA0KIHdp bGwgdGhlbiBtb3JlIG9yIGxlc3MganVzdCByZWZlcmVuY2UgUkZDIDM1NTAgYW5kIFJGQyA3NjU2 IGZyb20gdGhlcmUuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4oMikmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTMuMSI+U2VjdGlvbiAzLjE8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgQml0cmF0 ZTombmJzcDsgVGhpcyByZWxhdGVzIHRvIHRoZSBhbW91bnQgb2YgYml0cyA8Yj5zcGVudCBwZXIg c2Vjb25kPC9iPiB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0cmFuc21pdCB0aGUgbWVkaWEgc291cmNlIGFzIGFuIFJUUCBz dHJlYW0sIHdoaWNoIHR5cGljYWxseSBhbHNvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFmZmVjdHMgdGhlIFF1YWxpdHkgb2Yg RXhwZXJpZW5jZSAoUW9FKSBmb3IgdGhlIHJlY2VpdmluZyB1c2VyLjwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRo ZSBhdXRob3JzIG1heSBoYXZlIGludGVuZGVkIHRvIHVzZSDigJw8Yj5zZW50PC9iPuKAnSBpbnN0 ZWFkIG9mIOKAnHNwZW50JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bQm9CXSBJIHRoaW5rIGEgc2VuZGVyIGNhbiDigJxz cGVuZOKAnSBiaXRzIGl0IOKAnGhhcyBhdmFpbGFibGXigJ0gdG8gc2VuZCwgYnV0IEkgYWdyZWUg dGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY2hhbmdlIHRvIOKAnHNlbnTigJ0uDQo8L3NwYW4+ PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KDMpJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3QtMDgjc2Vj dGlvbi02LjEiPlNlY3Rpb24gNi4xPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2RpcmVjdGlvbmFsaXR5 IGlzIHJldmVyc2VkLiAmbmJzcDtUaGlzIGV4YW1wbGUgYW5zd2VyIGhhcyByZW1vdmVkIGFsbDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwO29mZmVyZWQgYWx0ZXJuYXRpdmUgZm9ybWF0cyBmb3IgdGhlIGZpcnN0IHNpbXVsY2Fz dCBzdHJlYW0gKGtlZXBpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtvbmx5IFNDSUQgMSksIGJ1dCBrZXB0IGFsdGVybmF0 aXZlIGZvcm1hdHMgZm9yIHRoZSBzZWNvbmQgc2ltdWxjYXN0PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7c3RyZWFtIGluIHJl Y2VpdmUgZGlyZWN0aW9uICg0LCA1KS4gJm5ic3A7VGhlIGFuc3dlciA8Yj48cz50aHVzPC9zPjwv Yj4gYWNjZXB0cyB0byBzZW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dHdvIHNpbXVsY2FzdCBzdHJlYW1zLCB3aXRob3V0 IGFsdGVybmF0aXZlcy4gJm5ic3A7VGhlIGFuc3dlciBkb2VzIG5vdDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2FjY2VwdCBp bml0aWFsIHBhdXNlIG9mIGFueSBzaW11bGNhc3Qgc3RyZWFtcywgaW4gZWl0aGVyIGRpcmVjdGlv bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDtNb3JlIGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBpbiBTZWN0aW9uIDYuNi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QbGVhc2UgcmVtb3ZlIHRoZSB3b3JkIOKAnHRodXPigJ0gc2luY2UgdGhlcmUgaXMgbm8gcmVh c29uIHByb3ZpZGVkIHByaW9yIHRvIHRoaXMgc2VudGVuY2UuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltCb0JdIE9LLjwvc3Bhbj48 L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPig0KSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3Nl Y3Rpb24tNi4yIj5TZWN0aW9uIDYuMjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtpbnN0ZWFkIG9mIG1h a2luZyBpdCBlcXVpdmFsZW50IHRvIGltcGxpY2l0bHkgc2VuZGluZyBhIHBhdXNlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 cmVxdWVzdCwgaXMgYmVjYXVzZSB0aGUgcGF1c2luZyBSVFAgc2VuZGVyIGNhbm5vdCBrbm93IHdo aWNoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7cmVjZWl2aW5nIFNTUkMgb3ducyB0aGUgcmVzdHJpY3Rpb24gd2hlbiA8Yj5U TU1CUi9UTU1CTjwvYj4gYXJlIHVzZWQgZm9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cGF1c2UvcmVzdW1lIHNpZ25hbGlu ZyBzaW5jZSB0aGUgUlRQIHJlY2VpdmVyJ3MgU1NSQyBpbiBzZW5kPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ZGlyZWN0aW9u IGlzIHNvbWV0aW1lcyBub3QgeWV0IGtub3duLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIGdvb2QgdG8gYSBn aXZlIHJlZmVyZW5jZSBmb3IgVE1NQlIvVE1NQk4gcG9pbnRpbmcgdG8mbmJzcDs8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzcyOCNzZWN0aW9uLTIuMSI+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzc3Mjgjc2VjdGlvbi0yLjE8L2E+Jm5ic3A7b3ImbmJzcDs8 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzcyOCNzZWN0aW9uLTUuNiI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc3Mjgjc2VjdGlvbi01LjY8L2E+LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5b Qm9CXSBPSy4gUHJlZmVyIHNlY3Rpb24gNS42IG9mIFJGQyA3NzI4LiBIb3dldmVyLCB0aGUgZHJh ZnQgc291cmNlIGlzIFhNTCBhbmQgSSBkb27igJl0IHRoaW5rIHhtbDJyZmMgJmx0O3hyZWYmZ3Q7 IHN1cHBvcnRzIHJlZmVyZW5jaW5nIGEgcGFydGljdWxhciBzZWN0aW9uLCBzbyBJ4oCZbSBub3Qg c3VyZQ0KIGhvdyB0byBhY2hpZXZlIHRoYXQuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtaW4taGVpZ2h0OiAxNHB4Ij4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oNSkmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9u LTYuMy4yIj5TZWN0aW9uIDYuMy4yPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgQW4gYW5zd2VyZXIgdGhhdCByZWNl aXZlcyBpbmRpY2F0aW9uIGluIGFuIG9mZmVyIG9mIGFuIFNDSUQgYmVpbmc8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBpbml0 aWFsbHkgcGF1c2VkIFNIT1VMRCBtYXJrIHRoYXQgU0NJRCBhcyBpbml0aWFsbHkgcGF1c2VkIGFs c28gaW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyZuYnNwOyB0aGUgYW5zd2VyLCByZWdhcmRsZXNzIG9mIGRpcmVjdGlvbiwgdW5sZXNz IGl0IGhhcyBnb29kIHJlYXNvbiBmb3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyB0aGUgU0NJRCBub3QgYmVpbmcgaW5pdGlh bGx5IHBhdXNlZC4mbmJzcDsgPGI+T25lIHN1Y2ggcmVhc29uIGNvdWxkLCBmb3I8L2I+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj4mbmJzcDsm bmJzcDsgZXhhbXBsZSwgYmUgdGhhdCB0aGUgYW5zd2VyZXIgd291bGQgb3RoZXJ3aXNlIGluaXRp YWxseSBub3QgcmVjZWl2ZTwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPiZuYnNwOyZuYnNwOyBhbnkgbWVkaWEgb2YgdGhhdCB0eXBlIGF0 IGFsbC48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UcnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgZXhhbXBsZS4gQ2FuIHlvdSBw bGVhc2UgZXhwbGFpbiBhIHNjZW5hcmlvIGluIHdoaWNoIHRoZSBleGFtcGxlIGFwcGxpZXM/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PltCb0JdIFNheSB0aGF0IHlvdSBoYXZlIGEgc2ltdWxjYXN0IHdpdGggc2V2ZXJhbCBkaWZmZXJl bnQgbWVkaWEgcXVhbGl0eSBsZXZlbHMgYmVpbmcgb2ZmZXJlZC4gVGhlIG9mZmVyZXIgZXhwZWN0 cyBtb3N0IHJlY2VpdmVycyB0byBhY2NlcHQgdGhlIGhpZ2hlc3QgcXVhbGl0eSBsZXZlbCwNCiBh bmQgdGhhdCB0aGV5IGFyZSB0aGVuIHVuaW50ZXJlc3RlZCB0byByZWNlaXZlIHRoZSBsb3dlciBx dWFsaXR5IGxldmVscy4gVGhlIG9mZmVyZXIgaGFzIHRoZXJlZm9yZSBzZXQgdGhlIGxvd2VyIHF1 YWxpdHkgc2ltdWxjYXN0IHN0cmVhbXMgdG8gaW5pdGlhbGx5IHBhdXNlZC4gRnVydGhlciBhc3N1 bWUgYSBzb21ld2hhdCByZXN0cmljdGVkIGFuc3dlcmVyIHRoYXQgY2Fubm90IGNvcGUgd2l0aCB0 aGUgaGlnaGVzdCBxdWFsaXR5IGxldmVsLiBJdA0KIHRoZXJlZm9yZSB3YW50cyB0byBhY2NlcHQg YSBsb3dlciBxdWFsaXR5IGxldmVsIHNpbXVsY2FzdCBzdHJlYW0gYW5kIHdvdWxkIG5vdCByZWNl aXZlIGFueXRoaW5nIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHNlc3Npb24gKHVudGlsIGlzc3Vp bmcgYW4gUkZDIDc3MjggUkVTVU1FKSBpZiBpdCBhY2NlcHRzIHRoaXMgbG93ZXIgcXVhbGl0eSBz aW11bGNhc3Qgc3RyZWFtIGFzIGluaXRpYWxseSBwYXVzZWQuIFdpdGhvdXQgaW5jbHVkaW5nIHN1 Y2gNCiBmYWlybHkgZXh0ZW5zaXZlIGV4YW1wbGUgdGV4dCwgSSBkb27igJl0IGtub3cgaG93IHRv IGJlc3QgbWFrZSBhIGNsYXJpZmljYXRpb24uIERvIHlvdSBoYXZlIGEgcHJvcG9zYWw/PC9zcGFu PjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oNikmbmJzcDs8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVs Y2FzdC0wOCNzZWN0aW9uLTcuMi4xIj5TZWN0aW9uIDcuMi4xPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7VGhpcyB3aWxsIHJlc3VsdCBpbiBhIHNpbmdsZSBSVFAgc3RyZWFtIGJlaW5nIHVzZWQg Zm9yIGEgPGI+DQpwYXJ0aWN1bGFyPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+Jm5ic3A7Jm5ic3A7Jm5ic3A7b2Y8L2I+IHRoZSBSVFAg bWl4ZXLigJlzIG1lZGlhIHNvdXJjZXMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNlbnRlbmNlIHNlZW1z IHRvIGJlIG1pc3NpbmcgYSB3b3JkIC0g4oCc4oCmdG9yIGEgcGFydGljdWxhciBfX19fX19fIG9m IHRoZSBSVFAgbWl4ZXLigJlz4oCmLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bQm9CXSBXaGF0IGFib3V0IHJlcGxhY2luZyDi gJxhIHBhcnRpY3VsYXIgb2bigJ0gd2l0aCDigJxlYWNoIG9uZSBvZuKAnT88L3NwYW4+PC9pPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oNykmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9u LTcuMi4xIj5TZWN0aW9uIDcuMi4xPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyZuYnNwOzxiPlRoaXMg YXM8L2I+IHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIHNpZ25hbGxpbmcgYmV0d2VlbiB0aGUgbWl4 ZXIgYW5kIHRoZSByZWNlaXZlciB0aGF0IGlzIHN0cnVjdHVyZWQgYXJvdW5kIHRoZSBvcmlnaW5h dGluZyBtZWRpYSBzb3VyY2VzLCBvbmx5IHRoZSBtaXhlcuKAmXMgbWVkaWEgc291cmNlcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 SSB0aGluayDigJxUaGlzIGFz4oCdIG5lZWRzIHRvIGJlIGNoYW5nZWQgdG8g4oCcVGhhdCBpc+KA nS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+W0JvQl0gT0suIEkgYXNzdW1lIOKAnFRoYXQgaXMsIOKAnCAod2l0aCBhIGNvbW1hKT88 L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWluLWhlaWdodDogMTRw eCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4o OCkmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1t bXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTcuMi4xIj5TZWN0aW9uIDcuMi4xPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWluLWhl aWdodDogMTRweCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwO0lmIFJ0cFN0cmVhbUlkcyBhcmUgdXNlZCBp biA8Yj50aGlzIHNjZW5hcmlvPC9iPiwgaXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZu YnNwO3RoZSBSdHBTdHJlYW1JZCBvbiBhIHBhcnRpY3VsYXIgU1NSQyB3aWxsIGNoYW5nZSBiYXNl ZCBvbiB0aGUgYWN0dWFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDtzaW11bGNhc3Qgc3RyZWFtIHNlbGVjdGVkIGZv ciBzd2l0Y2hpbmcuJm5ic3A7Jm5ic3A7VGhlc2UgUnRwU3RyZWFtSWQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwO2lk ZW50aWZpZXJzIHdpbGwgYmUgbG9jYWwgdG8gPGI+dGhpcyBsZWfigJlzIHNpZ25hbGxpbmcgY29u dGV4dDwvYj4uJm5ic3A7Jm5ic3A7SW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwO2FkZGl0aW9uLCB0aGUgZGVmaW5l ZCBSdHBTdHJlYW1JZHMgYW5kIHRoZWlyIHBhcmFtZXRlcnMgbmVlZCB0byBjb3ZlcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7YWxsIHRoZSBtZWRpYSBzb3VyY2VzIGFuZCBzaW11bGNhc3Qgc3RyZWFtcyB0aGF0IGNh biBiZSBzd2l0Y2hlZA0KPGI+aW50bzwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPiZuYnNwOyZuYnNwOyZuYnNwO3RoaXMgbWVkaWEgc291 cmNlLjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbiB0aGUgYWJvdmUgcGFyYWdyYXBoIHdoYXQgZG9lcyDigJx0aGlzIHNj ZW5hcmlv4oCdIHJlZmVyIHRvPyBJcyBpdCB0aGUgc2NlbmFyaW8gb2YgdXNpbmcgbWVkaWEmbmJz cDtzb3VyY2XigJlzIHJ0cCBzdHJlYW0gU1NSQyBpbiB0aGUgQ1NSQyBvZiB0aGUgcnRwIG1peGVy 4oCZcyBydHAgc3RyZWFtIChvcikgaXMgaXQgcmVmZXJyaW5nIHRvIOKAnFJUUCBNaXhlciAtIFJl Y2VpdmVy4oCdIHNjZW5hcmlvcyBpbiBnZW5lcmFsPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bQm9CXSDigJxUaGlzIHNjZW5hcmlv 4oCdIG1lYW5zIHRvIHJlZmVyIHRvIHRoaXMgc2VjdGlvbiAoNy4yLjEpLiBXaWxsIGNsYXJpZnku PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMg4oCcdGhpcyBsZWfigJlz IHNpZ25hbGluZyBjb250ZXh04oCdIHJlZmVyIHRvIHRoZSDigJxSVFAgbWl4ZXIgLSBSZWNlaXZl cuKAnSBjYWxsIGxlZz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+W0JvQl0gTm90IG5lY2Vzc2FyaWx5IGp1c3QgUlRQIHN0cmVhbSBy ZWNlaXZlciwgaXQgY291bGQgYWxzbyBiZSBSVFAgc3RyZWFtIHNlbmRlciwgb3RoZXJ3aXNlIHll cy4gSXQgaXMgdGhlIGNvbnRleHQgb2YgYSBzaW5nbGUgU0RQIG9mZmVyL2Fuc3dlciBiZXR3ZWVu IHR3byBwYXJ0aWNpcGFudHMNCiAoUlRQIG1peGVyIGFuZCB3aGF0ZXZlciBlbmRwb2ludCBpcyB0 aGUgY291bnRlcnBhcnQg4oCTIHBvc3NpYmx5IGV2ZW4gYW5vdGhlciBSVFAgbWl4ZXIpLjwvc3Bh bj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2VudGVuY2Ug4oCcSW4gYWRkaXRp b24sIHRoZSBkZWZpbmVkIFJ0cFN0cmVhbUlkc+KApi50aGF0IGNhbiBiZSBzd2l0Y2hlZCBpbnRv IHRoaXMgbWVkaWEgc291cmNlJnF1b3Q7IGlzIG5vdCBjbGVhciB0byBtZS4gU3BlY2lmaWNhbGx5 IHdoeSB3b3VsZCB3ZSBzd2l0Y2hpbmcgYW4gUlRQIHN0cmVhbQ0KPGI+aW50bzwvYj4gYSBtZWRp YSBzb3VyY2UuIFdhcyBpdCBpbnRlbmRlZCB0byBiZSDigJxzd2l0Y2hlZCBmcm9tIHRoaXMgbWVk aWEgc291cmNl4oCdIG9yIOKAnHN3aXRjaGVkIHRvIGEgUlRQIHJlY2VpdmVy4oCdPyBQbGVhc2Ug ZXhwbGFpbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+W0JvQl0gVGhlIFJUUCBtaXhlciByZWNlaXZlcyAocG90ZW50aWFsbHkgc2lt dWxjYXN0KSBSVFAgc3RyZWFtcyBmcm9tIG9yaWdpbmF0aW5nIG1lZGlhIHNvdXJjZXMgYW5kIHN3 aXRjaGVzIHRob3NlIFJUUCBwYWNrZXRzIGludGVybmFsbHkgdG8gcHJvdmlkZSBkYXRhIGZvciB0 aGUgUlRQDQogbWl4ZXLigJlzIG93biBtZWRpYSBzb3VyY2VzIGFuZCBSVFAgc3RyZWFtcywgYXMg c2VlbiBieSB0aGUgZmluYWwgcmVjZWl2ZXIgb2YgdGhlIFJUUCBzdHJlYW1zIGZyb20gdGhlIFJU UCBtaXhlci4gV2hhdCBhYm91dCByZS1mb3JtdWxhdGluZyB0byDigJxJbiBhZGRpdGlvbiwgdGhl IGRlZmluZWQgUnRwU3RyZWFtSWRzIGFuZCB0aGVpciBwYXJhbWV0ZXJzIG5lZWQgdG8gY292ZXIg YWxsIHRoZSBtZWRpYSBzb3VyY2VzIGFuZCBzaW11bGNhc3Qgc3RyZWFtcw0KPHNwYW4gc3R5bGU9 ImNvbG9yOnJlZCI+cmVjZWl2ZWQgYnkgdGhlIFJUUCBtaXhlciA8L3NwYW4+dGhhdCBjYW4gYmUg c3dpdGNoZWQgaW50byB0aGlzIG1lZGlhIHNvdXJjZTxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiwg c2VudCBieSB0aGUgUlRQIG1peGVyPC9zcGFuPuKAnT88L3NwYW4+PC9pPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgMzAsIDIwMTcs IGF0IDU6NDIgUE0sIEFydW4gQXJ1bmFjaGFsYW0gKGNhcnVuYWNoKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOmNhcnVuYWNoQGNpc2NvLmNvbSI+Y2FydW5hY2hAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkg RmxlbW1pbmcsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgdGhpbmsgaW4gYWJvdXQgYSB3ZWVrIGkuZSBieSBFT0IgNC83LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MhPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPkFydW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TZW50IGZyb20gbXkgaVBob25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KT24gTWFyIDMwLCAyMDE3LCBhdCA0OjMzIFBNLCBGbGVtbWluZyBBbmRyZWFz ZW4gKGZhbmRyZWFzKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbSI+ZmFu ZHJlYXNAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ VGhhbmtzIEFydW4gLSB3aGVuIGRvIHlvdSB0aGluayB5b3Ugd2lsbCBoYXZlIHRoZSByZXZpZXcg cmVhZHkgPw0KPGJyPg0KPGJyPg0KLS0gRmxlbW1pbmcgPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMy8zMC8xNyA0OjMwIFBNLCBBcnVuIEFydW5hY2hhbGFt IChjYXJ1bmFjaCkgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGkgRmxlbW1pbmcsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QXMgZGlzY3Vzc2VkLCBpIHdvdWxkIGJlIGdsYWQgdG8gcmV2aWV3Jm5ic3A7 PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LW1tdXNpYy1zZHAtc2ltdWxjYXN0Ij5kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0PC9h PiZuYnNwO2RyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGFua3MhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BcnVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4uIDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_AM5PR0701MB2577062A8CC8B4FEAEFA563D8D160AM5PR0701MB2577_-- From nobody Thu May 4 04:08:39 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A421128961 for ; Thu, 4 May 2017 04:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 N0ZeYOX_e05h for ; Thu, 4 May 2017 04:08:34 -0700 (PDT) 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 8A3051294F4 for ; Thu, 4 May 2017 04:08:32 -0700 (PDT) X-AuditID: c1b4fb2d-b3dff7000000196b-95-590b0bada362 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1F.A8.06507.DAB0B095; Thu, 4 May 2017 13:08:30 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0339.000; Thu, 4 May 2017 13:08:29 +0200 From: Christer Holmberg To: Christer Holmberg , "Asveren, Tolga" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Thread-Index: AQHSxMbB9tlWASzsjUecixZeUtGAbA== Date: Thu, 4 May 2017 11:08:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_D530E71A1C16Dchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbFdUXcdN3ekwf+rChZTlz9msZjd+Z7J gcljyZKfTB6XPv9nD2CK4rJJSc3JLEst0rdL4MroazvBWvDlLmPFzIP/mRoYdx5g7GLk5JAQ MJGYs3UGcxcjF4eQwBFGiee7u1kgnMWMEq9vPAPKcHCwCVhIdP/TBomLCLQzSixvPssK0i0s ECix4NhvdhBbRCBIovvUVShbT6Kv/SNYL4uAisT/XzIgYV4Ba4k73fvYQGxGATGJ76fWMIHY zALiEreezGeCOEhAYsme88wQtqjEy8f/wFaJAo3c9+8rG0RcUaL9aQMjRG+CxLSLjUwQ8wUl Ts58wjKBUWgWkrGzkJTNQlIGETeQeH9uPjOErS2xbOFrKFtfYuOXs4wQtrXEtx1LWZHVLGDk WMUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGEMHt/zW3cG4+rXjIUYBDkYlHt6ER5yRQqyJ ZcWVuYcYJTiYlUR4izm5I4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzOuy7ECEkkJ5YkpqdmlqQ WgSTZeLglGpgjL52/0rax7rtgiy7t3j9n3snofK/7R7h0mXSMyWfNsx07uz+MOXdNvm/KfX3 mHS0YiL7/7+ctujFqrkNSw/zvVFwfLbqSsivVj3n7Lu6M3fybjUv2N50/satJUc/vlxtplrq W9/E6Xkq8JJFTnpqKuuv2Q/PmUl936o494H74p2djJlcN7Z8tVdiKc5INNRiLipOBAAcc87p nQIAAA== Archived-At: Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 11:08:37 -0000 --_000_D530E71A1C16Dchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I intend to move forward with option 2), and submit a new version of draft-= mux-exclusive. I.e., the draft will NOT update RFC 8035, but simply indicat= e that RFC 8035 updates the same section and moves the location of the para= graph updated by draft-mux-exclusive. Regards, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Tuesday 2 May 2017 at 14:09 To: Tolga Asveren >, "m= music@ietf.org" > Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC = 8035 Hi, >I got your point but that made me think about a more fundamental issue: Do= es draft-mux-exclusive indeed update RFC5761? >IMHO it is not. It defines a new indicator with its own semantics. This is= a new capability, not something changing a capability already defined. And >it seems =93backward compatibility concerns=94 are already addressed in a = reasonable way by mux-exclusive and RFC8035 updates on RFC5761. > >So, I would: >i- Remove =93Updates: RFC5761=94 statement from the prologue >ii- Remove Section 5. > >If you still want to keep rtcp-mux-exclusive as an =93update on RFC5761=94= , then 2) sounds reasonable to me as well. It was previously agreed to add the text to draft-mux-exclusive= , so I don=92t want to change that at this point. At the end of the day, it= =92s just a clarification specifying that if there is SOME mechanism to ind= icate that separate ports cannot be used, the stream must be disabled. Unfo= rtunately, the RFC8035 update does not add such specification. Option 2) would be adding something like this to draft-mux-exclusive: "NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the paragraph u= pdated in this document is not updated by RFC8035, the location of the para= graph within section 5.1.1 is moved." Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 4:25 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, >i- =93rtcp-mux-exclusive=94 is a new capability/indication, not an update = on RFC5761/8035 per se. >ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional= . >iii- rtcp-mux-exclusive is defined as bidirectional. > >Adding all these together, I fail to see the rationale behind the text. Therefore, I think =934) Do Nothing=94 is the way to go here. Note that the text is already in draft-mux-exclusive, and optio= n 4) would not remove it. The issue is that, based on the update in RFC8035, the text is no longer wi= thin the =934th paragraph=94, as RFC8035 adds new paragraphs, and my questi= on is whether we should somehow point that out within draft-mux-exclusive. >OTOH, I still think that draft-mux-exclusive explicitly should indicate th= at =93rtcp-mux-exclusive itself is bidirectional=94 and that RFC8035 update= d RFC5761 to clarify that =93rtcp-mux is birectional=94. I think we should look at that suggestion (which, btw, I think seems reason= able) as a separate thing. THIS issue is more administrative. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Friday, April 28, 2017 5:57 AM To: mmusic@ietf.org Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also u= pdates section 5.1.1 of RFC 8035. draft-mux-exclusive keeps the existing text, and adds some new (= ). Update to 4th paragraph of section 5.1.1 OLD TEXT (RFC 5761): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. NEW TEXT (RFC 8035): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. As we can see, the original text is identical in 5761 and 8035. So, there i= s no clash. So far so good. draft-mux-exclusive keeps the existing text, and adds some new (= ). NEW TEXT (draft-mux-exclusive): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signaled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. However, if the offerer indicated in the offer that it = is not able to send and receive RTCP on a separate port, the offerer MUST disable the media streams associated with the attribute. The mechanism for indicating that the offerer is not able to send and receive RTCP on a separate port is outside the scope of this specification. Now, the issue is that, following the update in RFC 8035, the text is no lo= nger within the 4th paragraph of section 5.1.1. So, should we: 1) within draft-mux-exclusive, indicate that both RFC 5761 and RFC 803= 5 are updated; or 2) within draft-mux-exclusive, add a note indicating which paragraph i= s affected following the update in RFC 8035 3) within draft-mux-exclusive, ONLY update RFC 8035; or 4) o nothing My first reaction would be to go for option 2), as there IMO is no reason t= o formally update the text in RFC 8035. Regards, Christer --_000_D530E71A1C16Dchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I intend to move forward with option 2), and submit a new version of d= raft-mux-exclusive. I.e., the draft will NOT update RFC 8035, but simply in= dicate that RFC 8035 updates the same section and moves the location of the= paragraph updated by draft-mux-exclusive.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Tuesday 2 May 2017 at 14:09 To: Tolga Asveren <tasveren@sonusnet.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] RFC 5761 upda= ted by both draft-mux-exclusive and RFC 8035

Hi,

>I got your point but that made me think about a = more fundamental issue: Does draft-mux-exclusive indeed update RFC5761?

>IMHO it is not. It defines a new indicator with = its own semantics. This is a new capability, not something changing a capab= ility already defined. And

>it seems =93backward compatibilit= y concerns=94 are already addressed in a reasonable way by mux-exclusive an= d RFC8035 updates on RFC5761.

> 

>So, I would:

>i- Remove =93Updates: RFC5761=94 statement from = the prologue

>ii- Remove Section 5.

>

>If you still want to keep rtcp-mux-exclusive as = an =93update on RFC5761=94, then 2) sounds reasonable to me as well.

 
It was previously agreed to add the <new></new> text to dr= aft-mux-exclusive, so I don=92t want to change that at this point. At the e= nd of the day, it=92s just a clarification specifying that if there is SOME= mechanism to indicate that separate ports cannot be used, the stream must be disabled. Unfortunately, the RFC8035 update do= es not add such specification.

Option 2) would be adding something like this to draft-mux-exclusive:<= /div>

"NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the p= aragraph updated in this document is not updated by RFC8035, the location o= f the paragraph within section 5.1.1 is moved."

Regards,

Christer



 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, May 2, 2017 4:25 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 80= 35

 

Hi,

&n= bsp;

>i- =93rtcp-mux-exclu= sive=94 is a new capability/indication, not an update on RFC5761/8035 per s= e.

>ii- RFC8035 updates = RFC5761 so that rtcp-mux is used only as bidirectional.

>iii- rtcp-mux-exclus= ive is defined as bidirectional.

> 

>Adding all these tog= ether, I fail to see the rationale behind the <new></new> text.= Therefore, I think =934) Do Nothing=94 is the way to go here.

 =

Note th= at the <new></new> text is already in draft-mux-exclusive, and = option 4) would not remove it. 

&n= bsp;

The iss= ue is that, based on the update in RFC8035, the text is no longer within th= e =934th paragraph=94, as RFC8035 adds new paragraphs, and my question is w= hether we should somehow point that out within draft-mux-exclusive.

&n= bsp;

>OTOH, I still think = that draft-mux-exclusive explicitly should indicate that =93rtcp-mux-exclus= ive itself is bidirectional=94 and that RFC8035 updated RFC5761 to clarify = that =93rtcp-mux is birectional=94.

&n= bsp;

I think= we should look at that suggestion (which, btw, I think seems reasonable) a= s a separate thing. THIS issue is more administrative.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

 =

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: mmusic@ietf.org
Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and R= FC 8035

 = 

Hi,
draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 al=
so updates section 5.1.1 of RFC 8035.
draft-mux-exclusive keeps the existing text, and a=
dds some new (<new></new>).<=
o:p>
 <=
/o:p>
Update to=
 4th paragraph of section 5.1.1=

 
 
OLD TEXT (RFC 5761):

 


   If the answer does not contai=
n an "a=3Drtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


NEW TEXT (RF=
C 8035):


  =
 If the answer does not contain an "a=3Drtcp-mux" attribute, the =
offerer


   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


As we can se=
e, the original text is identical in 5761 and 8035. So, there is no clash. =
So far so good.


draft-mux-ex=
clusive keeps the existing text, and adds some new (<new></new>=
).


 <=
/o:p>


NEW TEXT (dr=
aft-mux-exclusive):


 


   If the answer does not contai=
n an "a=3Drtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signaled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute. <new> However, if the offerer indicated in the offer t=
hat it is


   not able to send and receive RT=
CP on a separate port, the offerer<=
/o:p>


   MUST disable the media streams =
associated with the attribute. The<=
/o:p>


   mechanism for indicating that t=
he offerer is not able to send and<=
/o:p>


   receive RTCP on a separate port=
 is outside the scope of this=



   specification.</new>




 






Now, the issue is that, following the upda=
te in RFC 8035, the text is no longer within the 4th paragraph of section 5=
.1.1. So, should we:






 






1) &nb=
sp;    within draft-mux-exclusive, indicate that both=
 RFC 5761 and RFC 8035 are updated; or






2)  &n=
bsp;   within draft-mux-exclusive, add a note indicating w=
hich paragraph is affected following the update in RFC 8035






3) &nb=
sp;    within draft-mux-exclusive, ONLY update RFC 80=
35; or






4) &nb=
sp;    o nothing






 






My first reaction would be to go for optio=
n 2), as there IMO is no reason to formally update the text in RFC 8035. 






 






Regards,






 






Christer






 






 
--_000_D530E71A1C16Dchristerholmbergericssoncom_-- From nobody Fri May 5 05:57:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79010129473 for ; Fri, 5 May 2017 05:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 JyGnGIIJWzmP for ; Fri, 5 May 2017 05:57:20 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14CAD127866 for ; Fri, 5 May 2017 05:57:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35717; q=dns/txt; s=iport; t=1493989039; x=1495198639; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=XkfI0QVGcM76dqycRJoGWMnFIUJYWtY4BjTN3fxMBIU=; b=Yk1TXK3Xrqmye6Nt0WwXEW7tRv9axil59F6Iylk6xgBZg6nlTvMtaWJo RDSK9r4LDBRAJEJR7ewsIH/CSEgiDakfkKyMpyfDfbJ/YhXfWYsRbz72L /Rcr1o5MagSbD5nPNUa3ChrpPOVvLoWGvlVQxdPtw/IVHdUAMQZilo/JA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAABQdQxZ/40NJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5nYoEMjgCRNiGVcIIMAyEBCoUuSgKERz8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQECAQEBK0EQCwsRAwEBAQEgAQYHJx8JCAYBDAYCAQGKDwUIDrNmK4o6A?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGX4FeKwuCZYE8g0cWhS8FlmGHDpMXggS?= =?us-ascii?q?IfIZoiHqLPR84P0tOIRVGhH+CDyQ2hjgFAoI2AQEB?= X-IronPort-AV: E=Sophos;i="5.38,292,1491264000"; d="scan'208,217";a="239767269" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 May 2017 12:57:17 +0000 Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v45CvGux012089; Fri, 5 May 2017 12:57:17 GMT To: Christer Holmberg , "Asveren, Tolga" , "mmusic@ietf.org" References: From: Flemming Andreasen Message-ID: <18c1c5e6-9c26-cbad-7174-946592f9e6e5@cisco.com> Date: Fri, 5 May 2017 08:57:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BB3019F5807ED3E02B9DB3EC" Archived-At: Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 12:57:23 -0000 This is a multi-part message in MIME format. --------------BB3019F5807ED3E02B9DB3EC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sounds reasonable to me -- Flemming (as individual) On 5/4/17 7:08 AM, Christer Holmberg wrote: > Hi, > > I intend to move forward with option 2), and submit a new version of > draft-mux-exclusive. I.e., the draft will NOT update RFC 8035, but > simply indicate that RFC 8035 updates the same section and moves the > location of the paragraph updated by draft-mux-exclusive. > > Regards, > > Christer > > From: mmusic > on behalf of Christer Holmberg > > > Date: Tuesday 2 May 2017 at 14:09 > To: Tolga Asveren >, "mmusic@ietf.org > " > > Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and > RFC 8035 > > Hi, > > >I got your point but that made me think about a more fundamental issue: Does > draft-mux-exclusive indeed update RFC5761? > > >IMHO it is not. It defines a new indicator with its own semantics. This is a new capability, not > something changing a capability already defined. And > > >it seems “backward compatibility concerns” are already addressed in a > reasonable way by mux-exclusive and RFC8035 updates on RFC5761. > > > > > >So, I would: > > >i- Remove “Updates: RFC5761” statement from the prologue > > >ii- Remove Section 5. > > > > > >If you still want to keep rtcp-mux-exclusive as an “update on RFC5761”, then 2) sounds > reasonable to me as well. > > It was previously agreed to add the text to > draft-mux-exclusive, so I don’t want to change that at this point. At > the end of the day, it’s just a clarification specifying that if there > is SOME mechanism to indicate that separate ports cannot be used, the > stream must be disabled. Unfortunately, the RFC8035 update does not > add such specification. > > Option 2) would be adding something like this to draft-mux-exclusive: > > "NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the > paragraph updated in this document is not updated by RFC8035, the > location of the paragraph within section 5.1.1 is moved." > > Regards, > > Christer > > > > *From:* Christer Holmberg [mailto:christer.holmberg@ericsson.com] > *Sent:* Tuesday, May 2, 2017 4:25 AM > *To:* Asveren, Tolga >; mmusic@ietf.org > *Subject:* Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 > > Hi, > > >i- “rtcp-mux-exclusive” is a new capability/indication, not an update on > RFC5761/8035 per se. > > >ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional. > > >iii- rtcp-mux-exclusive is defined as bidirectional. > > > > > >Adding all these together, I fail to see the rationale behind the > text. Therefore, I think “4) Do Nothing” is the way to go > here. > > Note that the text is already in draft-mux-exclusive, and > option 4) would not remove it. > > The issue is that, based on the update in RFC8035, the text is no > longer within the “4th paragraph”, as RFC8035 adds new paragraphs, and > my question is whether we should somehow point that out within > draft-mux-exclusive. > > >OTOH, I still think that draft-mux-exclusive explicitly should indicate > that “rtcp-mux-exclusive itself is bidirectional” and that RFC8035 > updated RFC5761 to clarify that “rtcp-mux is birectional”. > > I think we should look at that suggestion (which, btw, I think seems > reasonable) as a separate thing. THIS issue is more administrative. > > Regards, > > Christer > > *From:*mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Christer > Holmberg > *Sent:* Friday, April 28, 2017 5:57 AM > *To:* mmusic@ietf.org > *Subject:* [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and > RFC 8035 > > Hi, > draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 > also updates section 5.1.1 of RFC 8035. > draft-mux-exclusive keeps the existing text, and adds some new > (). > *Update to 4th paragraph of section 5.1.1* > OLD TEXT (RFC 5761): > If the answer does not contain an "a=rtcp-mux" attribute, the offerer > MUST NOT multiplex RTP and RTCP packets on a single port. Instead, > it should send and receive RTCP on a port allocated according to the > usual port-selection rules (either the port pair, or a signalled port > if the "a=rtcp:" attribute [10] is also included). This will occur > when talking to a peer that does not understand the "a=rtcp-mux" > attribute. > NEW TEXT (RFC 8035): > If the answer does not contain an "a=rtcp-mux" attribute, the offerer > MUST NOT multiplex RTP and RTCP packets on a single port. Instead, > it should send and receive RTCP on a port allocated according to the > usual port-selection rules (either the port pair, or a signalled port > if the "a=rtcp:" attribute [10] is also included). This will occur > when talking to a peer that does not understand the "a=rtcp-mux" > attribute. > As we can see, the original text is identical in 5761 and 8035. So, > there is no clash. So far so good. > draft-mux-exclusive keeps the existing text, and adds some new > (). > NEW TEXT (draft-mux-exclusive): > If the answer does not contain an "a=rtcp-mux" attribute, the offerer > MUST NOT multiplex RTP and RTCP packets on a single port. Instead, > it should send and receive RTCP on a port allocated according to the > usual port-selection rules (either the port pair, or a signaled port > if the "a=rtcp:" attribute [10] is also included). This will occur > when talking to a peer that does not understand the "a=rtcp-mux" > attribute. However, if the offerer indicated in the offer > that it is > not able to send and receive RTCP on a separate port, the offerer > MUST disable the media streams associated with the attribute. The > mechanism for indicating that the offerer is not able to send and > receive RTCP on a separate port is outside the scope of this > specification. > Now, the issue is that, following the update in RFC 8035, the text is > no longer within the 4th paragraph of section 5.1.1. So, should we: > 1)within draft-mux-exclusive, indicate that both RFC 5761 and RFC 8035 > are updated; or > 2) within draft-mux-exclusive, add a note indicating which paragraph > is affected following the update in RFC 8035 > 3)within draft-mux-exclusive, ONLY update RFC 8035; or > 4)o nothing > My first reaction would be to go for option 2), as there IMO is no > reason to formally update the text in RFC 8035. > Regards, > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------BB3019F5807ED3E02B9DB3EC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Sounds reasonable to me

-- Flemming (as individual)

On 5/4/17 7:08 AM, Christer Holmberg wrote:
Hi,

I intend to move forward with option 2), and submit a new version of draft-mux-exclusive. I.e., the draft will NOT update RFC 8035, but simply indicate that RFC 8035 updates the same section and moves the location of the paragraph updated by draft-mux-exclusive.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Christer Holmberg <christer.holmberg@ericsson.com>
Date: Tuesday 2 May 2017 at 14:09
To: Tolga Asveren <tasveren@sonusnet.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035

Hi,

>I got your point but that made me think about a more fundamental issue: Does draft-mux-exclusive indeed update RFC5761?

>IMHO it is not. It defines a new indicator with its own semantics. This is a new capability, not something changing a capability already defined. And

>it seems “backward compatibility concerns” are already addressed in a reasonable way by mux-exclusive and RFC8035 updates on RFC5761.

> 

>So, I would:

>i- Remove “Updates: RFC5761” statement from the prologue

>ii- Remove Section 5.

>

>If you still want to keep rtcp-mux-exclusive as an “update on RFC5761”, then 2) sounds reasonable to me as well.

 
It was previously agreed to add the <new></new> text to draft-mux-exclusive, so I don’t want to change that at this point. At the end of the day, it’s just a clarification specifying that if there is SOME mechanism to indicate that separate ports cannot be used, the stream must be disabled. Unfortunately, the RFC8035 update does not add such specification.

Option 2) would be adding something like this to draft-mux-exclusive:

"NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the paragraph updated in this document is not updated by RFC8035, the location of the paragraph within section 5.1.1 is moved."

Regards,

Christer



 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, May 2, 2017 4:25 AM
To: Asveren, Tolga <tasveren@sonusnet.com>; mmusic@ietf.org
Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035

 

Hi,

 

>i- “rtcp-mux-exclusive” is a new capability/indication, not an update on RFC5761/8035 per se.

>ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional.

>iii- rtcp-mux-exclusive is defined as bidirectional.

> 

>Adding all these together, I fail to see the rationale behind the <new></new> text. Therefore, I think “4) Do Nothing” is the way to go here.

 

Note that the <new></new> text is already in draft-mux-exclusive, and option 4) would not remove it. 

 

The issue is that, based on the update in RFC8035, the text is no longer within the “4th paragraph”, as RFC8035 adds new paragraphs, and my question is whether we should somehow point that out within draft-mux-exclusive.

 

>OTOH, I still think that draft-mux-exclusive explicitly should indicate that “rtcp-mux-exclusive itself is bidirectional” and that RFC8035 updated RFC5761 to clarify that “rtcp-mux is birectional”.

 

I think we should look at that suggestion (which, btw, I think seems reasonable) as a separate thing. THIS issue is more administrative.

 

Regards,

 

Christer

 

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: mmusic@ietf.org
Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035

 

Hi,
draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also updates section 5.1.1 of RFC 8035.
draft-mux-exclusive keeps the existing text, and adds some new (<new></new>).
 
Update to 4th paragraph of section 5.1.1
 
 
OLD TEXT (RFC 5761):
 
   If the answer does not contain an "a=rtcp-mux" attribute, the offerer
   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
   it should send and receive RTCP on a port allocated according to the
   usual port-selection rules (either the port pair, or a signalled port
   if the "a=rtcp:" attribute [10] is also included).  This will occur
   when talking to a peer that does not understand the "a=rtcp-mux"
   attribute.
 
NEW TEXT (RFC 8035):
   If the answer does not contain an "a=rtcp-mux" attribute, the offerer
   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
   it should send and receive RTCP on a port allocated according to the
   usual port-selection rules (either the port pair, or a signalled port
   if the "a=rtcp:" attribute [10] is also included).  This will occur
   when talking to a peer that does not understand the "a=rtcp-mux"
   attribute.
 
As we can see, the original text is identical in 5761 and 8035. So, there is no clash. So far so good.
draft-mux-exclusive keeps the existing text, and adds some new (<new></new>).
 
NEW TEXT (draft-mux-exclusive):
 
   If the answer does not contain an "a=rtcp-mux" attribute, the offerer
   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
   it should send and receive RTCP on a port allocated according to the
   usual port-selection rules (either the port pair, or a signaled port
   if the "a=rtcp:" attribute [10] is also included).  This will occur
   when talking to a peer that does not understand the "a=rtcp-mux"
   attribute. <new> However, if the offerer indicated in the offer that it is
   not able to send and receive RTCP on a separate port, the offerer
   MUST disable the media streams associated with the attribute. The
   mechanism for indicating that the offerer is not able to send and
   receive RTCP on a separate port is outside the scope of this
   specification.</new>
 
Now, the issue is that, following the update in RFC 8035, the text is no longer within the 4th paragraph of section 5.1.1. So, should we:
 
1)      within draft-mux-exclusive, indicate that both RFC 5761 and RFC 8035 are updated; or
2)      within draft-mux-exclusive, add a note indicating which paragraph is affected following the update in RFC 8035
3)      within draft-mux-exclusive, ONLY update RFC 8035; or
4)      o nothing
 
My first reaction would be to go for option 2), as there IMO is no reason to formally update the text in RFC 8035. 
 
Regards,
 
Christer
 
 
 

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

--------------BB3019F5807ED3E02B9DB3EC-- From nobody Fri May 5 06:17:08 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA7B126C83 for ; Fri, 5 May 2017 06:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 oT3MxYGFThkt for ; Fri, 5 May 2017 06:17:04 -0700 (PDT) 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 49582126B6E for ; Fri, 5 May 2017 06:17:04 -0700 (PDT) X-AuditID: c1b4fb30-663149a00000015f-45-590c7b4e6356 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 92.FB.00351.E4B7C095; Fri, 5 May 2017 15:17:02 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 5 May 2017 15:17:00 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VOLDqzlGV4sJaoEIqlAzSAtm3qfXgeF7KqIQQNBK9qE=; b=S7qCbiegW+MHjO0A2DpbRpqvAYIKvRwwy/GN6jyQ15hBgOd5vL6o6PaWtF/hHmY75OW6wRsUK0p9SL6ymWakDh/A9VKoCaVgR9wFcmDhxaByNtlBUST1dmkw+NOSuiPsCFDtyBsair3SGTcgsU7DjfEJjP+6fTc/9d+SrzdmBz0= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2579.eurprd07.prod.outlook.com (10.173.92.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 5 May 2017 13:16:59 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.1084.007; Fri, 5 May 2017 13:16:59 +0000 From: Bo Burman To: Paul Kyzivat , Flemming Andreasen , "mmusic@ietf.org" , "mmusic-chairs@tools.ietf.org" Thread-Topic: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 Thread-Index: AQHSurMSc+HCW/Aa3ESGugkflWHKa6HQIqAAgAAW7gCAFZQeUA== Date: Fri, 5 May 2017 13:16:59 +0000 Message-ID: References: <1bebf711-3459-a30f-44d2-e182b6fb132e@comcast.net> <34b42aa1-adc0-ea98-a0c3-beec16bcd69e@comcast.net> In-Reply-To: <34b42aa1-adc0-ea98-a0c3-beec16bcd69e@comcast.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: comcast.net; dkim=none (message not signed) header.d=none;comcast.net; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2579; 7:DFFBcmj5rcnpAMmdPvSyKA7E4xOOlOQPJ/D9x4u9Dr8WeYba6VUqBbprR+6ULxOzUcTKh6Bp3S8oMfSC7vTtcS5M9NArGbLNq10OYbSDnt6Z764HrW9mrjpENCO6Q4evnE83w6frKsXN7thPsvPWMhz7kvG0WAeG4KY/rcJuF+MwfxtyFRQ/EJ1Rm6I2zE/hQed8nAB//o+vhI2Gp5d9WlHipL8nOBdtpX0ZUeE+WHmkwzGvKBpFUyntKFb7O4Q18PVgoFSrLNK//jal6xI31FzXsZ9OZ9mWxO+jKNa+UWcw87unW3Um0ZUYrdXRrrpc0wFioLcc+dYhle0Qk3Q6IQ== x-ms-office365-filtering-correlation-id: 1a381fc4-cd42-46cc-3dd3-08d493b902fd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2579; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(82608151540597)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:AM5PR0701MB2579; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2579; x-forefront-prvs: 02981BE340 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39860400002)(39840400002)(39850400002)(39400400002)(39410400002)(13464003)(24454002)(377454003)(52314003)(230783001)(6436002)(50986999)(189998001)(6506006)(76176999)(54356999)(77096006)(3846002)(25786009)(102836003)(6116002)(229853002)(33656002)(7696004)(53546009)(74316002)(7736002)(305945005)(2950100002)(5660300001)(99286003)(8666007)(9686003)(6306002)(55016002)(38730400002)(6246003)(53936002)(81166006)(8676002)(3280700002)(3660700001)(478600001)(2900100001)(2501003)(2201001)(122556002)(86362001)(66066001)(2906002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2579; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 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-originalarrivaltime: 05 May 2017 13:16:59.2995 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2579 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUyM2K7sa5fNU+kwZs1mhbvL+ha/NubZDF1 +WMWiwc/etkcWDym/N7I6jH58RxGjyVLfjJ5fLn8mS2AJYrLJiU1J7MstUjfLoErY2LjfeaC zpSKtmWv2BoYz/t1MXJySAiYSNz6+o6li5GLQ0jgCKPE7lPTmSCc44wSc/c/ZgdxWAR6mSWO nb/BCJGZziRxruU0I1zZ5s42NpBhbAIaEvN33AVLiAjsYZQ49uwIE0hCWCBK4syBK0BFHECJ aIkv16xAwiICThLbdjSAlbAIqEi0PL3BDmLzCiRIrG35zQqxoJFN4n7LVrAFnAL2EpvavrOA 2IwCshL3v98Ds5kFxCVuPZnPBPGRgMSSPeeZIWxRiZeP/4ENYhSYyChx+f59qISCxP1fk6Fs WYlL87vBrpYQ6GOWWNwyHSrhKzHz0SN2iEQDo0RvYxMbRCJf4nfXGah1URJPv7+D6v7GJLF6 xUWoIhmJnatus0IkrrBKbFj/hB0SGFISd690MkLYMhIv7uxlncCoOQvJHxC2jsSC3Z/YIGxt iWULXzPPAgeOoMTJmU9YFjCyrGIULU4tTspNNzLSSy3KTC4uzs/Ty0st2cQITDMHt/w22MH4 8rnjIUYBDkYlHl6FHO5IIdbEsuLK3EOMEhzMSiK8qeU8kUK8KYmVValF+fFFpTmpxYcYpTlY lMR5HfddiBASSE8sSc1OTS1ILYLJMnFwSjUw9n648alSL2FxCVf74z9Hty29NntSx75Wx7L3 28s/mXY4GXQpRNkru6S/PRmgwq90j6d+l+u14y+Pne1pcDi1PkHg6FG1hZbnZpos2nPob6KU 42PdvE07z5tzpLyfn52xIr3xkVJ++Mqmt4UCO/qSJCcZKMRFyB2W27f5+MZpQk8r3/sL7WVy VWIpzkg01GIuKk4EALpO7dovAwAA Archived-At: Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 13:17:08 -0000 Since we did not hear any objections to this change, can the authors please= provide an updated document and we will then proceed with publication requ= est. Cheers /Bo MMUSIC co-chair > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: den 21 april 2017 21:43 > To: Flemming Andreasen ; mmusic@ietf.org; mmusic-chai= rs@tools.ietf.org > Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-ch= annel-sdpneg-11 >=20 > On 4/21/17 2:20 PM, Flemming Andreasen wrote: > > Hi Paul > > > > From a chair point of view, we are prioritizing the deliverables that > > have external dependencies, and we still have several of those for > > RTCWeb. 4566bis may or may not be ready to advance at this point, > > however we prefer to focus the group on the RTCWeb deliverables for now= . >=20 > OK. But when it starts to block things then it out to get done. >=20 > Thanks, > Paul >=20 > > Cheers > > > > -- Flemming (as MMUSIC co-chair) > > > > On 4/21/17 11:21 AM, Paul Kyzivat wrote: > >> On 4/21/17 9:50 AM, Bo Burman wrote: > >>> Hi Raju, > >>> > >>> Unless someone strongly objects, and given that a) 4566bis is > >>> nowhere near to RFC status, b) there are other documents that make > >>> use of the new template, without normatively referencing 4566bis, > >>> and c) that we have documents with dependencies on -sdpneg that we > >>> want to progress and avoid becoming stuck in RFC Editor's queue in > >>> MISSREF, I still believe that it would be better to make it an inform= ative reference. > >> > >> I don't see a need for a normative reference to 4566bis. > >> > >> OTOH, AFAIK there is nothing to prevent 4566bis from going to WGLC > >> *today*. It just needs for the motion to be made. I'm interested to > >> hear about this from the chairs. > >> > >> Thanks, > >> Paul > >> > >>> Cheers, > >>> > >>> /Bo > >>> > >>> > >>> > >>> *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] > >>> *Sent:* den 15 mars 2017 18:21 > >>> *To:* Bo Burman ; mmusic (mmusic@ietf.org) > >>> > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 > >>> > >>> > >>> > >>> Hi Bo, Paul, > >>> > >>> Since I don't have a strong preference one way or other, I slightly > >>> lean towards to keeping 4566bis as a normative reference for the > >>> mentioned reason 'use of new template defined by 4566bis'. > >>> > >>> I assume the impact of this being both must get RFC status > >>> simultaneously!? > >>> > >>> Do you know if 4566bis is close to RFC status? > >>> > >>> > >>> > >>> Bo, really appreciate bringing these comments to our attention! > >>> > >>> > >>> > >>> Thanks > >>> > >>> Raju > >>> > >>> > >>> > >>> *From:* Bo Burman [mailto:bo.burman@ericsson.com] > >>> *Sent:* Wednesday, March 15, 2017 11:11 AM > >>> *To:* Makaraju, Raju (Nokia - US) >>> >; mmusic (mmusic@ietf.org > >>> ) > > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 > >>> > >>> > >>> > >>> Hi Raju, > >>> > >>> > >>> > >>> I should probably have remembered also this in my "unaddressed" list > >>> below, but I put a question to the list to change 4566bis from > >>> normative to informative reference > >>> (https://mailarchive.ietf.org/arch/msg/mmusic/8TZ_yX45geKewDqgHCv1Hm > >>> URC-I), > >>> > >>> which seemed acceptable to Paul K, but so far no one else answered. > >>> What is the author's view on this? > >>> > >>> > >>> > >>> /Bo > >>> > >>> > >>> > >>> *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] > >>> *Sent:* den 13 mars 2017 22:57 > >>> *To:* Bo Burman >>> >; mmusic (mmusic@ietf.org > >>> ) > > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 > >>> > >>> > >>> > >>> Hi Bo, > >>> > >>>> It was a bit unclear if it was some kind of quote from somewhere, > >>> which is also commonly indicated by such indentation. I suggest just > >>> making it explicit that it is a note, starting the first line > >>> > >>>> with "Note: ". > >>> > >>> > >>> > >>> Will do. Thanks. > >>> > >>> > >>> > >>> BR > >>> > >>> Raju > >>> > >>> > >>> > >>> *From:* Bo Burman [mailto:bo.burman@ericsson.com] > >>> *Sent:* Monday, March 13, 2017 6:30 AM > >>> *To:* Makaraju, Raju (Nokia - US) >>> >; mmusic (mmusic@ietf.org > >>> ) > > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 > >>> > >>> > >>> > >>> Hi Raju, > >>> > >>> > >>> > >>> Regarding: > >>> > >>> 9) In Appendix A.1: Why are two paragraphs starting with "For da= ta > >>> channels negotiated" indented compared to other text? Is it supposed > >>> to be some kind of note? > >>> > >>> */[Raju] Yes, meant to be a note. Need to change indentation? Or > >>> change to some other style?/* > >>> > >>> > >>> > >>> It was a bit unclear if it was some kind of quote from somewhere, > >>> which is also commonly indicated by such indentation. I suggest just > >>> making it explicit that it is a note, starting the first line with "N= ote: ". > >>> > >>> > >>> > >>> /Bo > >>> > >>> > >>> > >>> *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] > >>> *Sent:* den 13 mars 2017 02:52 > >>> *To:* Bo Burman >>> >; mmusic (mmusic@ietf.org > >>> ) > > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 > >>> > >>> > >>> > >>> Hi Bo Burman, Christian Groves, Paul Kyzivat, > >>> > >>> > >>> > >>> Thank you so much for your time in making this document better, we > >>> appreciate it. Sorry for the extended delay. > >>> > >>> I accepted all the comments. > >>> > >>> Please see my comments inserted below. > >>> > >>> > >>> > >>> Thanks again > >>> > >>> Raju > >>> > >>> > >>> > >>> > >>> > >>> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Bo > >>> Burman > >>> *Sent:* Tuesday, February 28, 2017 10:11 AM > >>> *To:* mmusic (mmusic@ietf.org ) > >>> > > >>> *Subject:* [ALU] [MMUSIC] Shepherd's review > >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 > >>> > >>> > >>> > >>> Authors, WG, > >>> > >>> > >>> > >>> I think this document is getting ready for publication request. As > >>> part of making the shepherd's write-up, I have the following > >>> comments, to be addressed in an updated document: > >>> > >>> > >>> > >>> Issues: > >>> > >>> 1) In section 1: add that also BFCP (Binary Floor Control > >>> Protocol) is used in the same way as MSRP in examples. > >>> > >>> */[Raju] Will add BFCP./* > >>> > >>> 2) In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infinite lengt= h of > >>> this identifier, which seems inappropriate. I suggest providing a > >>> maximum length, maybe matching this to the unsigned 16 bit integer > >>> in SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient. > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> 3) In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing = "x" > >>> after "%" when defining hex characters. Change to: > >>> quoted-visible =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or % > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> 4) In 5.1.2.1, text below the example makes reference to MSRP > >>> subprotocol, but the example does not explicitly include any MSRP. > >>> The single example line uses "accept-types", which is admittedly > >>> related to MSRP, but I think this should be clarified to avoid > >>> confusion for readers not familiar with MSRP. > >>> > >>> */[Raju] Will change "Example" to "Example (other MSRP related SDP > >>> attributes are omitted for brevity):"/* > >>> > >>> 5) In 5.2.2: It is unclear why you differentiate handling of off= ers > >>> and answers that contain both "max-retr" and "max-time", mandating > >>> to reject the offer but allowing it in the answer. I think allowing > >>> this asymmetry should either be motivated, or handling should be > >>> aligned between offer and answer. > >>> > >>> */[Raju] I think it was thought giving a bit of flexibility to > >>> offerer while receiving answer is probably good but I see your point > >>> on aligning both. Will change text to align both./* > >>> > >>> 6) In section 6: several examples uses IP addresses that are not > >>> aligned with RFC 6890 (10.10.10.x), which must be changed. > >>> Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 > >>> (TEST-NET-2), or 203.0.113.0/24 (TEST-NET-3). > >>> > >>> */[Raju] Will change as suggested. /* > >>> > >>> 7) In Appendix A: same IP address issue as above, change from > >>> 79.97.215.79 to an address in the allowed range. > >>> > >>> */[Raju] Will change as suggested. /* > >>> > >>> > >>> > >>> Nits: > >>> > >>> 1) The date line in the document header is one character too lon= g > >>> (beyond column 72) > >>> > >>> */[Raju] Good catch! Hmmm... not sure how it is getting messed up as > >>> the it is supposed to be an auto generated line. Anyway, I just > >>> checked the new updated draft at > >>> /*https://xml2rfc.tools.ietf.org*/and output looks > >>> good./* > >>> > >>> 2) In section 1: s/In future data channels could/In the future, > >>> data channels could/ > >>> > >>> */[Raju] Will change as suggested. /* > >>> > >>> 3) In section 3: s/sending and receive data/sending and > >>> receiving data/ > >>> > >>> */[Raju] Will change as suggested. /* > >>> > >>> 4) At the very end of section 5.1.2.1: s/in the same document, > >>> which registers/in the same document that registers/ > >>> > >>> */[Raju] Will change as suggested. /* > >>> > >>> 5) In 5.2.4: s/other data channels which are now not included/ot= her > >>> data channels that are now not included/ > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> 6) In 5.2.5: s/channels are expected be closed now/channels are > >>> expected to be closed now/ > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> 7) In 8.3: s/dcsa usage level only shall use/dcsa usage level on= ly > >>> SHALL use/ > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> 8) In Appendix A.1: s/either pass to the data channel stack the > >>> stream identifier to assign/either pass the stream identifier to the > >>> data channel stack to assign/ > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> 9) In Appendix A.1: Why are two paragraphs starting with "For da= ta > >>> channels negotiated" indented compared to other text? Is it supposed > >>> to be some kind of note? > >>> > >>> */[Raju] Yes, meant to be a note. Need to change indentation? Or > >>> change to some other style?/* > >>> > >>> > >>> > >>> Comments from others that are not addressed in -11: > >>> > >>> 1) Christian Groves commented on Jan 20 that the example in > >>> Appendix A should contain an "a=3Ddtls-id:..." attribute as per other > >>> examples in the draft. > >>> > >>> */[Raju] Will add a=3Ddtls-id./* > >>> > >>> 2) Paul Kyzivat commented on Jan 21 that a bullet in section 5.2= .3 > >>> should be changed to: > >>> o For accepted data channels, the agent MUST create peer instances > >>> for the data channels using the SCTP stream identifiers and > >>> channel parameters contained in the SDP offer. > >>> > >>> */[Raju] Will change as suggested./* > >>> > >>> */ /* > >>> > >>> */Thanks/* > >>> > >>> */raju/* > >>> > >>> > >>> > >>> Cheers, > >>> > >>> /Bo > >>> > >>> MMUSIC co-chair > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >>> > >> > >> . > >> > > > > >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri May 5 06:54:57 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC1D1289B5; Fri, 5 May 2017 06:54:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149399248789.8528.10714714269929070830@ietfa.amsl.com> Date: Fri, 05 May 2017 06:54:47 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-mux-exclusive-12.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 13:54:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP Author : Christer Holmberg Filename : draft-ietf-mmusic-mux-exclusive-12.txt Pages : 14 Date : 2017-05-05 Abstract: This document defines a new SDP media-level attribute, 'rtcp-mux- only', that can be used by an endpoint to indicate exclusive support of RTP/RTCP multiplexing. The document also updates RFC 5761, by clarifying that an offerer can use a mechanism to indicate that it is not able to send and receive RTCP on separate ports. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-mux-exclusive/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-mux-exclusive-12 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-mux-exclusive-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-mux-exclusive-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 Fri May 5 06:57:03 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EBE129485 for ; Fri, 5 May 2017 06:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 L2TnOhDRknIj for ; Fri, 5 May 2017 06:56:58 -0700 (PDT) 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 718BA1294CC for ; Fri, 5 May 2017 06:56:57 -0700 (PDT) X-AuditID: c1b4fb3a-f56d89a000005025-e1-590c84a74f53 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id CB.9A.20517.7A48C095; Fri, 5 May 2017 15:56:55 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0339.000; Fri, 5 May 2017 15:56:43 +0200 From: Christer Holmberg To: Flemming Andreasen , "Asveren, Tolga" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Thread-Index: AQHSxMbB9tlWASzsjUecixZeUtGAbKHlkykAgABEUwA= Date: Fri, 5 May 2017 13:56:43 +0000 Message-ID: References: <18c1c5e6-9c26-cbad-7174-946592f9e6e5@cisco.com> In-Reply-To: <18c1c5e6-9c26-cbad-7174-946592f9e6e5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_D532606F1C257christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7h+7yFp5Ig1vvNS3eX9C1mLr8MYvF 7M73TA7MHlN+b2T1WLLkJ5PHpc//2QOYo7hsUlJzMstSi/TtErgyVr6bz1qw/htjxeezp1ka GHdeZexi5OSQEDCRWNn8kbWLkYtDSOAIo8Tbr8/YIZzFjBJzX5wCquLgYBOwkOj+pw3SICJQ I3FqeTcTiC0sECix4Nhvdoh4kET3qatQtpXEheWX2EFaWQRUJDa/qwAxeQWsJZoeJIBUCAnk SbzedZENxOYUsJU49Ose2ERGATGJ76fWgNnMAuISt57MZ4I4U0BiyZ7zzBC2qMTLx/9YQWxR AT2Jff++soGMlxBQlFjeLwfRmiDRt+Yy2Ie8AoISJ2c+YZnAKDILydRZSMpmISmDiBtIvD83 nxnC1pZYtvA1lK0vsfHLWUYI21ri3u6/KGoWMHKsYhQtTi0uzk03MtJLLcpMLi7Oz9PLSy3Z xAiMv4NbflvtYDz43PEQowAHoxIPr0IOd6QQa2JZcWXuIUYJDmYlEd7Ucp5IId6UxMqq1KL8 +KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZODilGhjXrZypLi//YqvcmciQ9tQL HwNXFOs3RXrFsaw4VL9yLldabsXVJ8mbDqvIchnW/lCdoviS8W3BTf7g5r/Jq6rb98w9oRkV //3YM90bCZPf3ZxpbVDadXoK/xvO4xk5Oxf22qQH7uEwvSgdWFq+WezRwTVBTA7t9WEPRapb F3PYNYRWnlhts02JpTgj0VCLuag4EQCqeAj7uwIAAA== Archived-At: Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 13:57:01 -0000 --_000_D532606F1C257christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Version =9612 submitted. Regards, Christer From: Flemming Andreasen > Date: Friday 5 May 2017 at 15:57 To: Christer Holmberg >, Tolga Asveren >, "mmusic@ietf.org" > Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC = 8035 Sounds reasonable to me -- Flemming (as individual) On 5/4/17 7:08 AM, Christer Holmberg wrote: Hi, I intend to move forward with option 2), and submit a new version of draft-= mux-exclusive. I.e., the draft will NOT update RFC 8035, but simply indicat= e that RFC 8035 updates the same section and moves the location of the para= graph updated by draft-mux-exclusive. Regards, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Tuesday 2 May 2017 at 14:09 To: Tolga Asveren >, "m= music@ietf.org" > Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC = 8035 Hi, >I got your point but that made me think about a more fundamental issue: Do= es draft-mux-exclusive indeed update RFC5761? >IMHO it is not. It defines a new indicator with its own semantics. This is= a new capability, not something changing a capability already defined. And >it seems =93backward compatibility concerns=94 are already addressed in a = reasonable way by mux-exclusive and RFC8035 updates on RFC5761. > >So, I would: >i- Remove =93Updates: RFC5761=94 statement from the prologue >ii- Remove Section 5. > >If you still want to keep rtcp-mux-exclusive as an =93update on RFC5761=94= , then 2) sounds reasonable to me as well. It was previously agreed to add the text to draft-mux-exclusive= , so I don=92t want to change that at this point. At the end of the day, it= =92s just a clarification specifying that if there is SOME mechanism to ind= icate that separate ports cannot be used, the stream must be disabled. Unfo= rtunately, the RFC8035 update does not add such specification. Option 2) would be adding something like this to draft-mux-exclusive: "NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the paragraph u= pdated in this document is not updated by RFC8035, the location of the para= graph within section 5.1.1 is moved." Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 4:25 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, >i- =93rtcp-mux-exclusive=94 is a new capability/indication, not an update = on RFC5761/8035 per se. >ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional= . >iii- rtcp-mux-exclusive is defined as bidirectional. > >Adding all these together, I fail to see the rationale behind the text. Therefore, I think =934) Do Nothing=94 is the way to go here. Note that the text is already in draft-mux-exclusive, and optio= n 4) would not remove it. The issue is that, based on the update in RFC8035, the text is no longer wi= thin the =934th paragraph=94, as RFC8035 adds new paragraphs, and my questi= on is whether we should somehow point that out within draft-mux-exclusive. >OTOH, I still think that draft-mux-exclusive explicitly should indicate th= at =93rtcp-mux-exclusive itself is bidirectional=94 and that RFC8035 update= d RFC5761 to clarify that =93rtcp-mux is birectional=94. I think we should look at that suggestion (which, btw, I think seems reason= able) as a separate thing. THIS issue is more administrative. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Friday, April 28, 2017 5:57 AM To: mmusic@ietf.org Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also u= pdates section 5.1.1 of RFC 8035. draft-mux-exclusive keeps the existing text, and adds some new (= ). Update to 4th paragraph of section 5.1.1 OLD TEXT (RFC 5761): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. NEW TEXT (RFC 8035): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. As we can see, the original text is identical in 5761 and 8035. So, there i= s no clash. So far so good. draft-mux-exclusive keeps the existing text, and adds some new (= ). NEW TEXT (draft-mux-exclusive): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signaled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. However, if the offerer indicated in the offer that it = is not able to send and receive RTCP on a separate port, the offerer MUST disable the media streams associated with the attribute. The mechanism for indicating that the offerer is not able to send and receive RTCP on a separate port is outside the scope of this specification. Now, the issue is that, following the update in RFC 8035, the text is no lo= nger within the 4th paragraph of section 5.1.1. So, should we: 1) within draft-mux-exclusive, indicate that both RFC 5761 and RFC 803= 5 are updated; or 2) within draft-mux-exclusive, add a note indicating which paragraph i= s affected following the update in RFC 8035 3) within draft-mux-exclusive, ONLY update RFC 8035; or 4) o nothing My first reaction would be to go for option 2), as there IMO is no reason t= o formally update the text in RFC 8035. Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.orghttps://www.ietf.org/mailman/listinf= o/mmusic --_000_D532606F1C257christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Version =9612 submitted.

Regards,

Christer

From: Flemming Andreasen <fandreas@cisco.com>
Date: Friday 5 May 2017 at 15:57 To: Christer Holmberg <christer.holmberg@ericsson.com>, Tolga Asveren <tasveren= @sonusnet.com>, "mmusic@ietf= .org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] RFC 5761 upda= ted by both draft-mux-exclusive and RFC 8035

Sounds reasonable to me

-- Flemming (as individual)

On 5/4/17 7:08 AM, Christer Holmberg wrote:<= br>
Hi,

I intend to move forward with option 2), and submit a new version of d= raft-mux-exclusive. I.e., the draft will NOT update RFC 8035, but simply in= dicate that RFC 8035 updates the same section and moves the location of the= paragraph updated by draft-mux-exclusive.

Regards,

Christer


Hi,

>I got your point but that made me think about a = more fundamental issue: Does draft-mux-exclusive indeed update RFC5761?

>IMHO it is not. It defines a new indicator with = its own semantics. This is a new capability, not something changing a capab= ility already defined. And

>it seems =93backward compatibilit= y concerns=94 are already addressed in a reasonable way by mux-exclusive an= d RFC8035 updates on RFC5761.

> 

>So, I would:

>i- Remove =93Updates: RFC5761=94 statement from = the prologue

>ii- Remove Section 5.

>

>If you still want to keep rtcp-mux-exclusive as = an =93update on RFC5761=94, then 2) sounds reasonable to me as well.

 
It was previously agreed to add the <new></new> text to dr= aft-mux-exclusive, so I don=92t want to change that at this point. At the e= nd of the day, it=92s just a clarification specifying that if there is SOME= mechanism to indicate that separate ports cannot be used, the stream must be disabled. Unfortunately, the RFC8035 update do= es not add such specification.

Option 2) would be adding something like this to draft-mux-exclusive:<= /div>

"NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the p= aragraph updated in this document is not updated by RFC8035, the location o= f the paragraph within section 5.1.1 is moved."

Regards,

Christer



 

From: Christer Holmberg [mailto:christer.ho= lmberg@ericsson.com]
Sent: Tuesday, May 2, 2017 4:25 AM
To: Asveren, Tolga <tasveren@sonusnet.com>; mmusic@ietf.org=
Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 80= 35

 

Hi,

&n= bsp;

>i- =93rtcp-mux-exclu= sive=94 is a new capability/indication, not an update on RFC5761/8035 per s= e.

>ii- RFC8035 updates = RFC5761 so that rtcp-mux is used only as bidirectional.

>iii- rtcp-mux-exclus= ive is defined as bidirectional.

> 

>Adding all these tog= ether, I fail to see the rationale behind the <new></new> text.= Therefore, I think =934) Do Nothing=94 is the way to go here.

 =

Note th= at the <new></new> text is already in draft-mux-exclusive, and = option 4) would not remove it. 

&n= bsp;

The iss= ue is that, based on the update in RFC8035, the text is no longer within th= e =934th paragraph=94, as RFC8035 adds new paragraphs, and my question is w= hether we should somehow point that out within draft-mux-exclusive.

&n= bsp;

>OTOH, I still think = that draft-mux-exclusive explicitly should indicate that =93rtcp-mux-exclus= ive itself is bidirectional=94 and that RFC8035 updated RFC5761 to clarify = that =93rtcp-mux is birectional=94.

&n= bsp;

I think= we should look at that suggestion (which, btw, I think seems reasonable) a= s a separate thing. THIS issue is more administrative.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

 =

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: mmus= ic@ietf.org
Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and R= FC 8035

 = 

Hi,
draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 al=
so updates section 5.1.1 of RFC 8035.
draft-mux-exclusive keeps the existing text, and a=
dds some new (<new></new>).<=
o:p>
 <=
/o:p>
Update to=
 4th paragraph of section 5.1.1=

 
 
OLD TEXT (RFC 5761):

 


   If the answer does not contai=
n an "a=3Drtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


NEW TEXT (RF=
C 8035):


  =
 If the answer does not contain an "a=3Drtcp-mux" attribute, the =
offerer


   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signalled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute.<=
/pre>

 <=
/o:p>


As we can se=
e, the original text is identical in 5761 and 8035. So, there is no clash. =
So far so good.


draft-mux-ex=
clusive keeps the existing text, and adds some new (<new></new>=
).


 <=
/o:p>


NEW TEXT (dr=
aft-mux-exclusive):


 


   If the answer does not contai=
n an "a=3Drtcp-mux" attribute, the offerer

   MUST NOT multiplex RTP and RT=
CP packets on a single port.  Instead,


   it should send and receive RT=
CP on a port allocated according to the


   usual port-selection rules (e=
ither the port pair, or a signaled port


   if the "a=3Drtcp:" =
attribute [10] is also included).  This will occur

   when talking to a peer that d=
oes not understand the "a=3Drtcp-mux"


   attribute. <new> However, if the offerer indicated in the offer t=
hat it is


   not able to send and receive RT=
CP on a separate port, the offerer<=
/o:p>


   MUST disable the media streams =
associated with the attribute. The<=
/o:p>


   mechanism for indicating that t=
he offerer is not able to send and<=
/o:p>


   receive RTCP on a separate port=
 is outside the scope of this=



   specification.</new>




 






Now, the issue is that, following the upda=
te in RFC 8035, the text is no longer within the 4th paragraph of section 5=
.1.1. So, should we:






 






1) &nb=
sp;    within draft-mux-exclusive, indicate that both=
 RFC 5761 and RFC 8035 are updated; or






2)  &n=
bsp;   within draft-mux-exclusive, add a note indicating w=
hich paragraph is affected following the update in RFC 8035






3) &nb=
sp;    within draft-mux-exclusive, ONLY update RFC 80=
35; or






4) &nb=
sp;    o nothing






 






My first reaction would be to go for optio=
n 2), as there IMO is no reason to formally update the text in RFC 8035. 






 






Regards,






 






Christer






 






 






_______________________________________________
mmusic mailing list
mmusi=
c@ietf.orghttps://www.ietf.org/mailman/listinfo/mmusic

 --_000_D532606F1C257christerholmbergericssoncom_-- From nobody Fri May 5 07:04:41 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2815812896F for ; Fri, 5 May 2017 07:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 EcFgRkQgbgb9 for ; Fri, 5 May 2017 07:04:33 -0700 (PDT) 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 578911270FC for ; Fri, 5 May 2017 07:04:31 -0700 (PDT) X-AuditID: c1b4fb30-663149a00000015f-b3-590c866d5381 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id E4.B5.00351.D668C095; Fri, 5 May 2017 16:04:29 +0200 (CEST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 5 May 2017 16:04:28 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mLFhzozuFkwSdoGcCxyAK9Z2MgJ0zn29eSQUJ5BWbHo=; b=kMuKsD1X/nKW7BCsG95FdIEBvWpDoEvK1kqxiKMmjr1TY7+r/pFdZQZW9aDq9X1l6CEAFJkO/JsFJBfN8ssYM+TTuAfsTuzaqgOURAkcfujqDTR/4YxgIrqMyjCM4jGQAQh9kMMyaD5Ojw2OFb/XIrbi2Lq+wWrHEIdT7e0/3JQ= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2578.eurprd07.prod.outlook.com (10.173.92.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 5 May 2017 14:04:27 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.1084.007; Fri, 5 May 2017 14:04:27 +0000 From: Bo Burman To: "mmusic (mmusic@ietf.org)" Thread-Topic: Consensus call for adoption of draft-hutton-mmusic-opportunistic-negotiation-00 Thread-Index: AdLFpZOd/EvsNyttRoO7HypCm1zI/g== Date: Fri, 5 May 2017 14:04:27 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2578; 7:G+oFYMHI8QLrIHWJArwtBOizjL+AUBoK8/t26N0ZWOA/xiLDN1s+Giy/GbAUXKAworGwoBsheonfSY0sOJmfnKvMasI7+gYRRv7OzIO5qyRiKiH6RUMe2CMlcyxym0OW6DdEBX8Jt7DA4x82vLTdnznTLfxNG1awZTkipFA2vX0TMCutdmSYg8zZAJ87W5iudQParbWeGY1x4+ewc4ooWQkssr2nDyPnuJHxuVgIkZKuftrO1FheyHOXg8E9vXfz2X/C3OAQzRuhdEoAoX8apKRjX0mnRiXYUGaI69EgZCMGy3P+Q5E2Lxfv/AAWTuSGn4CcV0t6xTzYzunQKMyxHw== x-ms-office365-filtering-correlation-id: bd4f927a-504a-4c48-cd18-08d493bfa4bf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2578; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:AM5PR0701MB2578; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2578; x-forefront-prvs: 02981BE340 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39400400002)(39450400003)(39860400002)(39850400002)(39410400002)(99286003)(55016002)(6306002)(9686003)(606005)(6436002)(5660300001)(54896002)(77096006)(236005)(6506006)(86362001)(230783001)(189998001)(19609705001)(53936002)(81166006)(8936002)(122556002)(110136004)(478600001)(38730400002)(8676002)(33656002)(2900100001)(50986999)(54356999)(3280700002)(3660700001)(2906002)(102836003)(3846002)(6116002)(790700001)(74316002)(7696004)(7736002)(25786009)(7906003)(6916009)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2578; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB25779856578CDBEA8A74290C8DEB0AM5PR0701MB2577_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2017 14:04:27.7181 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2578 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsUyM2K7jW5uG0+kwcqJhhZTlz9mcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrMdZ5kKNshUTNl9h72B8YNEFyMnh4SAicSPBR2MXYxcHEIC RxglljZ+YARJCAkcZ5Q4+FEFJMEi0MsscXDtOmaIqulMEr0XVjBBOEBVa/cuYgFpYRPQkJi/ 4y5Yu4iAgcTslTPAbGGBKIlPzVeYIeLxEk9/72aCsPUktjVdA6thEVCROLBlKVgNr0CCxMLJ d9lBbEYBWYn73++BzWcWEJe49WQ+E8TdAhJL9pxnhrBFJV4+/scKchCjQDejxId516CKFCTu /5oMVSQrcWl+N9ijEgJ9zBLLjk+DSvhKbLt7mhHCbmCUuHiGE8LOl5hy9iULhB0j8bdhCitE 8zcmiabur1DNMhI7V92GSkxnlXj0uZUJ4mcpibtXOqH+l5F4cWcvUBEH0A9AU7dxQ7wpKHFy 5hOWCYxqs5B8NwuhahaSKogSHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0Vo2hxanFSbrqR kV5qUWZycXF+nl5easkmRmCyObjlt8EOxpfPHQ8xCnAwKvHwKuRwRwqxJpYVV+YeYpTgYFYS 4U0t54kU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuu470KEkEB6YklqdmpqQWoRTJaJg1OqgXG+ q9KUQp/sybPkjqtyRfpeK/skKCgs8YK99LblykexvKa2lqpLV/G6HlguZW9x1eX9vfqgeyEv D9SsyDVadvT1rx3qK7lfeQf0Md9Y7nlHwXTq27JHK0WFN6dfYptf9LFyet3ipnvzG/a0uS9e U3PBkbt5/Z6keU/MU77+SFwqNNVEzITnpYoSS3FGoqEWc1FxIgDLLU0jMgMAAA== Archived-At: Subject: [MMUSIC] Consensus call for adoption of draft-hutton-mmusic-opportunistic-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 May 2017 14:04:35 -0000 --_000_AM5PR0701MB25779856578CDBEA8A74290C8DEB0AM5PR0701MB2577_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MMUSIC, Based on the feedback we received at the IETF 98 meeting in Chicago, it see= ms there is strong consensus for adopting this draft in MMUSIC. This = mail starts a one-week consensus call to confirm that consensus. Please ans= wer to state your support or if you have any objections. Unless someone objects, we will ask for a milestone and adopt it as an MMUS= IC WG draft. Please answer before midnight UTC on May 12, 2017. /Bo MMUSIC co-chair --_000_AM5PR0701MB25779856578CDBEA8A74290C8DEB0AM5PR0701MB2577_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MMUSIC,

 

Based on the feedback we received at the IETF 98 mee= ting in Chicago, it seems there is strong consensus for adopting this draft in MMUSIC. This mail starts a one-week consensus call to con= firm that consensus. Please answer to state your support or if you have any= objections.

 

Unless someone objects, we will ask for a milestone = and adopt it as an MMUSIC WG draft.

 

Please answer before midnight UTC on May 12, 2017.

 

/Bo

MMUSIC co-chair

 

--_000_AM5PR0701MB25779856578CDBEA8A74290C8DEB0AM5PR0701MB2577_-- From nobody Sun May 7 10:16:53 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51889128796; Sun, 7 May 2017 10:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 TEwpb0vMoub6; Sun, 7 May 2017 10:16:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B47C1275AB; Sun, 7 May 2017 10:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=78330; q=dns/txt; s=iport; t=1494177407; x=1495387007; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=j5j1HwNMejfn4Oii2a7VZ8/AC9N4RUCrBREe6YLeHzY=; b=HkKUluTre0NiTSg5H1SKgHKBvIeD1lFbNBrMgLlAcYHt/gL4MapBMqqw GrWu3uottfyqgAPIjdmQVCC8uHUjmbKFD4zbLCJ04dVaLXH/9ZPt3r65Y LcSsxF8E1eH3O2gqftEpD9auDhHDMJqfKrbAaywVStLtxQ3bMfD8llZMT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CUAQBdVQ9Z/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm48K2KBDAeDG0aKGJEyIXKVAIIPLoV2AhqELz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQEDDBdWEAIBBgIRBAEBIQEGAwICAjAUCQgCBA4FiiAOkWWdYYImi?= =?us-ascii?q?lwBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYg9KwuBWVg0hRmCVC6CMQWWZocTAYc?= =?us-ascii?q?bi3yCBIU8iiyUPQEfOIEKcBUcPAGEYRyBYgF2AQGGZAaBKoENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,305,1491264000"; d="scan'208,217";a="242291181" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 May 2017 17:16:45 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v47HGjFk014454 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 7 May 2017 17:16:45 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 7 May 2017 12:16:45 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Sun, 7 May 2017 12:16:45 -0500 From: "Arun Arunachalam (carunach)" To: Bo Burman CC: "mmusic (mmusic@ietf.org)" , "Flemming Andreasen (fandreas)" , "draft-ietf-mmusic-sdp-simulcast.authors@ietf.org" , "Arun Arunachalam (carunach)" Thread-Topic: Review: draft-ietf-mmusic-sdp-simulcast Thread-Index: AQHSqZR3U62wxX4n/EeUgd2ei06G2aGuOwmAgAABOwCADwZQgIAmDtaAgAZaogA= Date: Sun, 7 May 2017 17:16:45 +0000 Message-ID: References: <6351CDC7-7925-4448-A39E-56FCC9F2B12C@cisco.com> <991504f1-bb9c-17c7-432f-a53154d2da33@cisco.com> <344988B5-DEF9-41A4-BC15-7D8E07A22448@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.58.69] Content-Type: multipart/alternative; boundary="_000_DAE6CF8D63E746279F1CEAAD129E1342ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] Review: draft-ietf-mmusic-sdp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 May 2017 17:16:50 -0000 --_000_DAE6CF8D63E746279F1CEAAD129E1342ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEJvICENCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCk9uIE1heSAzLCAyMDE3LCBhdCAx MjoxNCBQTSwgQm8gQnVybWFuIDxiby5idXJtYW5AZXJpY3Nzb24uY29tPG1haWx0bzpiby5idXJt YW5AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCkhpIEFydW4sDQoNClRoYW5rIHlvdSBmb3IgdGhl IGNvbW1lbnRzISBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlcyBpbmxpbmUgYmVsb3cuDQoNCkNoZWVy cywNCi9Cbw0KDQpGcm9tOiBBcnVuIEFydW5hY2hhbGFtIChjYXJ1bmFjaCkgW21haWx0bzpjYXJ1 bmFjaEBjaXNjby5jb21dDQpTZW50OiBkZW4gOSBhcHJpbCAyMDE3IDEzOjA0DQpUbzogQm8gQnVy bWFuIDxiby5idXJtYW5AZXJpY3Nzb24uY29tPG1haWx0bzpiby5idXJtYW5AZXJpY3Nzb24uY29t Pj4NCkNjOiBGbGVtbWluZyBBbmRyZWFzZW4gKGZhbmRyZWFzKSA8ZmFuZHJlYXNAY2lzY28uY29t PG1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20+PjsgQXJ1biBBcnVuYWNoYWxhbSAoY2FydW5hY2gp IDxjYXJ1bmFjaEBjaXNjby5jb208bWFpbHRvOmNhcnVuYWNoQGNpc2NvLmNvbT4+DQpTdWJqZWN0 OiBSZTogUmV2aWV3OiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0DQoNCkhpIEJvLA0K DQpSZXZpZXdlZCB0aGUgZHJhZnQgYW5kIGhhdmUgYSBmZXcgY29tbWVudHMgYW5kIHF1ZXN0aW9u cyAoc2hvd24gYmVsb3cpLg0KDQpUaGFua3MhDQpBcnVuDQoNCkNvbW1lbnRzIC8gUXVlc3Rpb25z Og0KDQooMSkgU2VjdGlvbiAxPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3NlY3Rpb24tMT4NCg0KICAgdHJhbnNwb3J0IG92ZXIg UlRQLiAgVGhlIG1lZGlhIHRyYW5zcG9ydCB0b3BvbG9naWVzIGNvbnNpZGVyZWQgYXJlDQogICBw b2ludCB0byBwb2ludCBSVFAgc2Vzc2lvbnMgYXMgd2VsbCBhcyBjZW50cmFsaXplZCBtdWx0aS1w YXJ0eSBSVFANCiAgIHNlc3Npb25zLCB3aGVyZSBhIG1lZGlhIHNlbmRlciB3aWxsIHByb3ZpZGUg dGhlIHNpbXVsY2FzdGVkIHN0cmVhbXMNCiAgIHRvIGFuIFJUUCBtaWRkbGVib3ggb3IgZW5kcG9p bnQsIGFuZCBtaWRkbGVib3hlcyBtYXkgZnVydGhlcg0KICAgZGlzdHJpYnV0ZSB0aGUgc2ltdWxj YXN0IHN0cmVhbXMgdG8gb3RoZXIgbWlkZGxlYm94ZXMgb3IgZW5kcG9pbnRzLg0KDQpTZXZlcmFs IHBsYWNlcyBpbiB0aGUgZG9jIHVzZSB0aGUgdGVybSDigJxSVFAgU2Vzc2lvbuKAnSBhbmQg4oCc UlRQIHN0cmVhbXPigJ0gaGVuY2UgaXQgd291bGQgYmUgdXNlZnVsIHRvIHByb3ZpZGUgYSByZWZl cmVuY2Ugc28gdGhhdCByZWFkZXJzIGNhbiBrbm93IHRoZSBkaWZmZXJlbmNlLg0KDQpSVFAgU2Vz c2lvbiDigJQ+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNTUwI3NlY3Rpb24tMS4x DQpbQm9CXSBBcyBzYWlkIGF0IHRoZSBzdGFydCBvZiBzZWN0aW9uIDIuMSDigJxUZXJtaW5vbG9n eeKAnSwgdGhlIGRyYWZ0IGdlbmVyYWxseSB1c2VzIHRlcm1zIGZyb20gUlRQIFRheG9ub215IChS RkMgNzY1NikuIEJvdGggUlRQIHN0cmVhbSBhbmQgUlRQIHNlc3Npb24gYXJlIHRlcm1zIGRlc2Ny aWJlZCB0aGVyZS4gUlRQIHNlc3Npb24gaXMsIGFzIHlvdSBzYXksIGFsc28gZGVmaW5lZCBieSBS RlJDIDM1NTAsIGJ1dCB0aGVyZSBoYXMgYmVlbiBzaWduaWZpY2FudCBjb25mdXNpb24gYXJvdW5k IHdoYXQgdGhlIHRlcm0gcmVhbGx5IG1lYW5zLCBzbyBhZGRpdGlvbmFsIGNsYXJpZmljYXRpb24g d2FzIGFkZGVkIGluIFJGQyA3NjU2LiBJIGhhdmUgbm8gcHJvYmxlbSBhZGRpbmcgdGhlbSBhcyBl eHBsaWNpdCB0ZXJtcyBpbiBzZWN0aW9uIDIuMSwgYnV0IHdpbGwgdGhlbiBtb3JlIG9yIGxlc3Mg anVzdCByZWZlcmVuY2UgUkZDIDM1NTAgYW5kIFJGQyA3NjU2IGZyb20gdGhlcmUuDQoNCkdvb2Qu IFRoZSByZWZlcmVuY2UgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gc2hvdWxkIGJlIHN1ZmZp Y2llbnQuDQoNCg0KDQoNCigyKSBTZWN0aW9uIDMuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTMuMT4NCg0KDQog ICBCaXRyYXRlOiAgVGhpcyByZWxhdGVzIHRvIHRoZSBhbW91bnQgb2YgYml0cyBzcGVudCBwZXIg c2Vjb25kIHRvDQoNCiAgICAgIHRyYW5zbWl0IHRoZSBtZWRpYSBzb3VyY2UgYXMgYW4gUlRQIHN0 cmVhbSwgd2hpY2ggdHlwaWNhbGx5IGFsc28NCg0KICAgICAgYWZmZWN0cyB0aGUgUXVhbGl0eSBv ZiBFeHBlcmllbmNlIChRb0UpIGZvciB0aGUgcmVjZWl2aW5nIHVzZXIuDQoNCg0KSSB0aGluayB0 aGUgYXV0aG9ycyBtYXkgaGF2ZSBpbnRlbmRlZCB0byB1c2Ug4oCcc2VudOKAnSBpbnN0ZWFkIG9m IOKAnHNwZW50Ii4NCltCb0JdIEkgdGhpbmsgYSBzZW5kZXIgY2FuIOKAnHNwZW5k4oCdIGJpdHMg aXQg4oCcaGFzIGF2YWlsYWJsZeKAnSB0byBzZW5kLCBidXQgSSBhZ3JlZSB0aGF0IGl0IHdvdWxk IGJlIGJldHRlciB0byBjaGFuZ2UgdG8g4oCcc2VudOKAnS4NCg0KKDMpIFNlY3Rpb24gNi4xPGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0 LTA4I3NlY3Rpb24tNi4xPg0KDQogICBkaXJlY3Rpb25hbGl0eSBpcyByZXZlcnNlZC4gIFRoaXMg ZXhhbXBsZSBhbnN3ZXIgaGFzIHJlbW92ZWQgYWxsDQogICBvZmZlcmVkIGFsdGVybmF0aXZlIGZv cm1hdHMgZm9yIHRoZSBmaXJzdCBzaW11bGNhc3Qgc3RyZWFtIChrZWVwaW5nDQogICBvbmx5IFND SUQgMSksIGJ1dCBrZXB0IGFsdGVybmF0aXZlIGZvcm1hdHMgZm9yIHRoZSBzZWNvbmQgc2ltdWxj YXN0DQogICBzdHJlYW0gaW4gcmVjZWl2ZSBkaXJlY3Rpb24gKDQsIDUpLiAgVGhlIGFuc3dlciB0 aHVzIGFjY2VwdHMgdG8gc2VuZA0KICAgdHdvIHNpbXVsY2FzdCBzdHJlYW1zLCB3aXRob3V0IGFs dGVybmF0aXZlcy4gIFRoZSBhbnN3ZXIgZG9lcyBub3QNCiAgIGFjY2VwdCBpbml0aWFsIHBhdXNl IG9mIGFueSBzaW11bGNhc3Qgc3RyZWFtcywgaW4gZWl0aGVyIGRpcmVjdGlvbi4NCiAgIE1vcmUg ZXhhbXBsZXMgY2FuIGJlIGZvdW5kIGluIFNlY3Rpb24gNi42Lg0KDQpQbGVhc2UgcmVtb3ZlIHRo ZSB3b3JkIOKAnHRodXPigJ0gc2luY2UgdGhlcmUgaXMgbm8gcmVhc29uIHByb3ZpZGVkIHByaW9y IHRvIHRoaXMgc2VudGVuY2UuDQpbQm9CXSBPSy4NCg0KDQooNCkgU2VjdGlvbiA2LjI8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3QtMDgj c2VjdGlvbi02LjI+DQoNCiAgIGluc3RlYWQgb2YgbWFraW5nIGl0IGVxdWl2YWxlbnQgdG8gaW1w bGljaXRseSBzZW5kaW5nIGEgcGF1c2UNCiAgIHJlcXVlc3QsIGlzIGJlY2F1c2UgdGhlIHBhdXNp bmcgUlRQIHNlbmRlciBjYW5ub3Qga25vdyB3aGljaA0KICAgcmVjZWl2aW5nIFNTUkMgb3ducyB0 aGUgcmVzdHJpY3Rpb24gd2hlbiBUTU1CUi9UTU1CTiBhcmUgdXNlZCBmb3INCiAgIHBhdXNlL3Jl c3VtZSBzaWduYWxpbmcgc2luY2UgdGhlIFJUUCByZWNlaXZlcidzIFNTUkMgaW4gc2VuZA0KICAg ZGlyZWN0aW9uIGlzIHNvbWV0aW1lcyBub3QgeWV0IGtub3duLg0KDQpJdCB3b3VsZCBiZSBnb29k IHRvIGEgZ2l2ZSByZWZlcmVuY2UgZm9yIFRNTUJSL1RNTUJOIHBvaW50aW5nIHRvIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NzI4I3NlY3Rpb24tMi4xIG9yIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3NzI4I3NlY3Rpb24tNS42Lg0KW0JvQl0gT0suIFByZWZlciBzZWN0 aW9uIDUuNiBvZiBSRkMgNzcyOC4gSG93ZXZlciwgdGhlIGRyYWZ0IHNvdXJjZSBpcyBYTUwgYW5k IEkgZG9u4oCZdCB0aGluayB4bWwycmZjIDx4cmVmPiBzdXBwb3J0cyByZWZlcmVuY2luZyBhIHBh cnRpY3VsYXIgc2VjdGlvbiwgc28gSeKAmW0gbm90IHN1cmUgaG93IHRvIGFjaGlldmUgdGhhdC4N Cg0KDQpJIHRoaW5rIHdlIGNhbiB1c2UgIlNlY3Rpb24gNS42IG9mIDx4cmVmIHRhcmdldD0iUkZD NzcyOOKAnS8+4oCdIGluIHRoZSBYTUwgdmVyc2lvbiBvZiB0aGUgZG9jLg0KDQpSZWZlcmVuY2U6 IGh0dHBzOi8veG1sMnJmYy50b29scy5pZXRmLm9yZy94bWwycmZjRkFRLmh0bWwjYW5jaG9yMTgN Cg0KV29ya2luZyBleGFtcGxlOg0KDQpYTUw6DQoNCjxzZWN0aW9uIHRpdGxlPSJJbnRlcm1lZGlh cnkiPg0KPHQ+VGhlIHRlcm0gImludGVybWVkaWFyeSIgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDIg b2YgPHhyZWYgdGFyZ2V0PSJSRkM3OTg5Ii8+OyBpdCByZWZlcnMgdG8gYW55IGVudGl0eSBhbG9u ZyB0aGUgY2FsbCBzaWduYWxpbmcgcGF0aC48L3Q+DQo8L3NlY3Rpb24+DQoNClJGQzoNCmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTIzI3NlY3Rpb24tMy4zDQoNCg0KDQooNSkgU2Vj dGlvbiA2LjMuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMt c2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTYuMy4yPg0KDQogICBBbiBhbnN3ZXJlciB0aGF0IHJl Y2VpdmVzIGluZGljYXRpb24gaW4gYW4gb2ZmZXIgb2YgYW4gU0NJRCBiZWluZw0KICAgaW5pdGlh bGx5IHBhdXNlZCBTSE9VTEQgbWFyayB0aGF0IFNDSUQgYXMgaW5pdGlhbGx5IHBhdXNlZCBhbHNv IGluDQogICB0aGUgYW5zd2VyLCByZWdhcmRsZXNzIG9mIGRpcmVjdGlvbiwgdW5sZXNzIGl0IGhh cyBnb29kIHJlYXNvbiBmb3INCiAgIHRoZSBTQ0lEIG5vdCBiZWluZyBpbml0aWFsbHkgcGF1c2Vk LiAgT25lIHN1Y2ggcmVhc29uIGNvdWxkLCBmb3INCiAgIGV4YW1wbGUsIGJlIHRoYXQgdGhlIGFu c3dlcmVyIHdvdWxkIG90aGVyd2lzZSBpbml0aWFsbHkgbm90IHJlY2VpdmUNCiAgIGFueSBtZWRp YSBvZiB0aGF0IHR5cGUgYXQgYWxsLg0KDQpUcnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgZXhhbXBs ZS4gQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbiBhIHNjZW5hcmlvIGluIHdoaWNoIHRoZSBleGFtcGxl IGFwcGxpZXM/DQpbQm9CXSBTYXkgdGhhdCB5b3UgaGF2ZSBhIHNpbXVsY2FzdCB3aXRoIHNldmVy YWwgZGlmZmVyZW50IG1lZGlhIHF1YWxpdHkgbGV2ZWxzIGJlaW5nIG9mZmVyZWQuIFRoZSBvZmZl cmVyIGV4cGVjdHMgbW9zdCByZWNlaXZlcnMgdG8gYWNjZXB0IHRoZSBoaWdoZXN0IHF1YWxpdHkg bGV2ZWwsIGFuZCB0aGF0IHRoZXkgYXJlIHRoZW4gdW5pbnRlcmVzdGVkIHRvIHJlY2VpdmUgdGhl IGxvd2VyIHF1YWxpdHkgbGV2ZWxzLiBUaGUgb2ZmZXJlciBoYXMgdGhlcmVmb3JlIHNldCB0aGUg bG93ZXIgcXVhbGl0eSBzaW11bGNhc3Qgc3RyZWFtcyB0byBpbml0aWFsbHkgcGF1c2VkLiBGdXJ0 aGVyIGFzc3VtZSBhIHNvbWV3aGF0IHJlc3RyaWN0ZWQgYW5zd2VyZXIgdGhhdCBjYW5ub3QgY29w ZSB3aXRoIHRoZSBoaWdoZXN0IHF1YWxpdHkgbGV2ZWwuIEl0IHRoZXJlZm9yZSB3YW50cyB0byBh Y2NlcHQgYSBsb3dlciBxdWFsaXR5IGxldmVsIHNpbXVsY2FzdCBzdHJlYW0gYW5kIHdvdWxkIG5v dCByZWNlaXZlIGFueXRoaW5nIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIHNlc3Npb24gKHVudGls IGlzc3VpbmcgYW4gUkZDIDc3MjggUkVTVU1FKSBpZiBpdCBhY2NlcHRzIHRoaXMgbG93ZXIgcXVh bGl0eSBzaW11bGNhc3Qgc3RyZWFtIGFzIGluaXRpYWxseSBwYXVzZWQuIFdpdGhvdXQgaW5jbHVk aW5nIHN1Y2ggZmFpcmx5IGV4dGVuc2l2ZSBleGFtcGxlIHRleHQsIEkgZG9u4oCZdCBrbm93IGhv dyB0byBiZXN0IG1ha2UgYSBjbGFyaWZpY2F0aW9uLiBEbyB5b3UgaGF2ZSBhIHByb3Bvc2FsPw0K DQpHb3QgaXQuIE5pY2UgZXhhbXBsZS4NCg0KSG93IGFib3V0IGZvbGxvd2luZzoNCg0KICAgT25l IHN1Y2ggcmVhc29uIGNvdWxkLCBmb3IgZXhhbXBsZSwgYmUgdGhhdCB0aGUgYW5zd2VyZXIgZG9l c27igJl0IGhhdmUgdGhlIGFiaWxpdHkgdG8NCiAgIHByb2Nlc3MgYW55IHVucGF1c2VkIHNpbXVs Y2FzdCBzdHJlYW1zIG9mZmVyZWQgZm9yIGEgZ2l2ZW4gbWVkaWEgc291cmNlLiBJdCBjaG9vc2Vz DQogICBvbmUgb2YgdGhlIHBhdXNlZCBzaW11bGNhc3Qgc3RyZWFtIGluIHRoZSBvZmZlciBhbmQg bWFya3MgaXQgYXMgbm90IHBhdXNlZCBpbiB0aGUgYW5zd2VyLg0KDQoNCg0KDQoNCig2KSBTZWN0 aW9uIDcuMi4xPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1z ZHAtc2ltdWxjYXN0LTA4I3NlY3Rpb24tNy4yLjE+DQoNCiAgIFRoaXMgd2lsbCByZXN1bHQgaW4g YSBzaW5nbGUgUlRQIHN0cmVhbSBiZWluZyB1c2VkIGZvciBhIHBhcnRpY3VsYXINCiAgIG9mIHRo ZSBSVFAgbWl4ZXLigJlzIG1lZGlhIHNvdXJjZXMuDQoNCg0KVGhpcyBzZW50ZW5jZSBzZWVtcyB0 byBiZSBtaXNzaW5nIGEgd29yZCAtIOKAnOKApnRvciBhIHBhcnRpY3VsYXIgX19fX19fXyBvZiB0 aGUgUlRQIG1peGVy4oCZc+KApi7igJ0NCltCb0JdIFdoYXQgYWJvdXQgcmVwbGFjaW5nIOKAnGEg cGFydGljdWxhciBvZuKAnSB3aXRoIOKAnGVhY2ggb25lIG9m4oCdPw0KDQpXZSBjYW4gdXNlIOKA nGVhY2ggb2bigJ06DQoNCiAgIFRoaXMgd2lsbCByZXN1bHQgaW4gYSBzaW5nbGUgUlRQIHN0cmVh bSBiZWluZyB1c2VkIGZvciBlYWNoDQogICBvZiB0aGUgUlRQIG1peGVyJ3MgbWVkaWEgc291cmNl cy4NCg0KDQoNCg0KDQooNykgU2VjdGlvbiA3LjIuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTcuMi4xPg0KDQog ICAgVGhpcyBhcyB0aGVyZSBpcyBub3RoaW5nIGluIHRoZSBzaWduYWxsaW5nIGJldHdlZW4gdGhl IG1peGVyIGFuZCB0aGUgcmVjZWl2ZXIgdGhhdCBpcyBzdHJ1Y3R1cmVkIGFyb3VuZCB0aGUgb3Jp Z2luYXRpbmcgbWVkaWEgc291cmNlcywgb25seSB0aGUgbWl4ZXLigJlzIG1lZGlhIHNvdXJjZXMu DQoNCiBJIHRoaW5rIOKAnFRoaXMgYXPigJ0gbmVlZHMgdG8gYmUgY2hhbmdlZCB0byDigJxUaGF0 IGlz4oCdLg0KW0JvQl0gT0suIEkgYXNzdW1lIOKAnFRoYXQgaXMsIOKAnCAod2l0aCBhIGNvbW1h KT8NCg0KDQoNClllcy4NCg0KDQooOCkgU2VjdGlvbiA3LjIuMTxodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTcuMi4x Pg0KDQogICBJZiBSdHBTdHJlYW1JZHMgYXJlIHVzZWQgaW4gdGhpcyBzY2VuYXJpbywgaXQgc2hv dWxkIGJlIG5vdGVkIHRoYXQNCiAgIHRoZSBSdHBTdHJlYW1JZCBvbiBhIHBhcnRpY3VsYXIgU1NS QyB3aWxsIGNoYW5nZSBiYXNlZCBvbiB0aGUgYWN0dWFsDQogICBzaW11bGNhc3Qgc3RyZWFtIHNl bGVjdGVkIGZvciBzd2l0Y2hpbmcuICBUaGVzZSBSdHBTdHJlYW1JZA0KICAgaWRlbnRpZmllcnMg d2lsbCBiZSBsb2NhbCB0byB0aGlzIGxlZ+KAmXMgc2lnbmFsbGluZyBjb250ZXh0LiAgSW4NCiAg IGFkZGl0aW9uLCB0aGUgZGVmaW5lZCBSdHBTdHJlYW1JZHMgYW5kIHRoZWlyIHBhcmFtZXRlcnMg bmVlZCB0byBjb3Zlcg0KICAgYWxsIHRoZSBtZWRpYSBzb3VyY2VzIGFuZCBzaW11bGNhc3Qgc3Ry ZWFtcyB0aGF0IGNhbiBiZSBzd2l0Y2hlZCBpbnRvDQogICB0aGlzIG1lZGlhIHNvdXJjZS4NCg0K SW4gdGhlIGFib3ZlIHBhcmFncmFwaCB3aGF0IGRvZXMg4oCcdGhpcyBzY2VuYXJpb+KAnSByZWZl ciB0bz8gSXMgaXQgdGhlIHNjZW5hcmlvIG9mIHVzaW5nIG1lZGlhIHNvdXJjZeKAmXMgcnRwIHN0 cmVhbSBTU1JDIGluIHRoZSBDU1JDIG9mIHRoZSBydHAgbWl4ZXLigJlzIHJ0cCBzdHJlYW0gKG9y KSBpcyBpdCByZWZlcnJpbmcgdG8g4oCcUlRQIE1peGVyIC0gUmVjZWl2ZXLigJ0gc2NlbmFyaW9z IGluIGdlbmVyYWw/DQpbQm9CXSDigJxUaGlzIHNjZW5hcmlv4oCdIG1lYW5zIHRvIHJlZmVyIHRv IHRoaXMgc2VjdGlvbiAoNy4yLjEpLiBXaWxsIGNsYXJpZnkuDQoNCkRvZXMg4oCcdGhpcyBsZWfi gJlzIHNpZ25hbGluZyBjb250ZXh04oCdIHJlZmVyIHRvIHRoZSDigJxSVFAgbWl4ZXIgLSBSZWNl aXZlcuKAnSBjYWxsIGxlZz8NCltCb0JdIE5vdCBuZWNlc3NhcmlseSBqdXN0IFJUUCBzdHJlYW0g cmVjZWl2ZXIsIGl0IGNvdWxkIGFsc28gYmUgUlRQIHN0cmVhbSBzZW5kZXIsIG90aGVyd2lzZSB5 ZXMuIEl0IGlzIHRoZSBjb250ZXh0IG9mIGEgc2luZ2xlIFNEUCBvZmZlci9hbnN3ZXIgYmV0d2Vl biB0d28gcGFydGljaXBhbnRzIChSVFAgbWl4ZXIgYW5kIHdoYXRldmVyIGVuZHBvaW50IGlzIHRo ZSBjb3VudGVycGFydCDigJMgcG9zc2libHkgZXZlbiBhbm90aGVyIFJUUCBtaXhlcikuDQoNClRo ZSBzZW50ZW5jZSDigJxJbiBhZGRpdGlvbiwgdGhlIGRlZmluZWQgUnRwU3RyZWFtSWRz4oCmLnRo YXQgY2FuIGJlIHN3aXRjaGVkIGludG8gdGhpcyBtZWRpYSBzb3VyY2UiIGlzIG5vdCBjbGVhciB0 byBtZS4gU3BlY2lmaWNhbGx5IHdoeSB3b3VsZCB3ZSBzd2l0Y2hpbmcgYW4gUlRQIHN0cmVhbSBp bnRvIGEgbWVkaWEgc291cmNlLiBXYXMgaXQgaW50ZW5kZWQgdG8gYmUg4oCcc3dpdGNoZWQgZnJv bSB0aGlzIG1lZGlhIHNvdXJjZeKAnSBvciDigJxzd2l0Y2hlZCB0byBhIFJUUCByZWNlaXZlcuKA nT8gUGxlYXNlIGV4cGxhaW4uDQpbQm9CXSBUaGUgUlRQIG1peGVyIHJlY2VpdmVzIChwb3RlbnRp YWxseSBzaW11bGNhc3QpIFJUUCBzdHJlYW1zIGZyb20gb3JpZ2luYXRpbmcgbWVkaWEgc291cmNl cyBhbmQgc3dpdGNoZXMgdGhvc2UgUlRQIHBhY2tldHMgaW50ZXJuYWxseSB0byBwcm92aWRlIGRh dGEgZm9yIHRoZSBSVFAgbWl4ZXLigJlzIG93biBtZWRpYSBzb3VyY2VzIGFuZCBSVFAgc3RyZWFt cywgYXMgc2VlbiBieSB0aGUgZmluYWwgcmVjZWl2ZXIgb2YgdGhlIFJUUCBzdHJlYW1zIGZyb20g dGhlIFJUUCBtaXhlci4gV2hhdCBhYm91dCByZS1mb3JtdWxhdGluZyB0byDigJxJbiBhZGRpdGlv biwgdGhlIGRlZmluZWQgUnRwU3RyZWFtSWRzIGFuZCB0aGVpciBwYXJhbWV0ZXJzIG5lZWQgdG8g Y292ZXIgYWxsIHRoZSBtZWRpYSBzb3VyY2VzIGFuZCBzaW11bGNhc3Qgc3RyZWFtc3JlY2VpdmVk IGJ5IHRoZSBSVFAgbWl4ZXIgdGhhdCBjYW4gYmUgc3dpdGNoZWQgaW50byB0aGlzIG1lZGlhIHNv dXJjZSwgc2VudCBieSB0aGUgUlRQIG1peGVy4oCdPw0KDQpZZXMhIHRoaXMgZ2l2ZXMgbW9yZSBj bGFyaXR5Lg0KDQpUaGFua3MhDQpBcnVuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9uIE1h ciAzMCwgMjAxNywgYXQgNTo0MiBQTSwgQXJ1biBBcnVuYWNoYWxhbSAoY2FydW5hY2gpIDxjYXJ1 bmFjaEBjaXNjby5jb208bWFpbHRvOmNhcnVuYWNoQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSBG bGVtbWluZywNCg0KSSB0aGluayBpbiBhYm91dCBhIHdlZWsgaS5lIGJ5IEVPQiA0LzcuDQoNClRo YW5rcyENCkFydW4NClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gTWFyIDMwLCAyMDE3LCBhdCA0 OjMzIFBNLCBGbGVtbWluZyBBbmRyZWFzZW4gKGZhbmRyZWFzKSA8ZmFuZHJlYXNAY2lzY28uY29t PG1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20+PiB3cm90ZToNClRoYW5rcyBBcnVuIC0gd2hlbiBk byB5b3UgdGhpbmsgeW91IHdpbGwgaGF2ZSB0aGUgcmV2aWV3IHJlYWR5ID8NCg0KLS0gRmxlbW1p bmcNCk9uIDMvMzAvMTcgNDozMCBQTSwgQXJ1biBBcnVuYWNoYWxhbSAoY2FydW5hY2gpIHdyb3Rl Og0KSGkgRmxlbW1pbmcsDQoNCkFzIGRpc2N1c3NlZCwgaSB3b3VsZCBiZSBnbGFkIHRvIHJldmll dyBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdD4gZHJhZnQuDQoN ClRoYW5rcyENCkFydW4NCg0KDQouDQoNCg== --_000_DAE6CF8D63E746279F1CEAAD129E1342ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8F03306BB80A68469883C3474831C0FB@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhhbmtzIEJvICENCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlBsZWFzZSBzZWUgaW5s aW5lLjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXkgMywg MjAxNywgYXQgMTI6MTQgUE0sIEJvIEJ1cm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJvLmJ1cm1h bkBlcmljc3Nvbi5jb20iIGNsYXNzPSIiPmJvLmJ1cm1hbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3 cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNl Y3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3Rh cnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTog bm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkhpIEFydW4sPG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPlRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzISBQbGVhc2Ugc2VlIG15 IHJlc3BvbnNlcyBpbmxpbmUgYmVsb3cuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNz PSIiPkNoZWVycyw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPi9C bzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0i Ij4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5v bmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogYmx1ZTsgYm9yZGVyLWxlZnQt d2lkdGg6IDEuNXB0OyBwYWRkaW5nOiAwY20gMGNtIDBjbSA0cHQ7IiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9y ZGVyLXRvcC1jb2xvcjogcmdiKDIyNSwgMjI1LCAyMjUpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7 IHBhZGRpbmc6IDNwdCAwY20gMGNtOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QXJ1biBBcnVuYWNoYWxhbSAoY2FydW5hY2gpIFs8YSBo cmVmPSJtYWlsdG86Y2FydW5hY2hAY2lzY28uY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tYWlsdG86Y2FydW5hY2hAY2lzY28u Y29tPC9hPl08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmRlbiA5IGFwcmlsIDIwMTcgMTM6MDQ8YnIgY2xh c3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPkJvIEJ1cm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJvLmJ1cm1h bkBlcmljc3Nvbi5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsiIGNsYXNzPSIiPmJvLmJ1cm1hbkBlcmljc3Nvbi5jb208L2E+Jmd0OzxiciBjbGFz cz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+RmxlbW1pbmcgQW5kcmVhc2VuIChmYW5kcmVhcykgJmx0OzxhIGhy ZWY9Im1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmZhbmRyZWFzQGNpc2NvLmNvbTwvYT4m Z3Q7OyBBcnVuIEFydW5hY2hhbGFtIChjYXJ1bmFjaCkgJmx0OzxhIGhyZWY9Im1haWx0bzpjYXJ1 bmFjaEBjaXNjby5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsiIGNsYXNzPSIiPmNhcnVuYWNoQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIi Pg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBSZXZpZXc6IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11 bGNhc3Q8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQpIaSBCbyw8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBj bGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpSZXZpZXdlZCB0aGUg ZHJhZnQgYW5kIGhhdmUgYSBmZXcgY29tbWVudHMgYW5kIHF1ZXN0aW9ucyAoc2hvd24gYmVsb3cp LiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBj bGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpUaGFua3MhPG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpBcnVuPG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iY29sb3I6IHJnYigyNTUsIDEwNiwgMCk7IiBjbGFzcz0iIj5Db21tZW50cyAvIFF1ZXN0 aW9uczwvc3Bhbj48L2I+OjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KKDEpJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3QtMDgjc2VjdGlvbi0xIiBzdHlsZT0iY29s b3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5TZWN0aW9u IDE8L2E+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQombmJzcDsgJm5ic3A7dHJhbnNwb3J0IG92ZXIgUlRQLiAmbmJzcDtUaGUgbWVkaWEgdHJhbnNw b3J0IHRvcG9sb2dpZXMgY29uc2lkZXJlZCBhcmU8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtwb2ludCB0byBwb2ludDxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0iIj5SVFAgc2Vzc2lv bnM8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmFz IHdlbGwgYXMgY2VudHJhbGl6ZWQgbXVsdGktcGFydHkgUlRQPG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7c2Vzc2lvbnMsIHdoZXJlIGEgbWVk aWEgc2VuZGVyIHdpbGwgcHJvdmlkZSB0aGUgc2ltdWxjYXN0ZWQgc3RyZWFtczxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3RvIGFuIFJUUCBt aWRkbGVib3ggb3IgZW5kcG9pbnQsIGFuZCBtaWRkbGVib3hlcyBtYXkgZnVydGhlcjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2Rpc3RyaWJ1 dGUgdGhlIHNpbXVsY2FzdCBzdHJlYW1zIHRvIG90aGVyIG1pZGRsZWJveGVzIG9yIGVuZHBvaW50 cy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpTZXZlcmFsIHBs YWNlcyBpbiB0aGUgZG9jIHVzZSB0aGUgdGVybSDigJxSVFAgU2Vzc2lvbuKAnSBhbmQg4oCcUlRQ IHN0cmVhbXPigJ0gaGVuY2UgaXQgd291bGQgYmUgdXNlZnVsIHRvIHByb3ZpZGUgYSByZWZlcmVu Y2Ugc28gdGhhdCByZWFkZXJzIGNhbiBrbm93IHRoZSBkaWZmZXJlbmNlLjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQpSVFAgU2Vzc2lvbiDigJQmZ3Q7Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTAjc2VjdGlvbi0xLjEiIHN0eWxlPSJj b2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNTUwI3NlY3Rpb24tMS4xPC9hPjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5bQm9CXSBB cyBzYWlkIGF0IHRoZSBzdGFydCBvZiBzZWN0aW9uIDIuMSDigJxUZXJtaW5vbG9neeKAnSwgdGhl IGRyYWZ0IGdlbmVyYWxseSB1c2VzIHRlcm1zIGZyb20gUlRQIFRheG9ub215IChSRkMgNzY1Niku IEJvdGggUlRQIHN0cmVhbSBhbmQgUlRQIHNlc3Npb24gYXJlIHRlcm1zDQogZGVzY3JpYmVkIHRo ZXJlLiBSVFAgc2Vzc2lvbiBpcywgYXMgeW91IHNheSwgYWxzbyBkZWZpbmVkIGJ5IFJGUkMgMzU1 MCwgYnV0IHRoZXJlIGhhcyBiZWVuIHNpZ25pZmljYW50IGNvbmZ1c2lvbiBhcm91bmQgd2hhdCB0 aGUgdGVybSByZWFsbHkgbWVhbnMsIHNvIGFkZGl0aW9uYWwgY2xhcmlmaWNhdGlvbiB3YXMgYWRk ZWQgaW4gUkZDIDc2NTYuIEkgaGF2ZSBubyBwcm9ibGVtIGFkZGluZyB0aGVtIGFzIGV4cGxpY2l0 IHRlcm1zIGluIHNlY3Rpb24NCiAyLjEsIGJ1dCB3aWxsIHRoZW4gbW9yZSBvciBsZXNzIGp1c3Qg cmVmZXJlbmNlIFJGQyAzNTUwIGFuZCBSRkMgNzY1NiBmcm9tIHRoZXJlLjwvc3Bhbj48L2k+PC9i PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+R29vZC4gVGhl IHJlZmVyZW5jZSBpbiB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBzaG91bGQgYmUgc3VmZmljaWVu dC48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRp diBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQt Y29sb3I6IGJsdWU7IGJvcmRlci1sZWZ0LXdpZHRoOiAxLjVwdDsgcGFkZGluZzogMGNtIDBjbSAw Y20gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQooMikmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTMuMSIgc3R5bGU9ImNvbG9y OiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+U2VjdGlvbiAz LjE8L2E+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgQml0cmF0ZTombmJz cDsgVGhpcyByZWxhdGVzIHRvIHRoZSBhbW91bnQgb2YgYml0cyA8YiBjbGFzcz0iIj5zcGVudCBw ZXIgc2Vjb25kPC9iPiB0bzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFt aWx5OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdHJhbnNtaXQgdGhlIG1lZGlhIHNvdXJjZSBhcyBhbiBSVFAgc3RyZWFtLCB3aGljaCB0 eXBpY2FsbHkgYWxzbzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiAnQ291cmllciBOZXcnOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgYWZmZWN0cyB0aGUgUXVhbGl0eSBvZiBFeHBlcmllbmNlIChRb0UpIGZvciB0aGUgcmVjZWl2 aW5nIHVzZXIuPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wcmU+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAg Y2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpJIHRo aW5rIHRoZSBhdXRob3JzIG1heSBoYXZlIGludGVuZGVkIHRvIHVzZSDigJw8YiBjbGFzcz0iIj5z ZW50PC9iPuKAnSBpbnN0ZWFkIG9mIOKAnHNwZW50JnF1b3Q7LjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K PGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5bQm9CXSBJIHRoaW5rIGEg c2VuZGVyIGNhbiDigJxzcGVuZOKAnSBiaXRzIGl0IOKAnGhhcyBhdmFpbGFibGXigJ0gdG8gc2Vu ZCwgYnV0IEkgYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gY2hhbmdlIHRvIOKAnHNl bnTigJ0uPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpw Pjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCigzKSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3NlY3Rpb24t Ni4xIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBj bGFzcz0iIj5TZWN0aW9uIDYuMTwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtkaXJlY3Rpb25hbGl0eSBpcyByZXZlcnNl ZC4gJm5ic3A7VGhpcyBleGFtcGxlIGFuc3dlciBoYXMgcmVtb3ZlZCBhbGw8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtvZmZlcmVkIGFsdGVy bmF0aXZlIGZvcm1hdHMgZm9yIHRoZSBmaXJzdCBzaW11bGNhc3Qgc3RyZWFtIChrZWVwaW5nPG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7b25s eSBTQ0lEIDEpLCBidXQga2VwdCBhbHRlcm5hdGl2ZSBmb3JtYXRzIGZvciB0aGUgc2Vjb25kIHNp bXVsY2FzdDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwO3N0cmVhbSBpbiByZWNlaXZlIGRpcmVjdGlvbiAoNCwgNSkuICZuYnNwO1RoZSBhbnN3 ZXI8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xh c3M9IiI+PHMgY2xhc3M9IiI+dGh1czwvcz48L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmFjY2VwdHMgdG8gc2VuZDxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3R3byBzaW11bGNhc3Qgc3RyZWFt cywgd2l0aG91dCBhbHRlcm5hdGl2ZXMuICZuYnNwO1RoZSBhbnN3ZXIgZG9lcyBub3Q8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDthY2NlcHQg aW5pdGlhbCBwYXVzZSBvZiBhbnkgc2ltdWxjYXN0IHN0cmVhbXMsIGluIGVpdGhlciBkaXJlY3Rp b24uPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7TW9yZSBleGFtcGxlcyBjYW4gYmUgZm91bmQgaW4gU2VjdGlvbiA2LjYuPG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KUGxlYXNlIHJlbW92ZSB0aGUgd29yZCDi gJx0aHVz4oCdIHNpbmNlIHRoZXJlIGlzIG5vIHJlYXNvbiBwcm92aWRlZCBwcmlvciB0byB0aGlz IHNlbnRlbmNlLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj5bQm9CXSBPSy48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQooNCkmbmJzcDs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0w OCNzZWN0aW9uLTYuMiIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5k ZXJsaW5lOyIgY2xhc3M9IiI+U2VjdGlvbiA2LjI8L2E+PG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7aW5zdGVhZCBvZiBtYWtp bmcgaXQgZXF1aXZhbGVudCB0byBpbXBsaWNpdGx5IHNlbmRpbmcgYSBwYXVzZTxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3JlcXVlc3QsIGlz IGJlY2F1c2UgdGhlIHBhdXNpbmcgUlRQIHNlbmRlciBjYW5ub3Qga25vdyB3aGljaDxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3JlY2Vpdmlu ZyBTU1JDIG93bnMgdGhlIHJlc3RyaWN0aW9uIHdoZW48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+VE1NQlIvVE1NQk48L2I+PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmFyZSB1c2VkIGZvcjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3Bh dXNlL3Jlc3VtZSBzaWduYWxpbmcgc2luY2UgdGhlIFJUUCByZWNlaXZlcidzIFNTUkMgaW4gc2Vu ZDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNw O2RpcmVjdGlvbiBpcyBzb21ldGltZXMgbm90IHlldCBrbm93bi48bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpJdCB3b3VsZCBiZSBnb29kIHRvIGEgZ2l2ZSByZWZl cmVuY2UgZm9yIFRNTUJSL1RNTUJOIHBvaW50aW5nIHRvJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzc3Mjgjc2VjdGlvbi0yLjEiIHN0eWxlPSJjb2xvcjogcHVy cGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM3NzI4I3NlY3Rpb24tMi4xPC9hPiZuYnNwO29yJm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc3Mjgjc2VjdGlvbi01LjYiIHN0eWxl PSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NzI4I3NlY3Rpb24tNS42PC9hPi48bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+W0Jv Ql0gT0suIFByZWZlciBzZWN0aW9uIDUuNiBvZiBSRkMgNzcyOC4gSG93ZXZlciwgdGhlIGRyYWZ0 IHNvdXJjZSBpcyBYTUwgYW5kIEkgZG9u4oCZdCB0aGluayB4bWwycmZjICZsdDt4cmVmJmd0OyBz dXBwb3J0cyByZWZlcmVuY2luZyBhIHBhcnRpY3VsYXIgc2VjdGlvbiwgc28gSeKAmW0gbm90DQog c3VyZSBob3cgdG8gYWNoaWV2ZSB0aGF0Ljwvc3Bhbj48L2k+PC9iPjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIHRoaW5r IHdlIGNhbiB1c2UgJnF1b3Q7U2VjdGlvbiA1LjYgb2YgJmx0O3hyZWYgdGFyZ2V0PSZxdW90O1JG Qzc3MjjigJ0vJmd0O+KAnSBpbiB0aGUgWE1MIHZlcnNpb24gb2YgdGhlIGRvYy48L2Rpdj4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlJlZmVyZW5jZTombmJzcDs8YSBocmVmPSJo dHRwczovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcveG1sMnJmY0ZBUS5odG1sI2FuY2hvcjE4IiBj bGFzcz0iIj5odHRwczovL3htbDJyZmMudG9vbHMuaWV0Zi5vcmcveG1sMnJmY0ZBUS5odG1sI2Fu Y2hvcjE4PC9hPjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+V29ya2lu ZyBleGFtcGxlOjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+WE1MOjwv ZGl2Pg0KPGRpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxzcGFuIGNsYXNz PSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPiZsdDtzZWN0 aW9uIHRpdGxlPSZxdW90O0ludGVybWVkaWFyeSZxdW90OyZndDs8L2Rpdj4NCjxkaXY+PHNwYW4g Y2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+Jmx0 O3QmZ3Q7VGhlIHRlcm0gJnF1b3Q7aW50ZXJtZWRpYXJ5JnF1b3Q7IGlzIGRlZmluZWQgaW4gU2Vj dGlvbiAyIG9mICZsdDt4cmVmIHRhcmdldD0mcXVvdDtSRkM3OTg5JnF1b3Q7LyZndDs7IGl0IHJl ZmVycyB0byBhbnkgZW50aXR5IGFsb25nIHRoZSBjYWxsIHNpZ25hbGluZyBwYXRoLiZsdDsvdCZn dDs8L2Rpdj4NCjxkaXY+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUt c3BhY2U6cHJlIj48L3NwYW4+Jmx0Oy9zZWN0aW9uJmd0OzwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5SRkM6PC9kaXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTIzI3NlY3Rpb24tMy4zIiBjbGFzcz0iIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODEyMyNzZWN0aW9uLTMuMzwvYT48L2Rpdj4NCjxi ciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9u MTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNv bGlkOyBib3JkZXItbGVmdC1jb2xvcjogYmx1ZTsgYm9yZGVyLWxlZnQtd2lkdGg6IDEuNXB0OyBw YWRkaW5nOiAwY20gMGNtIDBjbSA0cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyBtaW4taGVpZ2h0OiAx NHB4OyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQooNSkmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTYuMy4yIiBzdHlsZT0iY29sb3I6IHB1 cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5TZWN0aW9uIDYuMy4y PC9hPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsgQW4g YW5zd2VyZXIgdGhhdCByZWNlaXZlcyBpbmRpY2F0aW9uIGluIGFuIG9mZmVyIG9mIGFuIFNDSUQg YmVpbmc8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyBpbml0aWFsbHkgcGF1c2VkIFNIT1VMRCBtYXJrIHRoYXQgU0NJRCBhcyBpbml0aWFsbHkg cGF1c2VkIGFsc28gaW48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CiZuYnNwOyZuYnNwOyB0aGUgYW5zd2VyLCByZWdhcmRsZXNzIG9mIGRpcmVjdGlvbiwgdW5sZXNz IGl0IGhhcyBnb29kIHJlYXNvbiBmb3I8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwOyB0aGUgU0NJRCBub3QgYmVpbmcgaW5pdGlhbGx5IHBhdXNl ZC4mbmJzcDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGIgY2xhc3M9IiI+T25lIHN1Y2ggcmVhc29uIGNvdWxkLCBmb3I8L2I+PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgZXhh bXBsZSwgYmUgdGhhdCB0aGUgYW5zd2VyZXIgd291bGQgb3RoZXJ3aXNlIGluaXRpYWxseSBub3Qg cmVjZWl2ZTwvYj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBhbnkgbWVkaWEgb2YgdGhhdCB0eXBlIGF0IGFsbC48L2I+ PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIi PiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpUcnlp bmcgdG8gdW5kZXJzdGFuZCB0aGUgZXhhbXBsZS4gQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbiBhIHNj ZW5hcmlvIGluIHdoaWNoIHRoZSBleGFtcGxlIGFwcGxpZXM/PG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPltCb0JdIFNheSB0aGF0IHlv dSBoYXZlIGEgc2ltdWxjYXN0IHdpdGggc2V2ZXJhbCBkaWZmZXJlbnQgbWVkaWEgcXVhbGl0eSBs ZXZlbHMgYmVpbmcgb2ZmZXJlZC4gVGhlIG9mZmVyZXIgZXhwZWN0cyBtb3N0IHJlY2VpdmVycyB0 byBhY2NlcHQgdGhlIGhpZ2hlc3QgcXVhbGl0eQ0KIGxldmVsLCBhbmQgdGhhdCB0aGV5IGFyZSB0 aGVuIHVuaW50ZXJlc3RlZCB0byByZWNlaXZlIHRoZSBsb3dlciBxdWFsaXR5IGxldmVscy4gVGhl IG9mZmVyZXIgaGFzIHRoZXJlZm9yZSBzZXQgdGhlIGxvd2VyIHF1YWxpdHkgc2ltdWxjYXN0IHN0 cmVhbXMgdG8gaW5pdGlhbGx5IHBhdXNlZC4gRnVydGhlciBhc3N1bWUgYSBzb21ld2hhdCByZXN0 cmljdGVkIGFuc3dlcmVyIHRoYXQgY2Fubm90IGNvcGUgd2l0aCB0aGUgaGlnaGVzdCBxdWFsaXR5 IGxldmVsLg0KIEl0IHRoZXJlZm9yZSB3YW50cyB0byBhY2NlcHQgYSBsb3dlciBxdWFsaXR5IGxl dmVsIHNpbXVsY2FzdCBzdHJlYW0gYW5kIHdvdWxkIG5vdCByZWNlaXZlIGFueXRoaW5nIGF0IHRo ZSBiZWdpbm5pbmcgb2YgdGhlIHNlc3Npb24gKHVudGlsIGlzc3VpbmcgYW4gUkZDIDc3MjggUkVT VU1FKSBpZiBpdCBhY2NlcHRzIHRoaXMgbG93ZXIgcXVhbGl0eSBzaW11bGNhc3Qgc3RyZWFtIGFz IGluaXRpYWxseSBwYXVzZWQuIFdpdGhvdXQgaW5jbHVkaW5nIHN1Y2gNCiBmYWlybHkgZXh0ZW5z aXZlIGV4YW1wbGUgdGV4dCwgSSBkb27igJl0IGtub3cgaG93IHRvIGJlc3QgbWFrZSBhIGNsYXJp ZmljYXRpb24uIERvIHlvdSBoYXZlIGEgcHJvcG9zYWw/PC9zcGFuPjwvaT48L2I+PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Hb3QgaXQuIE5pY2UgZXhhbXBs ZS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkhvdyBhYm91dCBmb2xs b3dpbmc6PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PiZuYnNwOyAmbmJzcDtPbmUgc3VjaCByZWFzb24gY291bGQsIGZvciBleGFtcGxlLCBiZSB0 aGF0IHRoZSBhbnN3ZXJlciBkb2VzbuKAmXQgaGF2ZSB0aGUgYWJpbGl0eSB0bzwvZGl2Pg0KPGRp dj4mbmJzcDsgJm5ic3A7cHJvY2VzcyBhbnkgdW5wYXVzZWQgc2ltdWxjYXN0IHN0cmVhbXMgb2Zm ZXJlZCBmb3IgYSBnaXZlbiBtZWRpYSBzb3VyY2UuIEl0IGNob29zZXM8L2Rpdj4NCjxkaXY+Jm5i c3A7ICZuYnNwO29uZSBvZiB0aGUgcGF1c2VkIHNpbXVsY2FzdCBzdHJlYW0gaW4gdGhlIG9mZmVy IGFuZCBtYXJrcyBpdCBhcyBub3QgcGF1c2VkIGluIHRoZSBhbnN3ZXIuPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBX b3JkU2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5v bmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IGJsdWU7IGJvcmRlci1sZWZ0LXdpZHRo OiAxLjVwdDsgcGFkZGluZzogMGNtIDBjbSAwY20gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNz PSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZu YnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQooNikmbmJzcDs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0w OCNzZWN0aW9uLTcuMi4xIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IiBjbGFzcz0iIj5TZWN0aW9uIDcuMi4xPC9hPjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyB3 aWxsIHJlc3VsdCBpbiBhIHNpbmdsZSBSVFAgc3RyZWFtIGJlaW5nIHVzZWQgZm9yIGE8c3BhbiBj bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+cGFy dGljdWxhcjwvYj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPiZuYnNwOyZuYnNwOyZuYnNwO29mPC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj50aGUgUlRQIG1peGVy4oCZcyBtZWRpYSBzb3VyY2Vz LiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAg Y2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KVGhpcyBzZW50ZW5j ZSBzZWVtcyB0byBiZSBtaXNzaW5nIGEgd29yZCAtIOKAnOKApnRvciBhIHBhcnRpY3VsYXIgX19f X19fXyBvZiB0aGUgUlRQIG1peGVy4oCZc+KApi7igJ08bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNs YXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+W0JvQl0gV2hhdCBhYm91dCByZXBs YWNpbmcg4oCcYSBwYXJ0aWN1bGFyIG9m4oCdIHdpdGgg4oCcZWFjaCBvbmUgb2bigJ0/PC9zcGFu PjwvaT48L2I+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCldlIGNhbiB1c2Ug4oCc ZWFjaCBvZuKAnTo8YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+Jm5ic3A7ICZuYnNwO1RoaXMgd2lsbCByZXN1bHQgaW4gYSBzaW5nbGUgUlRQIHN0 cmVhbSBiZWluZyB1c2VkIGZvciBlYWNoJm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtv ZiB0aGUgUlRQIG1peGVyJ3MgbWVkaWEgc291cmNlcy4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7 ICZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBm b250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1h bDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7Ij4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7 IGJvcmRlci1sZWZ0LWNvbG9yOiBibHVlOyBib3JkZXItbGVmdC13aWR0aDogMS41cHQ7IHBhZGRp bmc6IDBjbSAwY20gMGNtIDRwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KKDcp Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11 c2ljLXNkcC1zaW11bGNhc3QtMDgjc2VjdGlvbi03LjIuMSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+U2VjdGlvbiA3LjIuMTwvYT48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+ Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNw OyAmbmJzcDsmbmJzcDs8YiBjbGFzcz0iIj5UaGlzIGFzPC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj50aGVyZSBpcyBub3RoaW5nIGluIHRoZSBzaWdu YWxsaW5nIGJldHdlZW4gdGhlIG1peGVyIGFuZCB0aGUgcmVjZWl2ZXIgdGhhdCBpcyBzdHJ1Y3R1 cmVkIGFyb3VuZCB0aGUgb3JpZ2luYXRpbmcgbWVkaWEgc291cmNlcywgb25seSB0aGUgbWl4ZXLi gJlzIG1lZGlhIHNvdXJjZXMuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZu YnNwO0kgdGhpbmsg4oCcVGhpcyBhc+KAnSBuZWVkcyB0byBiZSBjaGFuZ2VkIHRvIOKAnFRoYXQg aXPigJ0uPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPltCb0JdIE9LLiBJIGFzc3VtZSDigJxUaGF0IGlzLCDigJwgKHdpdGggYSBjb21t YSk/PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv c3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5ZZXMuPC9kaXY+DQo8ZGl2PjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0i cGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTog bm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiBibHVlOyBib3JkZXItbGVm dC13aWR0aDogMS41cHQ7IHBhZGRpbmc6IDBjbSAwY20gMGNtIDRwdDsiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KKDgpJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3QtMDgjc2VjdGlvbi03LjIu MSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+U2VjdGlvbiA3LjIuMTwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgbWluLWhlaWdodDogMTRweDsi IGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO0lmIFJ0cFN0cmVhbUlkcyBhcmUgdXNlZCBp bjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFz cz0iIj50aGlzIHNjZW5hcmlvPC9iPiwgaXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQ8bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO3RoZSBS dHBTdHJlYW1JZCBvbiBhIHBhcnRpY3VsYXIgU1NSQyB3aWxsIGNoYW5nZSBiYXNlZCBvbiB0aGUg YWN0dWFsPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsmbmJzcDtzaW11bGNhc3Qgc3RyZWFtIHNlbGVjdGVkIGZvciBzd2l0Y2hpbmcuJm5ic3A7 Jm5ic3A7VGhlc2UgUnRwU3RyZWFtSWQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO2lkZW50aWZpZXJzIHdpbGwgYmUgbG9jYWwgdG88 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9 IiI+dGhpcyBsZWfigJlzIHNpZ25hbGxpbmcgY29udGV4dDwvYj4uJm5ic3A7Jm5ic3A7SW48bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw O2FkZGl0aW9uLCB0aGUgZGVmaW5lZCBSdHBTdHJlYW1JZHMgYW5kIHRoZWlyIHBhcmFtZXRlcnMg bmVlZCB0byBjb3ZlcjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7YWxsIHRoZSBtZWRpYSBzb3VyY2VzIGFuZCBzaW11bGNhc3Qgc3Ry ZWFtcyB0aGF0IGNhbiBiZSBzd2l0Y2hlZDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0iIj5pbnRvPC9iPjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhp cyBtZWRpYSBzb3VyY2UuPC9iPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCkluIHRoZSBhYm92ZSBwYXJhZ3JhcGggd2hhdCBkb2VzIOKAnHRoaXMgc2NlbmFyaW/i gJ0gcmVmZXIgdG8/IElzIGl0IHRoZSBzY2VuYXJpbyBvZiB1c2luZyBtZWRpYSZuYnNwO3NvdXJj ZeKAmXMgcnRwIHN0cmVhbSBTU1JDIGluIHRoZSBDU1JDIG9mIHRoZSBydHAgbWl4ZXLigJlzIHJ0 cCBzdHJlYW0gKG9yKSBpcyBpdCByZWZlcnJpbmcgdG8g4oCcUlRQIE1peGVyIC0gUmVjZWl2ZXLi gJ0gc2NlbmFyaW9zIGluIGdlbmVyYWw/PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48 aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPltCb0JdIOKAnFRoaXMgc2NlbmFyaW/igJ0gbWVh bnMgdG8gcmVmZXIgdG8gdGhpcyBzZWN0aW9uICg3LjIuMSkuIFdpbGwgY2xhcmlmeS48L3NwYW4+ PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KRG9lcyDigJx0aGlzIGxlZ+KAmXMgc2lnbmFsaW5nIGNvbnRleHTigJ0gcmVm ZXIgdG8gdGhlIOKAnFJUUCBtaXhlciAtIFJlY2VpdmVy4oCdIGNhbGwgbGVnPzxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5bQm9CXSBO b3QgbmVjZXNzYXJpbHkganVzdCBSVFAgc3RyZWFtIHJlY2VpdmVyLCBpdCBjb3VsZCBhbHNvIGJl IFJUUCBzdHJlYW0gc2VuZGVyLCBvdGhlcndpc2UgeWVzLiBJdCBpcyB0aGUgY29udGV4dCBvZiBh IHNpbmdsZSBTRFAgb2ZmZXIvYW5zd2VyIGJldHdlZW4gdHdvIHBhcnRpY2lwYW50cw0KIChSVFAg bWl4ZXIgYW5kIHdoYXRldmVyIGVuZHBvaW50IGlzIHRoZSBjb3VudGVycGFydCDigJMgcG9zc2li bHkgZXZlbiBhbm90aGVyIFJUUCBtaXhlcikuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpw IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClRoZSBzZW50ZW5j ZSDigJxJbiBhZGRpdGlvbiwgdGhlIGRlZmluZWQgUnRwU3RyZWFtSWRz4oCmLnRoYXQgY2FuIGJl IHN3aXRjaGVkIGludG8gdGhpcyBtZWRpYSBzb3VyY2UmcXVvdDsgaXMgbm90IGNsZWFyIHRvIG1l LiBTcGVjaWZpY2FsbHkgd2h5IHdvdWxkIHdlIHN3aXRjaGluZyBhbiBSVFAgc3RyZWFtPHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPmlu dG88L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmEN CiBtZWRpYSBzb3VyY2UuIFdhcyBpdCBpbnRlbmRlZCB0byBiZSDigJxzd2l0Y2hlZCBmcm9tIHRo aXMgbWVkaWEgc291cmNl4oCdIG9yIOKAnHN3aXRjaGVkIHRvIGEgUlRQIHJlY2VpdmVy4oCdPyBQ bGVhc2UgZXhwbGFpbi48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+W0JvQl0gVGhlIFJUUCBtaXhlciByZWNlaXZlcyAocG90ZW50aWFs bHkgc2ltdWxjYXN0KSBSVFAgc3RyZWFtcyBmcm9tIG9yaWdpbmF0aW5nIG1lZGlhIHNvdXJjZXMg YW5kIHN3aXRjaGVzIHRob3NlIFJUUCBwYWNrZXRzIGludGVybmFsbHkgdG8gcHJvdmlkZSBkYXRh IGZvciB0aGUNCiBSVFAgbWl4ZXLigJlzIG93biBtZWRpYSBzb3VyY2VzIGFuZCBSVFAgc3RyZWFt cywgYXMgc2VlbiBieSB0aGUgZmluYWwgcmVjZWl2ZXIgb2YgdGhlIFJUUCBzdHJlYW1zIGZyb20g dGhlIFJUUCBtaXhlci4gV2hhdCBhYm91dCByZS1mb3JtdWxhdGluZyB0byDigJxJbiBhZGRpdGlv biwgdGhlIGRlZmluZWQgUnRwU3RyZWFtSWRzIGFuZCB0aGVpciBwYXJhbWV0ZXJzIG5lZWQgdG8g Y292ZXIgYWxsIHRoZSBtZWRpYSBzb3VyY2VzIGFuZCBzaW11bGNhc3Qgc3RyZWFtczxzcGFuIHN0 eWxlPSJjb2xvcjogcmVkOyIgY2xhc3M9IiI+cmVjZWl2ZWQNCiBieSB0aGUgUlRQIG1peGVyPHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj50aGF0 IGNhbiBiZSBzd2l0Y2hlZCBpbnRvIHRoaXMgbWVkaWEgc291cmNlPHNwYW4gc3R5bGU9ImNvbG9y OiByZWQ7IiBjbGFzcz0iIj4sIHNlbnQgYnkgdGhlIFJUUCBtaXhlcjwvc3Bhbj7igJ0/PC9zcGFu PjwvaT48L2I+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+WWVzISB0aGlz IGdpdmVzIG1vcmUgY2xhcml0eS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2PlRoYW5rcyE8L2Rpdj4NCjxkaXY+QXJ1bjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdv cmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9u ZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogYmx1ZTsgYm9yZGVyLWxlZnQtd2lkdGg6 IDEuNXB0OyBwYWRkaW5nOiAwY20gMGNtIDBjbSA0cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86 cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNz PSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJv dHRvbTogNXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIE1hciAzMCwgMjAxNywgYXQgNTo0MiBQ TSwgQXJ1biBBcnVuYWNoYWxhbSAoY2FydW5hY2gpICZsdDs8YSBocmVmPSJtYWlsdG86Y2FydW5h Y2hAY2lzY28uY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7IiBjbGFzcz0iIj5jYXJ1bmFjaEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpIaSBGbGVtbWluZyw8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7 PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KSSB0aGluayBpbiBhYm91dCBhIHdlZWsgaS5l IGJ5IEVPQiA0LzcuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClRoYW5rcyE8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAxMnB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCkFydW48bzpwIGNs YXNzPSIiPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KU2VudCBmcm9tIG15IGlQaG9uZTxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMTJwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8YnIgY2xhc3M9IiI+ DQpPbiBNYXIgMzAsIDIwMTcsIGF0IDQ6MzMgUE0sIEZsZW1taW5nIEFuZHJlYXNlbiAoZmFuZHJl YXMpICZsdDs8YSBocmVmPSJtYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tIiBzdHlsZT0iY29sb3I6 IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5mYW5kcmVhc0Bj aXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAxMnB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7Ij4NClRoYW5rcyBBcnVuIC0gd2hlbiBkbyB5b3UgdGhpbmsgeW91 IHdpbGwgaGF2ZSB0aGUgcmV2aWV3IHJlYWR5ID88c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0gRmxl bW1pbmc8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86 cCBjbGFzcz0iIj48L286cD48L3A+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIDMvMzAvMTcgNDozMCBQTSwgQXJ1biBB cnVuYWNoYWxhbSAoY2FydW5hY2gpIHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206 IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCkhpIEZsZW1taW5nLDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkFzIGRpc2N1c3NlZCwg aSB3b3VsZCBiZSBnbGFkIHRvIHJldmlldyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdCIgc3R5 bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdDwvYT4mbmJzcDtkcmFmdC48bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KVGhhbmtzITxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KQXJ1bjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KLjxzcGFuIGNsYXNzPSJBcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DAE6CF8D63E746279F1CEAAD129E1342ciscocom_-- From nobody Mon May 8 00:39:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887C2128B93; Mon, 8 May 2017 00:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 yuakVj8n0_7W; Mon, 8 May 2017 00:39:41 -0700 (PDT) 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 349901252BA; Mon, 8 May 2017 00:39:39 -0700 (PDT) X-AuditID: c1b4fb3a-b95ff70000005025-ed-591020b998df Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 66.BD.20517.9B020195; Mon, 8 May 2017 09:39:38 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.339.0; Mon, 8 May 2017 09:39:37 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+uXmRl9GJ+zlEYOy3dEtXFO9Fh+l8BlQYAqCCTsvNoo=; b=K11dlDTMLeqQTYWbpHj/X5nbQjtznbseYNSfaQgH2NLA3fJ8tNHSoSFu0syUkMUt/OSF7MEIQ6BkpFQwDEi7GONhkefu4/KWRPuxEGo2fFzqEq2TxjmdZv36PqCeHaZ+AFj2yNUjSvouWbbQOT4yOuBk5JnFyaC0lmg6ONIb1pc= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2579.eurprd07.prod.outlook.com (10.173.92.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Mon, 8 May 2017 07:39:36 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.1084.015; Mon, 8 May 2017 07:39:36 +0000 From: Bo Burman To: "Arun Arunachalam (carunach)" CC: "mmusic (mmusic@ietf.org)" , "Flemming Andreasen (fandreas)" , "draft-ietf-mmusic-sdp-simulcast.authors@ietf.org" Thread-Topic: Review: draft-ietf-mmusic-sdp-simulcast Thread-Index: AQHSqZ1LgElfJhuy3UubAvb9EhsTOqGt6dmAgA8E2ICAJefu4IAGgY6AgADwIDA= Date: Mon, 8 May 2017 07:39:35 +0000 Message-ID: References: <6351CDC7-7925-4448-A39E-56FCC9F2B12C@cisco.com> <991504f1-bb9c-17c7-432f-a53154d2da33@cisco.com> <344988B5-DEF9-41A4-BC15-7D8E07A22448@cisco.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.86] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2579; 7:JiANSUcfiwh52YCkF5yOqkLdIvZYZthwIuGLT7DCyv1c0l2WBXio4z5taKSIp8Bv39vV8wM0HuzDWNn8joxRIMKB3ewCtal6zNWcvQZ7e/u7qNmBQpgX16vzX6iJ3yVQb4WbeKc0Y+wvtLGYbCbOJqZnGiuwoYCBnyndG1unxa6gq5ciHo57guKfuGJMllasvr8Rbta1ckReNDz04eooYEJE9qmiXux8tjAkGAONYLnycL09dUVTzfh7E4Dw1ITPFjXmaJO2yM9Wy5JPzLBj+X2XwSMuR+wA2ICYEdE1DPB62LzLEgYDc8ekH+eWOvkyWII0i5vE1lXlfUZdp0YmNQ== x-ms-office365-filtering-correlation-id: 305c9f2e-cc12-43fc-eb64-08d495e56039 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2579; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(6072148); SRVR:AM5PR0701MB2579; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2579; x-forefront-prvs: 0301360BF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39400400002)(39410400002)(39850400002)(39860400002)(39840400002)(24454002)(377454003)(19609705001)(8936002)(122556002)(7736002)(86362001)(77096006)(229853002)(7906003)(478600001)(3660700001)(66066001)(189998001)(3280700002)(8676002)(2906002)(81166006)(2950100002)(7696004)(6916009)(6436002)(76176999)(230783001)(3846002)(6506006)(236005)(50986999)(55016002)(93886004)(606005)(53936002)(54896002)(9686003)(53546009)(102836003)(6306002)(561944003)(4326008)(99286003)(25786009)(6246003)(38730400002)(33656002)(110136004)(345774005)(53946003)(5660300001)(6116002)(54356999)(74316002)(790700001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2579; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB25776AF092A7D09EFEABB2858DEE0AM5PR0701MB2577_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2017 07:39:35.9629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2579 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85247S6G0qPprCWn1QQS3RWJahfggpjD6Flw95yNMcXjtn iQbFjErULJeaFzQ1ZjqTwnRNpkZqalle0KCwdIraxUAtSJ1Gtu0s8tv/ef+/58pLkzKTyJtW Z2hYLoNJU4hdqao405FAsxzHH6xadVPmzd6TKLs/jVLKlfFAZXnTPBVJxZRttYli9HorcYZI cD2WzKaps1ku+HiSa0pFTz6RVblE5mz0apEWdU+ThciFBhwKazeNkkLkSsvwSwSNtV1ICIYQ vPjxXmwPKFxMwmZNvVhwKgjorG/7j1l/TxL2YmLsB3Wd08iu3fFhWDQ1OwqTeBKB5dmgA3Kz dZwwDYsKEW2DwmDDGiTwp2FwyuoYisIHYKD2usiupTgJWix6UmhmIWC2xCCx57rgCDB0cHYG YV+wrM9Qdk1iT5haqCOE5TDou8eci3rAt/k/InsdhIsRGAxbYsGQg2Wz1An5wkRdkWMzwLdJ MH7ocRqxMNJwlxAMLYLivGvO7ExYmhxytkuFmvU7pACtEaDXtYsEwwdWvw87s/PFMFbxixRu 4Q3T7wpQCfKv3jG7oDOhtaZVUu24wR54XbVAVdvWJrE/PDEHC8g+KCuakwjaD27U1Ep2vtcj SQvy4FmeT1eFhASxnPo8z2dmBGWwmqfI9p16O7bCO1Hvl6g+hGmk2CWdrdwdLxMx2Xxueh8C mlS4Sxs8cLxMmszkXma5zHPcpTSW70N7aUrhKY18Ph4nwypGw6aybBbL/XMJ2sXb9sOuxD7c c9K43Lyte9Dc9NX8ynrUZ3PF5/N6RGSYKdrDOBcg+qlEw2d1/XO53PZ2wX2mNG1Lo5toilDO z+wfoduUj3MWmYSL8lE60CuKeTuGEy+Uf2wPzW7sUq1eLeXXSzYGTsmbbp2oan/kp00kos3L THC4qrZ/Te01EuX2RkHxKcyhAJLjmb8SYbv0SgMAAA== Archived-At: Subject: Re: [MMUSIC] Review: draft-ietf-mmusic-sdp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 07:39:45 -0000 --_000_AM5PR0701MB25776AF092A7D09EFEABB2858DEE0AM5PR0701MB2577_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T0ssIHRoYW5rcyEgV2lsbCBtYWtlIGNvcnJlc3BvbmRpbmcgdXBkYXRlcyBpbiBuZXh0IHZlcnNp b24hIFNlZSBhbHNvIGEgZmV3IGNvbW1lbnRzIGlubGluZSBiZWxvdy4NCi9Cbw0KDQpGcm9tOiBB cnVuIEFydW5hY2hhbGFtIChjYXJ1bmFjaCkgW21haWx0bzpjYXJ1bmFjaEBjaXNjby5jb21dDQpT ZW50OiBkZW4gNyBtYWogMjAxNyAxOToxNw0KVG86IEJvIEJ1cm1hbiA8Ym8uYnVybWFuQGVyaWNz c29uLmNvbT4NCkNjOiBtbXVzaWMgKG1tdXNpY0BpZXRmLm9yZykgPG1tdXNpY0BpZXRmLm9yZz47 IEZsZW1taW5nIEFuZHJlYXNlbiAoZmFuZHJlYXMpIDxmYW5kcmVhc0BjaXNjby5jb20+OyBkcmFm dC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LmF1dGhvcnNAaWV0Zi5vcmc7IEFydW4gQXJ1bmFj aGFsYW0gKGNhcnVuYWNoKSA8Y2FydW5hY2hAY2lzY28uY29tPg0KU3ViamVjdDogUmU6IFJldmll dzogZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdA0KDQpUaGFua3MgQm8gIQ0KDQpQbGVh c2Ugc2VlIGlubGluZS4NCg0KT24gTWF5IDMsIDIwMTcsIGF0IDEyOjE0IFBNLCBCbyBCdXJtYW4g PGJvLmJ1cm1hbkBlcmljc3Nvbi5jb208bWFpbHRvOmJvLmJ1cm1hbkBlcmljc3Nvbi5jb20+PiB3 cm90ZToNCg0KSGkgQXJ1biwNCg0KVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMhIFBsZWFzZSBz ZWUgbXkgcmVzcG9uc2VzIGlubGluZSBiZWxvdy4NCg0KQ2hlZXJzLA0KL0JvDQoNCkZyb206IEFy dW4gQXJ1bmFjaGFsYW0gKGNhcnVuYWNoKSBbbWFpbHRvOmNhcnVuYWNoQGNpc2NvLmNvbV0NClNl bnQ6IGRlbiA5IGFwcmlsIDIwMTcgMTM6MDQNClRvOiBCbyBCdXJtYW4gPGJvLmJ1cm1hbkBlcmlj c3Nvbi5jb208bWFpbHRvOmJvLmJ1cm1hbkBlcmljc3Nvbi5jb20+Pg0KQ2M6IEZsZW1taW5nIEFu ZHJlYXNlbiAoZmFuZHJlYXMpIDxmYW5kcmVhc0BjaXNjby5jb208bWFpbHRvOmZhbmRyZWFzQGNp c2NvLmNvbT4+OyBBcnVuIEFydW5hY2hhbGFtIChjYXJ1bmFjaCkgPGNhcnVuYWNoQGNpc2NvLmNv bTxtYWlsdG86Y2FydW5hY2hAY2lzY28uY29tPj4NClN1YmplY3Q6IFJlOiBSZXZpZXc6IGRyYWZ0 LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3QNCg0KSGkgQm8sDQoNClJldmlld2VkIHRoZSBkcmFm dCBhbmQgaGF2ZSBhIGZldyBjb21tZW50cyBhbmQgcXVlc3Rpb25zIChzaG93biBiZWxvdykuDQoN ClRoYW5rcyENCkFydW4NCg0KQ29tbWVudHMgLyBRdWVzdGlvbnM6DQoNCigxKSBTZWN0aW9uIDE8 aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNh c3QtMDgjc2VjdGlvbi0xPg0KDQogICB0cmFuc3BvcnQgb3ZlciBSVFAuICBUaGUgbWVkaWEgdHJh bnNwb3J0IHRvcG9sb2dpZXMgY29uc2lkZXJlZCBhcmUNCiAgIHBvaW50IHRvIHBvaW50IFJUUCBz ZXNzaW9ucyBhcyB3ZWxsIGFzIGNlbnRyYWxpemVkIG11bHRpLXBhcnR5IFJUUA0KICAgc2Vzc2lv bnMsIHdoZXJlIGEgbWVkaWEgc2VuZGVyIHdpbGwgcHJvdmlkZSB0aGUgc2ltdWxjYXN0ZWQgc3Ry ZWFtcw0KICAgdG8gYW4gUlRQIG1pZGRsZWJveCBvciBlbmRwb2ludCwgYW5kIG1pZGRsZWJveGVz IG1heSBmdXJ0aGVyDQogICBkaXN0cmlidXRlIHRoZSBzaW11bGNhc3Qgc3RyZWFtcyB0byBvdGhl ciBtaWRkbGVib3hlcyBvciBlbmRwb2ludHMuDQoNClNldmVyYWwgcGxhY2VzIGluIHRoZSBkb2Mg dXNlIHRoZSB0ZXJtIOKAnFJUUCBTZXNzaW9u4oCdIGFuZCDigJxSVFAgc3RyZWFtc+KAnSBoZW5j ZSBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gcHJvdmlkZSBhIHJlZmVyZW5jZSBzbyB0aGF0IHJlYWRl cnMgY2FuIGtub3cgdGhlIGRpZmZlcmVuY2UuDQoNClJUUCBTZXNzaW9uIOKAlD4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTAjc2VjdGlvbi0xLjENCltCb0JdIEFzIHNhaWQgYXQg dGhlIHN0YXJ0IG9mIHNlY3Rpb24gMi4xIOKAnFRlcm1pbm9sb2d54oCdLCB0aGUgZHJhZnQgZ2Vu ZXJhbGx5IHVzZXMgdGVybXMgZnJvbSBSVFAgVGF4b25vbXkgKFJGQyA3NjU2KS4gQm90aCBSVFAg c3RyZWFtIGFuZCBSVFAgc2Vzc2lvbiBhcmUgdGVybXMgZGVzY3JpYmVkIHRoZXJlLiBSVFAgc2Vz c2lvbiBpcywgYXMgeW91IHNheSwgYWxzbyBkZWZpbmVkIGJ5IFJGUkMgMzU1MCwgYnV0IHRoZXJl IGhhcyBiZWVuIHNpZ25pZmljYW50IGNvbmZ1c2lvbiBhcm91bmQgd2hhdCB0aGUgdGVybSByZWFs bHkgbWVhbnMsIHNvIGFkZGl0aW9uYWwgY2xhcmlmaWNhdGlvbiB3YXMgYWRkZWQgaW4gUkZDIDc2 NTYuIEkgaGF2ZSBubyBwcm9ibGVtIGFkZGluZyB0aGVtIGFzIGV4cGxpY2l0IHRlcm1zIGluIHNl Y3Rpb24gMi4xLCBidXQgd2lsbCB0aGVuIG1vcmUgb3IgbGVzcyBqdXN0IHJlZmVyZW5jZSBSRkMg MzU1MCBhbmQgUkZDIDc2NTYgZnJvbSB0aGVyZS4NCg0KR29vZC4gVGhlIHJlZmVyZW5jZSBpbiB0 aGUgdGVybWlub2xvZ3kgc2VjdGlvbiBzaG91bGQgYmUgc3VmZmljaWVudC4NCg0KDQoNCg0KDQoo MikgU2VjdGlvbiAzLjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11 c2ljLXNkcC1zaW11bGNhc3QtMDgjc2VjdGlvbi0zLjE+DQoNCg0KICAgQml0cmF0ZTogIFRoaXMg cmVsYXRlcyB0byB0aGUgYW1vdW50IG9mIGJpdHMgc3BlbnQgcGVyIHNlY29uZCB0bw0KDQogICAg ICB0cmFuc21pdCB0aGUgbWVkaWEgc291cmNlIGFzIGFuIFJUUCBzdHJlYW0sIHdoaWNoIHR5cGlj YWxseSBhbHNvDQoNCiAgICAgIGFmZmVjdHMgdGhlIFF1YWxpdHkgb2YgRXhwZXJpZW5jZSAoUW9F KSBmb3IgdGhlIHJlY2VpdmluZyB1c2VyLg0KDQpJIHRoaW5rIHRoZSBhdXRob3JzIG1heSBoYXZl IGludGVuZGVkIHRvIHVzZSDigJxzZW504oCdIGluc3RlYWQgb2Yg4oCcc3BlbnQiLg0KW0JvQl0g SSB0aGluayBhIHNlbmRlciBjYW4g4oCcc3BlbmTigJ0gYml0cyBpdCDigJxoYXMgYXZhaWxhYmxl 4oCdIHRvIHNlbmQsIGJ1dCBJIGFncmVlIHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGNoYW5n ZSB0byDigJxzZW504oCdLg0KDQooMykgU2VjdGlvbiA2LjE8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3QtMDgjc2VjdGlvbi02LjE+DQoN CiAgIGRpcmVjdGlvbmFsaXR5IGlzIHJldmVyc2VkLiAgVGhpcyBleGFtcGxlIGFuc3dlciBoYXMg cmVtb3ZlZCBhbGwNCiAgIG9mZmVyZWQgYWx0ZXJuYXRpdmUgZm9ybWF0cyBmb3IgdGhlIGZpcnN0 IHNpbXVsY2FzdCBzdHJlYW0gKGtlZXBpbmcNCiAgIG9ubHkgU0NJRCAxKSwgYnV0IGtlcHQgYWx0 ZXJuYXRpdmUgZm9ybWF0cyBmb3IgdGhlIHNlY29uZCBzaW11bGNhc3QNCiAgIHN0cmVhbSBpbiBy ZWNlaXZlIGRpcmVjdGlvbiAoNCwgNSkuICBUaGUgYW5zd2VyIHRodXMgYWNjZXB0cyB0byBzZW5k DQogICB0d28gc2ltdWxjYXN0IHN0cmVhbXMsIHdpdGhvdXQgYWx0ZXJuYXRpdmVzLiAgVGhlIGFu c3dlciBkb2VzIG5vdA0KICAgYWNjZXB0IGluaXRpYWwgcGF1c2Ugb2YgYW55IHNpbXVsY2FzdCBz dHJlYW1zLCBpbiBlaXRoZXIgZGlyZWN0aW9uLg0KICAgTW9yZSBleGFtcGxlcyBjYW4gYmUgZm91 bmQgaW4gU2VjdGlvbiA2LjYuDQoNClBsZWFzZSByZW1vdmUgdGhlIHdvcmQg4oCcdGh1c+KAnSBz aW5jZSB0aGVyZSBpcyBubyByZWFzb24gcHJvdmlkZWQgcHJpb3IgdG8gdGhpcyBzZW50ZW5jZS4N CltCb0JdIE9LLg0KDQoNCig0KSBTZWN0aW9uIDYuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTYuMj4NCg0KICAg aW5zdGVhZCBvZiBtYWtpbmcgaXQgZXF1aXZhbGVudCB0byBpbXBsaWNpdGx5IHNlbmRpbmcgYSBw YXVzZQ0KICAgcmVxdWVzdCwgaXMgYmVjYXVzZSB0aGUgcGF1c2luZyBSVFAgc2VuZGVyIGNhbm5v dCBrbm93IHdoaWNoDQogICByZWNlaXZpbmcgU1NSQyBvd25zIHRoZSByZXN0cmljdGlvbiB3aGVu IFRNTUJSL1RNTUJOIGFyZSB1c2VkIGZvcg0KICAgcGF1c2UvcmVzdW1lIHNpZ25hbGluZyBzaW5j ZSB0aGUgUlRQIHJlY2VpdmVyJ3MgU1NSQyBpbiBzZW5kDQogICBkaXJlY3Rpb24gaXMgc29tZXRp bWVzIG5vdCB5ZXQga25vd24uDQoNCkl0IHdvdWxkIGJlIGdvb2QgdG8gYSBnaXZlIHJlZmVyZW5j ZSBmb3IgVE1NQlIvVE1NQk4gcG9pbnRpbmcgdG8gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc3Mjgjc2VjdGlvbi0yLjEgb3IgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc3 Mjgjc2VjdGlvbi01LjYuDQpbQm9CXSBPSy4gUHJlZmVyIHNlY3Rpb24gNS42IG9mIFJGQyA3NzI4 LiBIb3dldmVyLCB0aGUgZHJhZnQgc291cmNlIGlzIFhNTCBhbmQgSSBkb27igJl0IHRoaW5rIHht bDJyZmMgPHhyZWY+IHN1cHBvcnRzIHJlZmVyZW5jaW5nIGEgcGFydGljdWxhciBzZWN0aW9uLCBz byBJ4oCZbSBub3Qgc3VyZSBob3cgdG8gYWNoaWV2ZSB0aGF0Lg0KDQoNCkkgdGhpbmsgd2UgY2Fu IHVzZSAiU2VjdGlvbiA1LjYgb2YgPHhyZWYgdGFyZ2V0PSJSRkM3NzI44oCdLz7igJ0gaW4gdGhl IFhNTCB2ZXJzaW9uIG9mIHRoZSBkb2MuDQoNClJlZmVyZW5jZTogaHR0cHM6Ly94bWwycmZjLnRv b2xzLmlldGYub3JnL3htbDJyZmNGQVEuaHRtbCNhbmNob3IxOA0KDQpXb3JraW5nIGV4YW1wbGU6 DQoNClhNTDoNCg0KPHNlY3Rpb24gdGl0bGU9IkludGVybWVkaWFyeSI+DQo8dD5UaGUgdGVybSAi aW50ZXJtZWRpYXJ5IiBpcyBkZWZpbmVkIGluIFNlY3Rpb24gMiBvZiA8eHJlZiB0YXJnZXQ9IlJG Qzc5ODkiLz47IGl0IHJlZmVycyB0byBhbnkgZW50aXR5IGFsb25nIHRoZSBjYWxsIHNpZ25hbGlu ZyBwYXRoLjwvdD4NCjwvc2VjdGlvbj4NCg0KUkZDOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzgxMjMjc2VjdGlvbi0zLjMNCltCb0JdIE9LLCB0aGF0IHdvcmtzDQoNCg0KDQoNCig1 KSBTZWN0aW9uIDYuMy4yPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1t dXNpYy1zZHAtc2ltdWxjYXN0LTA4I3NlY3Rpb24tNi4zLjI+DQoNCiAgIEFuIGFuc3dlcmVyIHRo YXQgcmVjZWl2ZXMgaW5kaWNhdGlvbiBpbiBhbiBvZmZlciBvZiBhbiBTQ0lEIGJlaW5nDQogICBp bml0aWFsbHkgcGF1c2VkIFNIT1VMRCBtYXJrIHRoYXQgU0NJRCBhcyBpbml0aWFsbHkgcGF1c2Vk IGFsc28gaW4NCiAgIHRoZSBhbnN3ZXIsIHJlZ2FyZGxlc3Mgb2YgZGlyZWN0aW9uLCB1bmxlc3Mg aXQgaGFzIGdvb2QgcmVhc29uIGZvcg0KICAgdGhlIFNDSUQgbm90IGJlaW5nIGluaXRpYWxseSBw YXVzZWQuICBPbmUgc3VjaCByZWFzb24gY291bGQsIGZvcg0KICAgZXhhbXBsZSwgYmUgdGhhdCB0 aGUgYW5zd2VyZXIgd291bGQgb3RoZXJ3aXNlIGluaXRpYWxseSBub3QgcmVjZWl2ZQ0KICAgYW55 IG1lZGlhIG9mIHRoYXQgdHlwZSBhdCBhbGwuDQoNClRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBl eGFtcGxlLiBDYW4geW91IHBsZWFzZSBleHBsYWluIGEgc2NlbmFyaW8gaW4gd2hpY2ggdGhlIGV4 YW1wbGUgYXBwbGllcz8NCltCb0JdIFNheSB0aGF0IHlvdSBoYXZlIGEgc2ltdWxjYXN0IHdpdGgg c2V2ZXJhbCBkaWZmZXJlbnQgbWVkaWEgcXVhbGl0eSBsZXZlbHMgYmVpbmcgb2ZmZXJlZC4gVGhl IG9mZmVyZXIgZXhwZWN0cyBtb3N0IHJlY2VpdmVycyB0byBhY2NlcHQgdGhlIGhpZ2hlc3QgcXVh bGl0eSBsZXZlbCwgYW5kIHRoYXQgdGhleSBhcmUgdGhlbiB1bmludGVyZXN0ZWQgdG8gcmVjZWl2 ZSB0aGUgbG93ZXIgcXVhbGl0eSBsZXZlbHMuIFRoZSBvZmZlcmVyIGhhcyB0aGVyZWZvcmUgc2V0 IHRoZSBsb3dlciBxdWFsaXR5IHNpbXVsY2FzdCBzdHJlYW1zIHRvIGluaXRpYWxseSBwYXVzZWQu IEZ1cnRoZXIgYXNzdW1lIGEgc29tZXdoYXQgcmVzdHJpY3RlZCBhbnN3ZXJlciB0aGF0IGNhbm5v dCBjb3BlIHdpdGggdGhlIGhpZ2hlc3QgcXVhbGl0eSBsZXZlbC4gSXQgdGhlcmVmb3JlIHdhbnRz IHRvIGFjY2VwdCBhIGxvd2VyIHF1YWxpdHkgbGV2ZWwgc2ltdWxjYXN0IHN0cmVhbSBhbmQgd291 bGQgbm90IHJlY2VpdmUgYW55dGhpbmcgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgc2Vzc2lvbiAo dW50aWwgaXNzdWluZyBhbiBSRkMgNzcyOCBSRVNVTUUpIGlmIGl0IGFjY2VwdHMgdGhpcyBsb3dl ciBxdWFsaXR5IHNpbXVsY2FzdCBzdHJlYW0gYXMgaW5pdGlhbGx5IHBhdXNlZC4gV2l0aG91dCBp bmNsdWRpbmcgc3VjaCBmYWlybHkgZXh0ZW5zaXZlIGV4YW1wbGUgdGV4dCwgSSBkb27igJl0IGtu b3cgaG93IHRvIGJlc3QgbWFrZSBhIGNsYXJpZmljYXRpb24uIERvIHlvdSBoYXZlIGEgcHJvcG9z YWw/DQoNCkdvdCBpdC4gTmljZSBleGFtcGxlLg0KDQpIb3cgYWJvdXQgZm9sbG93aW5nOg0KDQog ICBPbmUgc3VjaCByZWFzb24gY291bGQsIGZvciBleGFtcGxlLCBiZSB0aGF0IHRoZSBhbnN3ZXJl ciBkb2VzbuKAmXQgaGF2ZSB0aGUgYWJpbGl0eSB0bw0KICAgcHJvY2VzcyBhbnkgdW5wYXVzZWQg c2ltdWxjYXN0IHN0cmVhbXMgb2ZmZXJlZCBmb3IgYSBnaXZlbiBtZWRpYSBzb3VyY2UuIEl0IGNo b29zZXMNCiAgIG9uZSBvZiB0aGUgcGF1c2VkIHNpbXVsY2FzdCBzdHJlYW0gaW4gdGhlIG9mZmVy IGFuZCBtYXJrcyBpdCBhcyBub3QgcGF1c2VkIGluIHRoZSBhbnN3ZXIuDQoNCltCb0JdIE9LLCBi dXQgc3VnZ2VzdCBtaW5vciB3b3JkaW5nIGNoYW5nZSB0byBrZWVwIGl0IGVudGlyZWx5IGNsZWFy IHRoYXQgdGhlIHNjb3BlIGlzIFNEUCBhbmQgaW5pdGlhbGx5IHBhdXNlZCBzdHJlYW1zOg0KT25l IHN1Y2ggcmVhc29uIGNvdWxkLCBmb3IgZXhhbXBsZSwgYmUgdGhhdCB0aGUgYW5zd2VyZXIgZG9l c24ndCBoYXZlIHRoZSBhYmlsaXR5IHRvIHByb2Nlc3MgYW55IGluaXRpYWxseSB1bnBhdXNlZCBz aW11bGNhc3Qgc3RyZWFtcyBvZmZlcmVkIGZvciBhIGdpdmVuIG1lZGlhIHNvdXJjZS4gSXQgdGhl biBjaG9vc2VzIG9uZSBvZiB0aGUgaW5pdGlhbGx5IHBhdXNlZCBzaW11bGNhc3Qgc3RyZWFtcyBp biB0aGUgb2ZmZXIgYW5kIG1hcmtzIGl0IGFzIG5vdCBwYXVzZWQgaW4gdGhlIGFuc3dlci4NCg0K DQoNCg0KDQooNikgU2VjdGlvbiA3LjIuMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTcuMi4xPg0KDQogICBUaGlz IHdpbGwgcmVzdWx0IGluIGEgc2luZ2xlIFJUUCBzdHJlYW0gYmVpbmcgdXNlZCBmb3IgYSBwYXJ0 aWN1bGFyDQogICBvZiB0aGUgUlRQIG1peGVy4oCZcyBtZWRpYSBzb3VyY2VzLg0KDQoNClRoaXMg c2VudGVuY2Ugc2VlbXMgdG8gYmUgbWlzc2luZyBhIHdvcmQgLSDigJzigKZ0b3IgYSBwYXJ0aWN1 bGFyIF9fX19fX18gb2YgdGhlIFJUUCBtaXhlcuKAmXPigKYu4oCdDQpbQm9CXSBXaGF0IGFib3V0 IHJlcGxhY2luZyDigJxhIHBhcnRpY3VsYXIgb2bigJ0gd2l0aCDigJxlYWNoIG9uZSBvZuKAnT8N Cg0KV2UgY2FuIHVzZSDigJxlYWNoIG9m4oCdOg0KDQogICBUaGlzIHdpbGwgcmVzdWx0IGluIGEg c2luZ2xlIFJUUCBzdHJlYW0gYmVpbmcgdXNlZCBmb3IgZWFjaA0KICAgb2YgdGhlIFJUUCBtaXhl cidzIG1lZGlhIHNvdXJjZXMuDQoNCltCb0JdIE9LDQoNCg0KDQoNCig3KSBTZWN0aW9uIDcuMi4x PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxj YXN0LTA4I3NlY3Rpb24tNy4yLjE+DQoNCiAgICBUaGlzIGFzIHRoZXJlIGlzIG5vdGhpbmcgaW4g dGhlIHNpZ25hbGxpbmcgYmV0d2VlbiB0aGUgbWl4ZXIgYW5kIHRoZSByZWNlaXZlciB0aGF0IGlz IHN0cnVjdHVyZWQgYXJvdW5kIHRoZSBvcmlnaW5hdGluZyBtZWRpYSBzb3VyY2VzLCBvbmx5IHRo ZSBtaXhlcuKAmXMgbWVkaWEgc291cmNlcy4NCg0KIEkgdGhpbmsg4oCcVGhpcyBhc+KAnSBuZWVk cyB0byBiZSBjaGFuZ2VkIHRvIOKAnFRoYXQgaXPigJ0uDQpbQm9CXSBPSy4gSSBhc3N1bWUg4oCc VGhhdCBpcywg4oCcICh3aXRoIGEgY29tbWEpPw0KDQoNCg0KWWVzLg0KDQoNCg0KKDgpIFNlY3Rp b24gNy4yLjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNk cC1zaW11bGNhc3QtMDgjc2VjdGlvbi03LjIuMT4NCg0KICAgSWYgUnRwU3RyZWFtSWRzIGFyZSB1 c2VkIGluIHRoaXMgc2NlbmFyaW8sIGl0IHNob3VsZCBiZSBub3RlZCB0aGF0DQogICB0aGUgUnRw U3RyZWFtSWQgb24gYSBwYXJ0aWN1bGFyIFNTUkMgd2lsbCBjaGFuZ2UgYmFzZWQgb24gdGhlIGFj dHVhbA0KICAgc2ltdWxjYXN0IHN0cmVhbSBzZWxlY3RlZCBmb3Igc3dpdGNoaW5nLiAgVGhlc2Ug UnRwU3RyZWFtSWQNCiAgIGlkZW50aWZpZXJzIHdpbGwgYmUgbG9jYWwgdG8gdGhpcyBsZWfigJlz IHNpZ25hbGxpbmcgY29udGV4dC4gIEluDQogICBhZGRpdGlvbiwgdGhlIGRlZmluZWQgUnRwU3Ry ZWFtSWRzIGFuZCB0aGVpciBwYXJhbWV0ZXJzIG5lZWQgdG8gY292ZXINCiAgIGFsbCB0aGUgbWVk aWEgc291cmNlcyBhbmQgc2ltdWxjYXN0IHN0cmVhbXMgdGhhdCBjYW4gYmUgc3dpdGNoZWQgaW50 bw0KICAgdGhpcyBtZWRpYSBzb3VyY2UuDQoNCkluIHRoZSBhYm92ZSBwYXJhZ3JhcGggd2hhdCBk b2VzIOKAnHRoaXMgc2NlbmFyaW/igJ0gcmVmZXIgdG8/IElzIGl0IHRoZSBzY2VuYXJpbyBvZiB1 c2luZyBtZWRpYSBzb3VyY2XigJlzIHJ0cCBzdHJlYW0gU1NSQyBpbiB0aGUgQ1NSQyBvZiB0aGUg cnRwIG1peGVy4oCZcyBydHAgc3RyZWFtIChvcikgaXMgaXQgcmVmZXJyaW5nIHRvIOKAnFJUUCBN aXhlciAtIFJlY2VpdmVy4oCdIHNjZW5hcmlvcyBpbiBnZW5lcmFsPw0KW0JvQl0g4oCcVGhpcyBz Y2VuYXJpb+KAnSBtZWFucyB0byByZWZlciB0byB0aGlzIHNlY3Rpb24gKDcuMi4xKS4gV2lsbCBj bGFyaWZ5Lg0KDQpEb2VzIOKAnHRoaXMgbGVn4oCZcyBzaWduYWxpbmcgY29udGV4dOKAnSByZWZl ciB0byB0aGUg4oCcUlRQIG1peGVyIC0gUmVjZWl2ZXLigJ0gY2FsbCBsZWc/DQpbQm9CXSBOb3Qg bmVjZXNzYXJpbHkganVzdCBSVFAgc3RyZWFtIHJlY2VpdmVyLCBpdCBjb3VsZCBhbHNvIGJlIFJU UCBzdHJlYW0gc2VuZGVyLCBvdGhlcndpc2UgeWVzLiBJdCBpcyB0aGUgY29udGV4dCBvZiBhIHNp bmdsZSBTRFAgb2ZmZXIvYW5zd2VyIGJldHdlZW4gdHdvIHBhcnRpY2lwYW50cyAoUlRQIG1peGVy IGFuZCB3aGF0ZXZlciBlbmRwb2ludCBpcyB0aGUgY291bnRlcnBhcnQg4oCTIHBvc3NpYmx5IGV2 ZW4gYW5vdGhlciBSVFAgbWl4ZXIpLg0KDQpUaGUgc2VudGVuY2Ug4oCcSW4gYWRkaXRpb24sIHRo ZSBkZWZpbmVkIFJ0cFN0cmVhbUlkc+KApi50aGF0IGNhbiBiZSBzd2l0Y2hlZCBpbnRvIHRoaXMg bWVkaWEgc291cmNlIiBpcyBub3QgY2xlYXIgdG8gbWUuIFNwZWNpZmljYWxseSB3aHkgd291bGQg d2Ugc3dpdGNoaW5nIGFuIFJUUCBzdHJlYW0gaW50byBhIG1lZGlhIHNvdXJjZS4gV2FzIGl0IGlu dGVuZGVkIHRvIGJlIOKAnHN3aXRjaGVkIGZyb20gdGhpcyBtZWRpYSBzb3VyY2XigJ0gb3Ig4oCc c3dpdGNoZWQgdG8gYSBSVFAgcmVjZWl2ZXLigJ0/IFBsZWFzZSBleHBsYWluLg0KW0JvQl0gVGhl IFJUUCBtaXhlciByZWNlaXZlcyAocG90ZW50aWFsbHkgc2ltdWxjYXN0KSBSVFAgc3RyZWFtcyBm cm9tIG9yaWdpbmF0aW5nIG1lZGlhIHNvdXJjZXMgYW5kIHN3aXRjaGVzIHRob3NlIFJUUCBwYWNr ZXRzIGludGVybmFsbHkgdG8gcHJvdmlkZSBkYXRhIGZvciB0aGUgUlRQIG1peGVy4oCZcyBvd24g bWVkaWEgc291cmNlcyBhbmQgUlRQIHN0cmVhbXMsIGFzIHNlZW4gYnkgdGhlIGZpbmFsIHJlY2Vp dmVyIG9mIHRoZSBSVFAgc3RyZWFtcyBmcm9tIHRoZSBSVFAgbWl4ZXIuIFdoYXQgYWJvdXQgcmUt Zm9ybXVsYXRpbmcgdG8g4oCcSW4gYWRkaXRpb24sIHRoZSBkZWZpbmVkIFJ0cFN0cmVhbUlkcyBh bmQgdGhlaXIgcGFyYW1ldGVycyBuZWVkIHRvIGNvdmVyIGFsbCB0aGUgbWVkaWEgc291cmNlcyBh bmQgc2ltdWxjYXN0IHN0cmVhbXNyZWNlaXZlZCBieSB0aGUgUlRQIG1peGVyIHRoYXQgY2FuIGJl IHN3aXRjaGVkIGludG8gdGhpcyBtZWRpYSBzb3VyY2UsIHNlbnQgYnkgdGhlIFJUUCBtaXhlcuKA nT8NCg0KWWVzISB0aGlzIGdpdmVzIG1vcmUgY2xhcml0eS4NCg0KVGhhbmtzIQ0KQXJ1bg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9uIE1hciAzMCwgMjAxNywgYXQgNTo0MiBQTSwgQXJ1 biBBcnVuYWNoYWxhbSAoY2FydW5hY2gpIDxjYXJ1bmFjaEBjaXNjby5jb208bWFpbHRvOmNhcnVu YWNoQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpIaSBGbGVtbWluZywNCg0KSSB0aGluayBpbiBhYm91 dCBhIHdlZWsgaS5lIGJ5IEVPQiA0LzcuDQoNClRoYW5rcyENCkFydW4NClNlbnQgZnJvbSBteSBp UGhvbmUNCg0KT24gTWFyIDMwLCAyMDE3LCBhdCA0OjMzIFBNLCBGbGVtbWluZyBBbmRyZWFzZW4g KGZhbmRyZWFzKSA8ZmFuZHJlYXNAY2lzY28uY29tPG1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20+ PiB3cm90ZToNClRoYW5rcyBBcnVuIC0gd2hlbiBkbyB5b3UgdGhpbmsgeW91IHdpbGwgaGF2ZSB0 aGUgcmV2aWV3IHJlYWR5ID8NCg0KLS0gRmxlbW1pbmcNCk9uIDMvMzAvMTcgNDozMCBQTSwgQXJ1 biBBcnVuYWNoYWxhbSAoY2FydW5hY2gpIHdyb3RlOg0KSGkgRmxlbW1pbmcsDQoNCkFzIGRpc2N1 c3NlZCwgaSB3b3VsZCBiZSBnbGFkIHRvIHJldmlldyBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2lt dWxjYXN0PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1t bXVzaWMtc2RwLXNpbXVsY2FzdD4gZHJhZnQuDQoNClRoYW5rcyENCkFydW4NCg0KDQouDQoNCg== --_000_AM5PR0701MB25776AF092A7D09EFEABB2858DEE0AM5PR0701MB2577_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNv bnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29s YXMiLHNlcmlmO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUt dGFiLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9LLCB0aGFua3Mh IFdpbGwgbWFrZSBjb3JyZXNwb25kaW5nIHVwZGF0ZXMgaW4gbmV4dCB2ZXJzaW9uISBTZWUgYWxz byBhIGZldyBjb21tZW50cyBpbmxpbmUgYmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4vQm88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQXJ1biBBcnVuYWNoYWxhbSAoY2Fy dW5hY2gpIFttYWlsdG86Y2FydW5hY2hAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IGRl biA3IG1haiAyMDE3IDE5OjE3PGJyPg0KPGI+VG86PC9iPiBCbyBCdXJtYW4gJmx0O2JvLmJ1cm1h bkBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBtbXVzaWMgKG1tdXNpY0BpZXRmLm9y ZykgJmx0O21tdXNpY0BpZXRmLm9yZyZndDs7IEZsZW1taW5nIEFuZHJlYXNlbiAoZmFuZHJlYXMp ICZsdDtmYW5kcmVhc0BjaXNjby5jb20mZ3Q7OyBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxj YXN0LmF1dGhvcnNAaWV0Zi5vcmc7IEFydW4gQXJ1bmFjaGFsYW0gKGNhcnVuYWNoKSAmbHQ7Y2Fy dW5hY2hAY2lzY28uY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUmV2aWV3OiBkcmFm dC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIEJvICEgPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ugc2VlIGlubGluZS48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXkgMywgMjAxNywgYXQgMTI6MTQgUE0s IEJvIEJ1cm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJvLmJ1cm1hbkBlcmljc3Nvbi5jb20iPmJv LmJ1cm1hbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGkgQXJ1biw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmsgeW91IGZvciB0aGUg Y29tbWVudHMhIFBsZWFzZSBzZWUgbXkgcmVzcG9uc2VzIGlubGluZSBiZWxvdy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+L0JvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFydW4N CiBBcnVuYWNoYWxhbSAoY2FydW5hY2gpIFs8YSBocmVmPSJtYWlsdG86Y2FydW5hY2hAY2lzY28u Y29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86Y2FydW5hY2hAY2lzY28uY29t PC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5kZW4gOSBhcHJpbCAyMDE3IDEzOjA0PGJyPg0KPGI+VG86PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5CbyBCdXJtYW4gJmx0 OzxhIGhyZWY9Im1haWx0bzpiby5idXJtYW5AZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj5iby5idXJtYW5AZXJpY3Nzb24uY29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5G bGVtbWluZyBBbmRyZWFzZW4gKGZhbmRyZWFzKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmZhbmRyZWFz QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ZmFuZHJlYXNAY2lzY28uY29t PC9zcGFuPjwvYT4mZ3Q7OyBBcnVuIEFydW5hY2hhbGFtIChjYXJ1bmFjaCkgJmx0OzxhIGhyZWY9 Im1haWx0bzpjYXJ1bmFjaEBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNh cnVuYWNoQGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogUmV2aWV3OiBk cmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQm8s PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBoYXZlIGEgZmV3IGNvbW1lbnRzIGFu ZCBxdWVzdGlvbnMgKHNob3duIGJlbG93KS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QXJ1bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOiNGRjZBMDAiPkNvbW1lbnRzIC8gUXVlc3Rpb25zPC9z cGFuPjwvYj46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oMSkmbmJzcDs8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNp bXVsY2FzdC0wOCNzZWN0aW9uLTEiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPlNlY3Rpb24g MTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7dHJhbnNwb3J0IG92ZXIgUlRQLiAmbmJzcDtUaGUgbWVkaWEgdHJhbnNwb3J0IHRvcG9sb2dp ZXMgY29uc2lkZXJlZCBhcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtwb2ludCB0byBwb2ludDxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5SVFAgc2Vz c2lvbnM8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PmFzIHdlbGwgYXMgY2VudHJhbGl6ZWQgbXVsdGktcGFydHkgUlRQPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7c2Vzc2lvbnMsIHdoZXJlIGEgbWVkaWEgc2VuZGVyIHdpbGwgcHJvdmlkZSB0aGUgc2lt dWxjYXN0ZWQgc3RyZWFtczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3RvIGFuIFJUUCBtaWRkbGVi b3ggb3IgZW5kcG9pbnQsIGFuZCBtaWRkbGVib3hlcyBtYXkgZnVydGhlcjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwO2Rpc3RyaWJ1dGUgdGhlIHNpbXVsY2FzdCBzdHJlYW1zIHRvIG90aGVyIG1pZGRs ZWJveGVzIG9yIGVuZHBvaW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T ZXZlcmFsIHBsYWNlcyBpbiB0aGUgZG9jIHVzZSB0aGUgdGVybSDigJxSVFAgU2Vzc2lvbuKAnSBh bmQg4oCcUlRQIHN0cmVhbXPigJ0gaGVuY2UgaXQgd291bGQgYmUgdXNlZnVsIHRvIHByb3ZpZGUg YSByZWZlcmVuY2Ugc28gdGhhdCByZWFkZXJzIGNhbiBrbm93IHRoZSBkaWZmZXJlbmNlLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SVFAgU2Vzc2lvbiDigJQmZ3Q7Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM1NTAjc2VjdGlvbi0xLjEiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNTUwI3Nl Y3Rpb24tMS4xPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W0JvQl0gQXMgc2FpZCBhdCB0 aGUgc3RhcnQgb2Ygc2VjdGlvbiAyLjEg4oCcVGVybWlub2xvZ3nigJ0sIHRoZSBkcmFmdCBnZW5l cmFsbHkgdXNlcyB0ZXJtcyBmcm9tIFJUUCBUYXhvbm9teSAoUkZDIDc2NTYpLiBCb3RoIFJUUCBz dHJlYW0gYW5kIFJUUCBzZXNzaW9uIGFyZSB0ZXJtcyBkZXNjcmliZWQNCiB0aGVyZS4gUlRQIHNl c3Npb24gaXMsIGFzIHlvdSBzYXksIGFsc28gZGVmaW5lZCBieSBSRlJDIDM1NTAsIGJ1dCB0aGVy ZSBoYXMgYmVlbiBzaWduaWZpY2FudCBjb25mdXNpb24gYXJvdW5kIHdoYXQgdGhlIHRlcm0gcmVh bGx5IG1lYW5zLCBzbyBhZGRpdGlvbmFsIGNsYXJpZmljYXRpb24gd2FzIGFkZGVkIGluIFJGQyA3 NjU2LiBJIGhhdmUgbm8gcHJvYmxlbSBhZGRpbmcgdGhlbSBhcyBleHBsaWNpdCB0ZXJtcyBpbiBz ZWN0aW9uIDIuMSwgYnV0DQogd2lsbCB0aGVuIG1vcmUgb3IgbGVzcyBqdXN0IHJlZmVyZW5jZSBS RkMgMzU1MCBhbmQgUkZDIDc2NTYgZnJvbSB0aGVyZS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdvb2QuIFRoZSByZWZl cmVuY2UgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gc2hvdWxkIGJlIHN1ZmZpY2llbnQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPigyKSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3NlY3Rpb24tMy4xIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5TZWN0aW9uIDMuMTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZu YnNwOyBCaXRyYXRlOiZuYnNwOyBUaGlzIHJlbGF0ZXMgdG8gdGhlIGFtb3VudCBvZiBiaXRzIDxi PnNwZW50IHBlciBzZWNvbmQ8L2I+IHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRyYW5zbWl0IHRoZSBtZWRpYSBzb3VyY2Ug YXMgYW4gUlRQIHN0cmVhbSwgd2hpY2ggdHlwaWNhbGx5IGFsc288L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWZmZWN0cyB0aGUg UXVhbGl0eSBvZiBFeHBlcmllbmNlIChRb0UpIGZvciB0aGUgcmVjZWl2aW5nIHVzZXIuPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSBhdXRob3JzIG1heSBoYXZlIGludGVu ZGVkIHRvIHVzZSDigJw8Yj5zZW50PC9iPuKAnSBpbnN0ZWFkIG9mIOKAnHNwZW50JnF1b3Q7Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5bQm9CXSBJIHRoaW5rIGEgc2VuZGVyIGNhbiDigJxzcGVuZOKAnSBi aXRzIGl0IOKAnGhhcyBhdmFpbGFibGXigJ0gdG8gc2VuZCwgYnV0IEkgYWdyZWUgdGhhdCBpdCB3 b3VsZCBiZSBiZXR0ZXIgdG8gY2hhbmdlIHRvIOKAnHNlbnTigJ0uPC9zcGFuPjwvaT48L2I+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPigzKSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3NlY3Rpb24t Ni4xIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5TZWN0aW9uIDYuMTwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ZGlyZWN0aW9uYWxp dHkgaXMgcmV2ZXJzZWQuICZuYnNwO1RoaXMgZXhhbXBsZSBhbnN3ZXIgaGFzIHJlbW92ZWQgYWxs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7b2ZmZXJlZCBhbHRlcm5hdGl2ZSBmb3JtYXRzIGZvciB0 aGUgZmlyc3Qgc2ltdWxjYXN0IHN0cmVhbSAoa2VlcGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw O29ubHkgU0NJRCAxKSwgYnV0IGtlcHQgYWx0ZXJuYXRpdmUgZm9ybWF0cyBmb3IgdGhlIHNlY29u ZCBzaW11bGNhc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtzdHJlYW0gaW4gcmVjZWl2ZSBkaXJl Y3Rpb24gKDQsIDUpLiAmbmJzcDtUaGUgYW5zd2VyPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPjxzPnRodXM8L3M+PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hY2NlcHRzIHRvIHNlbmQ8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDt0d28gc2ltdWxjYXN0IHN0cmVhbXMsIHdpdGhvdXQgYWx0ZXJuYXRpdmVz LiAmbmJzcDtUaGUgYW5zd2VyIGRvZXMgbm90PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7YWNjZXB0 IGluaXRpYWwgcGF1c2Ugb2YgYW55IHNpbXVsY2FzdCBzdHJlYW1zLCBpbiBlaXRoZXIgZGlyZWN0 aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO01vcmUgZXhhbXBsZXMgY2FuIGJlIGZvdW5kIGlu IFNlY3Rpb24gNi42LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBy ZW1vdmUgdGhlIHdvcmQg4oCcdGh1c+KAnSBzaW5jZSB0aGVyZSBpcyBubyByZWFzb24gcHJvdmlk ZWQgcHJpb3IgdG8gdGhpcyBzZW50ZW5jZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W0JvQl0gT0suPC9z cGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ KDQpJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt bW11c2ljLXNkcC1zaW11bGNhc3QtMDgjc2VjdGlvbi02LjIiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPlNlY3Rpb24gNi4yPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDtpbnN0ZWFkIG9mIG1ha2luZyBpdCBlcXVpdmFsZW50IHRvIGlt cGxpY2l0bHkgc2VuZGluZyBhIHBhdXNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cmVxdWVzdCwg aXMgYmVjYXVzZSB0aGUgcGF1c2luZyBSVFAgc2VuZGVyIGNhbm5vdCBrbm93IHdoaWNoPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7cmVjZWl2aW5nIFNTUkMgb3ducyB0aGUgcmVzdHJpY3Rpb24gd2hl bjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5UTU1C Ui9UTU1CTjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+YXJlIHVzZWQgZm9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cGF1c2UvcmVzdW1lIHNpZ25h bGluZyBzaW5jZSB0aGUgUlRQIHJlY2VpdmVyJ3MgU1NSQyBpbiBzZW5kPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7ZGlyZWN0aW9uIGlzIHNvbWV0aW1lcyBub3QgeWV0IGtub3duLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIGdvb2QgdG8gYSBnaXZlIHJlZmVy ZW5jZSBmb3IgVE1NQlIvVE1NQk4gcG9pbnRpbmcgdG8mbmJzcDs8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNzcyOCNzZWN0aW9uLTIuMSI+PHNwYW4gc3R5bGU9ImNvbG9y OnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc3Mjgjc2VjdGlvbi0yLjE8 L3NwYW4+PC9hPiZuYnNwO29yJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzc3Mjgjc2VjdGlvbi01LjYiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NzI4I3NlY3Rpb24tNS42PC9zcGFuPjwvYT4uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPltCb0JdIE9LLiBQcmVmZXIgc2VjdGlvbiA1LjYgb2YgUkZDIDc3Mjgu IEhvd2V2ZXIsIHRoZSBkcmFmdCBzb3VyY2UgaXMgWE1MIGFuZCBJIGRvbuKAmXQgdGhpbmsgeG1s MnJmYyAmbHQ7eHJlZiZndDsgc3VwcG9ydHMgcmVmZXJlbmNpbmcgYSBwYXJ0aWN1bGFyIHNlY3Rp b24sIHNvIEnigJltIG5vdCBzdXJlDQogaG93IHRvIGFjaGlldmUgdGhhdC48L3NwYW4+PC9pPjwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsg d2UgY2FuIHVzZSAmcXVvdDtTZWN0aW9uIDUuNiBvZiAmbHQ7eHJlZiB0YXJnZXQ9JnF1b3Q7UkZD NzcyOOKAnS8mZ3Q74oCdIGluIHRoZSBYTUwgdmVyc2lvbiBvZiB0aGUgZG9jLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWZlcmVuY2U6Jm5i c3A7PGEgaHJlZj0iaHR0cHM6Ly94bWwycmZjLnRvb2xzLmlldGYub3JnL3htbDJyZmNGQVEuaHRt bCNhbmNob3IxOCI+aHR0cHM6Ly94bWwycmZjLnRvb2xzLmlldGYub3JnL3htbDJyZmNGQVEuaHRt bCNhbmNob3IxODwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V29ya2luZyBleGFtcGxlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5YTUw6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7c2VjdGlvbiB0aXRsZT0mcXVv dDtJbnRlcm1lZGlhcnkmcXVvdDsmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7dCZndDtUaGUgdGVybSAmcXVvdDtpbnRlcm1lZGlhcnkm cXVvdDsgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDIgb2YgJmx0O3hyZWYgdGFyZ2V0PSZxdW90O1JG Qzc5ODkmcXVvdDsvJmd0OzsgaXQgcmVmZXJzIHRvIGFueSBlbnRpdHkgYWxvbmcgdGhlIGNhbGwg c2lnbmFsaW5nIHBhdGguJmx0Oy90Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0Oy9zZWN0aW9uJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQzo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTIzI3NlY3Rpb24tMy4zIj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjODEyMyNzZWN0aW9uLTMuMzwvYT48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W0JvQl0gT0ssIHRoYXQg d29ya3M8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oNSkmbmJz cDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMt c2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTYuMy4yIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5TZWN0aW9uIDYuMy4yPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7IEFuIGFuc3dlcmVyIHRoYXQgcmVjZWl2ZXMgaW5kaWNhdGlvbiBpbiBhbiBvZmZl ciBvZiBhbiBTQ0lEIGJlaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgaW5pdGlhbGx5IHBhdXNl ZCBTSE9VTEQgbWFyayB0aGF0IFNDSUQgYXMgaW5pdGlhbGx5IHBhdXNlZCBhbHNvIGluPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsgdGhlIGFuc3dlciwgcmVnYXJkbGVzcyBvZiBkaXJlY3Rpb24sIHVu bGVzcyBpdCBoYXMgZ29vZCByZWFzb24gZm9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgdGhlIFND SUQgbm90IGJlaW5nIGluaXRpYWxseSBwYXVzZWQuJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uZSBzdWNoIHJlYXNvbiBjb3VsZCwgZm9y PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+Jm5ic3A7Jm5ic3A7IGV4YW1wbGUsIGJlIHRoYXQgdGhlIGFuc3dl cmVyIHdvdWxkIG90aGVyd2lzZSBpbml0aWFsbHkgbm90IHJlY2VpdmU8L2I+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj4mbmJzcDsmbmJzcDsgYW55IG1lZGlhIG9mIHRoYXQgdHlwZSBhdCBhbGwuPC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIGV4YW1w bGUuIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4gYSBzY2VuYXJpbyBpbiB3aGljaCB0aGUgZXhhbXBs ZSBhcHBsaWVzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bQm9CXSBTYXkgdGhhdCB5b3UgaGF2ZSBhIHNp bXVsY2FzdCB3aXRoIHNldmVyYWwgZGlmZmVyZW50IG1lZGlhIHF1YWxpdHkgbGV2ZWxzIGJlaW5n IG9mZmVyZWQuIFRoZSBvZmZlcmVyIGV4cGVjdHMgbW9zdCByZWNlaXZlcnMgdG8gYWNjZXB0IHRo ZSBoaWdoZXN0IHF1YWxpdHkgbGV2ZWwsDQogYW5kIHRoYXQgdGhleSBhcmUgdGhlbiB1bmludGVy ZXN0ZWQgdG8gcmVjZWl2ZSB0aGUgbG93ZXIgcXVhbGl0eSBsZXZlbHMuIFRoZSBvZmZlcmVyIGhh cyB0aGVyZWZvcmUgc2V0IHRoZSBsb3dlciBxdWFsaXR5IHNpbXVsY2FzdCBzdHJlYW1zIHRvIGlu aXRpYWxseSBwYXVzZWQuIEZ1cnRoZXIgYXNzdW1lIGEgc29tZXdoYXQgcmVzdHJpY3RlZCBhbnN3 ZXJlciB0aGF0IGNhbm5vdCBjb3BlIHdpdGggdGhlIGhpZ2hlc3QgcXVhbGl0eSBsZXZlbC4gSXQN CiB0aGVyZWZvcmUgd2FudHMgdG8gYWNjZXB0IGEgbG93ZXIgcXVhbGl0eSBsZXZlbCBzaW11bGNh c3Qgc3RyZWFtIGFuZCB3b3VsZCBub3QgcmVjZWl2ZSBhbnl0aGluZyBhdCB0aGUgYmVnaW5uaW5n IG9mIHRoZSBzZXNzaW9uICh1bnRpbCBpc3N1aW5nIGFuIFJGQyA3NzI4IFJFU1VNRSkgaWYgaXQg YWNjZXB0cyB0aGlzIGxvd2VyIHF1YWxpdHkgc2ltdWxjYXN0IHN0cmVhbSBhcyBpbml0aWFsbHkg cGF1c2VkLiBXaXRob3V0IGluY2x1ZGluZyBzdWNoDQogZmFpcmx5IGV4dGVuc2l2ZSBleGFtcGxl IHRleHQsIEkgZG9u4oCZdCBrbm93IGhvdyB0byBiZXN0IG1ha2UgYSBjbGFyaWZpY2F0aW9uLiBE byB5b3UgaGF2ZSBhIHByb3Bvc2FsPzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R290IGl0LiBOaWNlIGV4YW1wbGUuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBh Ym91dCBmb2xsb3dpbmc6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO09uZSBzdWNoIHJlYXNvbiBj b3VsZCwgZm9yIGV4YW1wbGUsIGJlIHRoYXQgdGhlIGFuc3dlcmVyIGRvZXNu4oCZdCBoYXZlIHRo ZSBhYmlsaXR5IHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7cHJvY2VzcyBhbnkgdW5wYXVzZWQgc2ltdWxjYXN0IHN0cmVh bXMgb2ZmZXJlZCBmb3IgYSBnaXZlbiBtZWRpYSBzb3VyY2UuIEl0IGNob29zZXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtv bmUgb2YgdGhlIHBhdXNlZCBzaW11bGNhc3Qgc3RyZWFtIGluIHRoZSBvZmZlciBhbmQgbWFya3Mg aXQgYXMgbm90IHBhdXNlZCBpbiB0aGUgYW5zd2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bQm9C XSBPSywgYnV0IHN1Z2dlc3QgbWlub3Igd29yZGluZyBjaGFuZ2UgdG8ga2VlcCBpdCBlbnRpcmVs eSBjbGVhciB0aGF0IHRoZSBzY29wZSBpcyBTRFAgYW5kDQo8dT5pbml0aWFsbHk8L3U+IHBhdXNl ZCBzdHJlYW1zOjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PbmUgc3VjaCByZWFzb24gY291bGQsIGZvciBleGFtcGxl LCBiZSB0aGF0IHRoZSBhbnN3ZXJlciBkb2Vzbid0IGhhdmUgdGhlIGFiaWxpdHkgdG8gcHJvY2Vz cyBhbnkgaW5pdGlhbGx5IHVucGF1c2VkIHNpbXVsY2FzdCBzdHJlYW1zIG9mZmVyZWQgZm9yIGEg Z2l2ZW4gbWVkaWEgc291cmNlLiBJdCB0aGVuDQogY2hvb3NlcyBvbmUgb2YgdGhlIGluaXRpYWxs eSBwYXVzZWQgc2ltdWxjYXN0IHN0cmVhbXMgaW4gdGhlIG9mZmVyIGFuZCBtYXJrcyBpdCBhcyBu b3QgcGF1c2VkIGluIHRoZSBhbnN3ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4oNikmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTcuMi4xIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5TZWN0aW9uIDcuMi4xPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgd2lsbCByZXN1bHQgaW4gYSBz aW5nbGUgUlRQIHN0cmVhbSBiZWluZyB1c2VkIGZvciBhPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPnBhcnRpY3VsYXI8L2I+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj4m bmJzcDsmbmJzcDsmbmJzcDtvZjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+dGhlIFJUUCBtaXhlcuKAmXMgbWVkaWEgc291cmNlcy4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc2Vu dGVuY2Ugc2VlbXMgdG8gYmUgbWlzc2luZyBhIHdvcmQgLSDigJzigKZ0b3IgYSBwYXJ0aWN1bGFy IF9fX19fX18gb2YgdGhlIFJUUCBtaXhlcuKAmXPigKYu4oCdPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltC b0JdIFdoYXQgYWJvdXQgcmVwbGFjaW5nIOKAnGEgcGFydGljdWxhciBvZuKAnSB3aXRoIOKAnGVh Y2ggb25lIG9m4oCdPzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2UgY2FuIHVzZSDigJxlYWNoIG9m4oCdOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDtUaGlzIHdpbGwgcmVz dWx0IGluIGEgc2luZ2xlIFJUUCBzdHJlYW0gYmVpbmcgdXNlZCBmb3IgZWFjaCZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwO29mIHRoZSBSVFAgbWl4ZXIncyBtZWRpYSBzb3VyY2VzLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT5bQm9CXSA8L2k+PC9iPk9LPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oNykmbmJzcDs8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0w OCNzZWN0aW9uLTcuMi4xIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5TZWN0aW9uIDcuMi4x PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsmbmJzcDs8Yj5UaGlzIGFzPC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj50aGVyZSBpcyBub3RoaW5nIGluIHRoZSBzaWduYWxsaW5nIGJldHdlZW4g dGhlIG1peGVyIGFuZCB0aGUgcmVjZWl2ZXIgdGhhdCBpcyBzdHJ1Y3R1cmVkIGFyb3VuZCB0aGUg b3JpZ2luYXRpbmcgbWVkaWEgc291cmNlcywgb25seSB0aGUgbWl4ZXLigJlzIG1lZGlhIHNvdXJj ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO0kgdGhpbmsg4oCcVGhpcyBhc+KA nSBuZWVkcyB0byBiZSBjaGFuZ2VkIHRvIOKAnFRoYXQgaXPigJ0uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PltCb0JdIE9LLiBJIGFzc3VtZSDigJxUaGF0IGlzLCDigJwgKHdpdGggYSBjb21tYSk/PC9zcGFu PjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPig4KSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3NlY3Rpb24tNy4yLjEiPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPlNlY3Rpb24gNy4yLjE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYgUnRwU3RyZWFtSWRzIGFyZSB1c2VkIGluPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPnRoaXMgc2NlbmFy aW88L2I+LCBpdCBzaG91bGQgYmUgbm90ZWQgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7dGhlIFJ0cFN0cmVhbUlkIG9uIGEgcGFydGljdWxhciBTU1JDIHdpbGwgY2hhbmdlIGJhc2Vk IG9uIHRoZSBhY3R1YWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwO3NpbXVsY2FzdCBzdHJl YW0gc2VsZWN0ZWQgZm9yIHN3aXRjaGluZy4mbmJzcDsmbmJzcDtUaGVzZSBSdHBTdHJlYW1JZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7aWRlbnRpZmllcnMgd2lsbCBiZSBsb2NhbCB0bzxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj50aGlzIGxl Z+KAmXMgc2lnbmFsbGluZyBjb250ZXh0PC9iPi4mbmJzcDsmbmJzcDtJbjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7YWRkaXRpb24sIHRoZSBkZWZpbmVkIFJ0cFN0cmVhbUlkcyBhbmQgdGhl aXIgcGFyYW1ldGVycyBuZWVkIHRvIGNvdmVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDth bGwgdGhlIG1lZGlhIHNvdXJjZXMgYW5kIHNpbXVsY2FzdCBzdHJlYW1zIHRoYXQgY2FuIGJlIHN3 aXRjaGVkPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi PmludG88L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj4mbmJzcDsmbmJzcDsmbmJzcDt0aGlzIG1lZGlhIHNvdXJj ZS48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhlIGFib3ZlIHBh cmFncmFwaCB3aGF0IGRvZXMg4oCcdGhpcyBzY2VuYXJpb+KAnSByZWZlciB0bz8gSXMgaXQgdGhl IHNjZW5hcmlvIG9mIHVzaW5nIG1lZGlhJm5ic3A7c291cmNl4oCZcyBydHAgc3RyZWFtIFNTUkMg aW4gdGhlIENTUkMgb2YgdGhlIHJ0cCBtaXhlcuKAmXMgcnRwIHN0cmVhbSAob3IpIGlzIGl0IHJl ZmVycmluZyB0byDigJxSVFAgTWl4ZXIgLSBSZWNlaXZlcuKAnSBzY2VuYXJpb3MgaW4gZ2VuZXJh bD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+W0JvQl0g4oCcVGhpcyBzY2VuYXJpb+KAnSBtZWFucyB0byBy ZWZlciB0byB0aGlzIHNlY3Rpb24gKDcuMi4xKS4gV2lsbCBjbGFyaWZ5Ljwvc3Bhbj48L2k+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Eb2VzIOKAnHRoaXMgbGVn4oCZcyBzaWduYWxp bmcgY29udGV4dOKAnSByZWZlciB0byB0aGUg4oCcUlRQIG1peGVyIC0gUmVjZWl2ZXLigJ0gY2Fs bCBsZWc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltCb0JdIE5vdCBuZWNlc3NhcmlseSBqdXN0IFJUUCBz dHJlYW0gcmVjZWl2ZXIsIGl0IGNvdWxkIGFsc28gYmUgUlRQIHN0cmVhbSBzZW5kZXIsIG90aGVy d2lzZSB5ZXMuIEl0IGlzIHRoZSBjb250ZXh0IG9mIGEgc2luZ2xlIFNEUCBvZmZlci9hbnN3ZXIg YmV0d2VlbiB0d28gcGFydGljaXBhbnRzDQogKFJUUCBtaXhlciBhbmQgd2hhdGV2ZXIgZW5kcG9p bnQgaXMgdGhlIGNvdW50ZXJwYXJ0IOKAkyBwb3NzaWJseSBldmVuIGFub3RoZXIgUlRQIG1peGVy KS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHNlbnRlbmNl IOKAnEluIGFkZGl0aW9uLCB0aGUgZGVmaW5lZCBSdHBTdHJlYW1JZHPigKYudGhhdCBjYW4gYmUg c3dpdGNoZWQgaW50byB0aGlzIG1lZGlhIHNvdXJjZSZxdW90OyBpcyBub3QgY2xlYXIgdG8gbWUu IFNwZWNpZmljYWxseSB3aHkgd291bGQgd2Ugc3dpdGNoaW5nIGFuIFJUUCBzdHJlYW08c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+aW50bzwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+YQ0KIG1lZGlhIHNv dXJjZS4gV2FzIGl0IGludGVuZGVkIHRvIGJlIOKAnHN3aXRjaGVkIGZyb20gdGhpcyBtZWRpYSBz b3VyY2XigJ0gb3Ig4oCcc3dpdGNoZWQgdG8gYSBSVFAgcmVjZWl2ZXLigJ0/IFBsZWFzZSBleHBs YWluLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5bQm9CXSBUaGUgUlRQIG1peGVyIHJlY2VpdmVzIChwb3Rl bnRpYWxseSBzaW11bGNhc3QpIFJUUCBzdHJlYW1zIGZyb20gb3JpZ2luYXRpbmcgbWVkaWEgc291 cmNlcyBhbmQgc3dpdGNoZXMgdGhvc2UgUlRQIHBhY2tldHMgaW50ZXJuYWxseSB0byBwcm92aWRl IGRhdGEgZm9yIHRoZSBSVFANCiBtaXhlcuKAmXMgb3duIG1lZGlhIHNvdXJjZXMgYW5kIFJUUCBz dHJlYW1zLCBhcyBzZWVuIGJ5IHRoZSBmaW5hbCByZWNlaXZlciBvZiB0aGUgUlRQIHN0cmVhbXMg ZnJvbSB0aGUgUlRQIG1peGVyLiBXaGF0IGFib3V0IHJlLWZvcm11bGF0aW5nIHRvIOKAnEluIGFk ZGl0aW9uLCB0aGUgZGVmaW5lZCBSdHBTdHJlYW1JZHMgYW5kIHRoZWlyIHBhcmFtZXRlcnMgbmVl ZCB0byBjb3ZlciBhbGwgdGhlIG1lZGlhIHNvdXJjZXMgYW5kIHNpbXVsY2FzdCBzdHJlYW1zPHNw YW4gc3R5bGU9ImNvbG9yOnJlZCI+cmVjZWl2ZWQNCiBieSB0aGUgUlRQIG1peGVyPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj50aGF0IGNhbiBi ZSBzd2l0Y2hlZCBpbnRvIHRoaXMgbWVkaWEgc291cmNlPHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+ LCBzZW50IGJ5IHRoZSBSVFAgbWl4ZXI8L3NwYW4+4oCdPzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcyEgdGhpcyBnaXZlcyBtb3Jl IGNsYXJpdHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFydW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTWFyIDMwLCAyMDE3LCBhdCA1OjQyIFBNLCBBcnVuIEFy dW5hY2hhbGFtIChjYXJ1bmFjaCkgJmx0OzxhIGhyZWY9Im1haWx0bzpjYXJ1bmFjaEBjaXNjby5j b20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmNhcnVuYWNoQGNpc2NvLmNvbTwvc3Bhbj48 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBGbGVtbWluZyw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpbiBhYm91dCBhIHdlZWsgaS5lIGJ5IEVP QiA0LzcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5BcnVuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIE1hciAzMCwgMjAxNywgYXQgNDozMyBQTSwgRmxl bW1pbmcgQW5kcmVhc2VuIChmYW5kcmVhcykgJmx0OzxhIGhyZWY9Im1haWx0bzpmYW5kcmVhc0Bj aXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmZhbmRyZWFzQGNpc2NvLmNvbTwv c3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGFua3MgQXJ1 biAtIHdoZW4gZG8geW91IHRoaW5rIHlvdSB3aWxsIGhhdmUgdGhlIHJldmlldyByZWFkeSA/PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4N Ci0tIEZsZW1taW5nPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biAzLzMwLzE3IDQ6MzAgUE0sIEFydW4gQXJ1bmFjaGFsYW0gKGNhcnVuYWNoKSB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBGbGVtbWluZyw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBkaXNjdXNzZWQsIGkgd291bGQgYmUgZ2xhZCB0 byByZXZpZXcmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3QiPjxzcGFuIHN0eWxlPSJjb2xvcjpw dXJwbGUiPmRyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3Q8L3NwYW4+PC9hPiZuYnNwO2Ry YWZ0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MhPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcnVuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4uPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AM5PR0701MB25776AF092A7D09EFEABB2858DEE0AM5PR0701MB2577_-- From nobody Mon May 8 01:44:13 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B068F129405; Mon, 8 May 2017 01:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 b-SjjsuKx-VJ; Mon, 8 May 2017 01:44:07 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7374F127B5A; Mon, 8 May 2017 01:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=99354; q=dns/txt; s=iport; t=1494233047; x=1495442647; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6hLzBGj2OJ3xa9PRQ0ODHxMk99gwREInqe0jEW16I1I=; b=FjcbWG1ysjvYlqYdb+9K59FyeKJH7opuiD3/nck+RHK+KMoikn37E8V6 tz3xoS2M4r0aWZa9bFtUlkN419jV7e0yjfdfqvlkkCklfHipZDy0c8cjL Q8NCmgXzbzx41HUoyNCv76OOI8m8WnVyLXC97Mj7bZzecL8gm1X23g5XA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BZAQDqLhBZ/5xdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm48K2KBDAeDG0aKGJE1IXKVAIIPLoV2AhqENT8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQEDDBdWEAIBBgIRBAEBIQEGAwICAjAUCQgCBA4FiiAOk1GdYYImi?= =?us-ascii?q?mABAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYg9KwuBWVg0hRmCVC6CMQWWZocTAYc?= =?us-ascii?q?bi3yCBIU8iiyUPQEfOIEKcBUcPAGEYRyBYgF2AQGGLAaBKoENAQEB?= X-IronPort-AV: E=Sophos;i="5.38,308,1491264000"; d="scan'208,217";a="423225320" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 May 2017 08:44:05 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v488i5gm024135 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 May 2017 08:44:05 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 8 May 2017 03:44:05 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Mon, 8 May 2017 03:44:05 -0500 From: "Arun Arunachalam (carunach)" To: Bo Burman CC: "mmusic (mmusic@ietf.org)" , "Flemming Andreasen (fandreas)" , "draft-ietf-mmusic-sdp-simulcast.authors@ietf.org" , "Arun Arunachalam (carunach)" Thread-Topic: Review: draft-ietf-mmusic-sdp-simulcast Thread-Index: AQHSqZR3U62wxX4n/EeUgd2ei06G2aGuOwmAgAABOwCADwZQgIAmDtaAgAZaogCAAPEXgIAAEgEA Date: Mon, 8 May 2017 08:44:05 +0000 Message-ID: <25CE0091-72AC-4751-A18E-2808B89F7A56@cisco.com> References: <6351CDC7-7925-4448-A39E-56FCC9F2B12C@cisco.com> <991504f1-bb9c-17c7-432f-a53154d2da33@cisco.com> <344988B5-DEF9-41A4-BC15-7D8E07A22448@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.58.69] Content-Type: multipart/alternative; boundary="_000_25CE009172AC4751A18E2808B89F7A56ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] Review: draft-ietf-mmusic-sdp-simulcast X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 08:44:12 -0000 --_000_25CE009172AC4751A18E2808B89F7A56ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQm8sDQoNClRoZSBtaW5vciBjaGFuZ2UgaW4gU2VjdGlvbiA2LjMuMiBsb29rcyBnb29kLg0K DQpUaGFua3MhDQpBcnVuDQoNCk9uIE1heSA4LCAyMDE3LCBhdCAzOjM5IEFNLCBCbyBCdXJtYW4g PGJvLmJ1cm1hbkBlcmljc3Nvbi5jb208bWFpbHRvOmJvLmJ1cm1hbkBlcmljc3Nvbi5jb20+PiB3 cm90ZToNCg0KT0ssIHRoYW5rcyEgV2lsbCBtYWtlIGNvcnJlc3BvbmRpbmcgdXBkYXRlcyBpbiBu ZXh0IHZlcnNpb24hIFNlZSBhbHNvIGEgZmV3IGNvbW1lbnRzIGlubGluZSBiZWxvdy4NCi9Cbw0K DQpGcm9tOiBBcnVuIEFydW5hY2hhbGFtIChjYXJ1bmFjaCkgW21haWx0bzpjYXJ1bmFjaEBjaXNj by5jb21dDQpTZW50OiBkZW4gNyBtYWogMjAxNyAxOToxNw0KVG86IEJvIEJ1cm1hbiA8Ym8uYnVy bWFuQGVyaWNzc29uLmNvbTxtYWlsdG86Ym8uYnVybWFuQGVyaWNzc29uLmNvbT4+DQpDYzogbW11 c2ljIChtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4pIDxtbXVzaWNAaWV0 Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+OyBGbGVtbWluZyBBbmRyZWFzZW4gKGZhbmRy ZWFzKSA8ZmFuZHJlYXNAY2lzY28uY29tPG1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20+PjsgZHJh ZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC5hdXRob3JzQGlldGYub3JnPG1haWx0bzpkcmFm dC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LmF1dGhvcnNAaWV0Zi5vcmc+OyBBcnVuIEFydW5h Y2hhbGFtIChjYXJ1bmFjaCkgPGNhcnVuYWNoQGNpc2NvLmNvbTxtYWlsdG86Y2FydW5hY2hAY2lz Y28uY29tPj4NClN1YmplY3Q6IFJlOiBSZXZpZXc6IGRyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11 bGNhc3QNCg0KVGhhbmtzIEJvICENCg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNCk9uIE1heSAzLCAy MDE3LCBhdCAxMjoxNCBQTSwgQm8gQnVybWFuIDxiby5idXJtYW5AZXJpY3Nzb24uY29tPG1haWx0 bzpiby5idXJtYW5AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCkhpIEFydW4sDQoNClRoYW5rIHlv dSBmb3IgdGhlIGNvbW1lbnRzISBQbGVhc2Ugc2VlIG15IHJlc3BvbnNlcyBpbmxpbmUgYmVsb3cu DQoNCkNoZWVycywNCi9Cbw0KDQpGcm9tOiBBcnVuIEFydW5hY2hhbGFtIChjYXJ1bmFjaCkgW21h aWx0bzpjYXJ1bmFjaEBjaXNjby5jb21dDQpTZW50OiBkZW4gOSBhcHJpbCAyMDE3IDEzOjA0DQpU bzogQm8gQnVybWFuIDxiby5idXJtYW5AZXJpY3Nzb24uY29tPG1haWx0bzpiby5idXJtYW5AZXJp Y3Nzb24uY29tPj4NCkNjOiBGbGVtbWluZyBBbmRyZWFzZW4gKGZhbmRyZWFzKSA8ZmFuZHJlYXNA Y2lzY28uY29tPG1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20+PjsgQXJ1biBBcnVuYWNoYWxhbSAo Y2FydW5hY2gpIDxjYXJ1bmFjaEBjaXNjby5jb208bWFpbHRvOmNhcnVuYWNoQGNpc2NvLmNvbT4+ DQpTdWJqZWN0OiBSZTogUmV2aWV3OiBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0DQoN CkhpIEJvLA0KDQpSZXZpZXdlZCB0aGUgZHJhZnQgYW5kIGhhdmUgYSBmZXcgY29tbWVudHMgYW5k IHF1ZXN0aW9ucyAoc2hvd24gYmVsb3cpLg0KDQpUaGFua3MhDQpBcnVuDQoNCkNvbW1lbnRzIC8g UXVlc3Rpb25zOg0KDQooMSkgU2VjdGlvbiAxPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3NlY3Rpb24tMT4NCg0KICAgdHJhbnNw b3J0IG92ZXIgUlRQLiAgVGhlIG1lZGlhIHRyYW5zcG9ydCB0b3BvbG9naWVzIGNvbnNpZGVyZWQg YXJlDQogICBwb2ludCB0byBwb2ludCBSVFAgc2Vzc2lvbnMgYXMgd2VsbCBhcyBjZW50cmFsaXpl ZCBtdWx0aS1wYXJ0eSBSVFANCiAgIHNlc3Npb25zLCB3aGVyZSBhIG1lZGlhIHNlbmRlciB3aWxs IHByb3ZpZGUgdGhlIHNpbXVsY2FzdGVkIHN0cmVhbXMNCiAgIHRvIGFuIFJUUCBtaWRkbGVib3gg b3IgZW5kcG9pbnQsIGFuZCBtaWRkbGVib3hlcyBtYXkgZnVydGhlcg0KICAgZGlzdHJpYnV0ZSB0 aGUgc2ltdWxjYXN0IHN0cmVhbXMgdG8gb3RoZXIgbWlkZGxlYm94ZXMgb3IgZW5kcG9pbnRzLg0K DQpTZXZlcmFsIHBsYWNlcyBpbiB0aGUgZG9jIHVzZSB0aGUgdGVybSDigJxSVFAgU2Vzc2lvbuKA nSBhbmQg4oCcUlRQIHN0cmVhbXPigJ0gaGVuY2UgaXQgd291bGQgYmUgdXNlZnVsIHRvIHByb3Zp ZGUgYSByZWZlcmVuY2Ugc28gdGhhdCByZWFkZXJzIGNhbiBrbm93IHRoZSBkaWZmZXJlbmNlLg0K DQpSVFAgU2Vzc2lvbiDigJQ+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNTUwI3Nl Y3Rpb24tMS4xDQpbQm9CXSBBcyBzYWlkIGF0IHRoZSBzdGFydCBvZiBzZWN0aW9uIDIuMSDigJxU ZXJtaW5vbG9neeKAnSwgdGhlIGRyYWZ0IGdlbmVyYWxseSB1c2VzIHRlcm1zIGZyb20gUlRQIFRh eG9ub215IChSRkMgNzY1NikuIEJvdGggUlRQIHN0cmVhbSBhbmQgUlRQIHNlc3Npb24gYXJlIHRl cm1zIGRlc2NyaWJlZCB0aGVyZS4gUlRQIHNlc3Npb24gaXMsIGFzIHlvdSBzYXksIGFsc28gZGVm aW5lZCBieSBSRlJDIDM1NTAsIGJ1dCB0aGVyZSBoYXMgYmVlbiBzaWduaWZpY2FudCBjb25mdXNp b24gYXJvdW5kIHdoYXQgdGhlIHRlcm0gcmVhbGx5IG1lYW5zLCBzbyBhZGRpdGlvbmFsIGNsYXJp ZmljYXRpb24gd2FzIGFkZGVkIGluIFJGQyA3NjU2LiBJIGhhdmUgbm8gcHJvYmxlbSBhZGRpbmcg dGhlbSBhcyBleHBsaWNpdCB0ZXJtcyBpbiBzZWN0aW9uIDIuMSwgYnV0IHdpbGwgdGhlbiBtb3Jl IG9yIGxlc3MganVzdCByZWZlcmVuY2UgUkZDIDM1NTAgYW5kIFJGQyA3NjU2IGZyb20gdGhlcmUu DQoNCkdvb2QuIFRoZSByZWZlcmVuY2UgaW4gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24gc2hvdWxk IGJlIHN1ZmZpY2llbnQuDQoNCg0KDQoNCg0KKDIpIFNlY3Rpb24gMy4xPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3NlY3Rpb24t My4xPg0KDQoNCiAgIEJpdHJhdGU6ICBUaGlzIHJlbGF0ZXMgdG8gdGhlIGFtb3VudCBvZiBiaXRz IHNwZW50IHBlciBzZWNvbmQgdG8NCg0KICAgICAgdHJhbnNtaXQgdGhlIG1lZGlhIHNvdXJjZSBh cyBhbiBSVFAgc3RyZWFtLCB3aGljaCB0eXBpY2FsbHkgYWxzbw0KDQogICAgICBhZmZlY3RzIHRo ZSBRdWFsaXR5IG9mIEV4cGVyaWVuY2UgKFFvRSkgZm9yIHRoZSByZWNlaXZpbmcgdXNlci4NCg0K DQpJIHRoaW5rIHRoZSBhdXRob3JzIG1heSBoYXZlIGludGVuZGVkIHRvIHVzZSDigJxzZW504oCd IGluc3RlYWQgb2Yg4oCcc3BlbnQiLg0KW0JvQl0gSSB0aGluayBhIHNlbmRlciBjYW4g4oCcc3Bl bmTigJ0gYml0cyBpdCDigJxoYXMgYXZhaWxhYmxl4oCdIHRvIHNlbmQsIGJ1dCBJIGFncmVlIHRo YXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGNoYW5nZSB0byDigJxzZW504oCdLg0KDQooMykgU2Vj dGlvbiA2LjE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNk cC1zaW11bGNhc3QtMDgjc2VjdGlvbi02LjE+DQoNCiAgIGRpcmVjdGlvbmFsaXR5IGlzIHJldmVy c2VkLiAgVGhpcyBleGFtcGxlIGFuc3dlciBoYXMgcmVtb3ZlZCBhbGwNCiAgIG9mZmVyZWQgYWx0 ZXJuYXRpdmUgZm9ybWF0cyBmb3IgdGhlIGZpcnN0IHNpbXVsY2FzdCBzdHJlYW0gKGtlZXBpbmcN CiAgIG9ubHkgU0NJRCAxKSwgYnV0IGtlcHQgYWx0ZXJuYXRpdmUgZm9ybWF0cyBmb3IgdGhlIHNl Y29uZCBzaW11bGNhc3QNCiAgIHN0cmVhbSBpbiByZWNlaXZlIGRpcmVjdGlvbiAoNCwgNSkuICBU aGUgYW5zd2VyIHRodXMgYWNjZXB0cyB0byBzZW5kDQogICB0d28gc2ltdWxjYXN0IHN0cmVhbXMs IHdpdGhvdXQgYWx0ZXJuYXRpdmVzLiAgVGhlIGFuc3dlciBkb2VzIG5vdA0KICAgYWNjZXB0IGlu aXRpYWwgcGF1c2Ugb2YgYW55IHNpbXVsY2FzdCBzdHJlYW1zLCBpbiBlaXRoZXIgZGlyZWN0aW9u Lg0KICAgTW9yZSBleGFtcGxlcyBjYW4gYmUgZm91bmQgaW4gU2VjdGlvbiA2LjYuDQoNClBsZWFz ZSByZW1vdmUgdGhlIHdvcmQg4oCcdGh1c+KAnSBzaW5jZSB0aGVyZSBpcyBubyByZWFzb24gcHJv dmlkZWQgcHJpb3IgdG8gdGhpcyBzZW50ZW5jZS4NCltCb0JdIE9LLg0KDQoNCig0KSBTZWN0aW9u IDYuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNp bXVsY2FzdC0wOCNzZWN0aW9uLTYuMj4NCg0KICAgaW5zdGVhZCBvZiBtYWtpbmcgaXQgZXF1aXZh bGVudCB0byBpbXBsaWNpdGx5IHNlbmRpbmcgYSBwYXVzZQ0KICAgcmVxdWVzdCwgaXMgYmVjYXVz ZSB0aGUgcGF1c2luZyBSVFAgc2VuZGVyIGNhbm5vdCBrbm93IHdoaWNoDQogICByZWNlaXZpbmcg U1NSQyBvd25zIHRoZSByZXN0cmljdGlvbiB3aGVuIFRNTUJSL1RNTUJOIGFyZSB1c2VkIGZvcg0K ICAgcGF1c2UvcmVzdW1lIHNpZ25hbGluZyBzaW5jZSB0aGUgUlRQIHJlY2VpdmVyJ3MgU1NSQyBp biBzZW5kDQogICBkaXJlY3Rpb24gaXMgc29tZXRpbWVzIG5vdCB5ZXQga25vd24uDQoNCkl0IHdv dWxkIGJlIGdvb2QgdG8gYSBnaXZlIHJlZmVyZW5jZSBmb3IgVE1NQlIvVE1NQk4gcG9pbnRpbmcg dG8gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc3Mjgjc2VjdGlvbi0yLjEgb3IgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc3Mjgjc2VjdGlvbi01LjYuDQpbQm9CXSBPSy4g UHJlZmVyIHNlY3Rpb24gNS42IG9mIFJGQyA3NzI4LiBIb3dldmVyLCB0aGUgZHJhZnQgc291cmNl IGlzIFhNTCBhbmQgSSBkb27igJl0IHRoaW5rIHhtbDJyZmMgPHhyZWY+IHN1cHBvcnRzIHJlZmVy ZW5jaW5nIGEgcGFydGljdWxhciBzZWN0aW9uLCBzbyBJ4oCZbSBub3Qgc3VyZSBob3cgdG8gYWNo aWV2ZSB0aGF0Lg0KDQoNCkkgdGhpbmsgd2UgY2FuIHVzZSAiU2VjdGlvbiA1LjYgb2YgPHhyZWYg dGFyZ2V0PSJSRkM3NzI44oCdLz7igJ0gaW4gdGhlIFhNTCB2ZXJzaW9uIG9mIHRoZSBkb2MuDQoN ClJlZmVyZW5jZTogaHR0cHM6Ly94bWwycmZjLnRvb2xzLmlldGYub3JnL3htbDJyZmNGQVEuaHRt bCNhbmNob3IxOA0KDQpXb3JraW5nIGV4YW1wbGU6DQoNClhNTDoNCg0KPHNlY3Rpb24gdGl0bGU9 IkludGVybWVkaWFyeSI+DQo8dD5UaGUgdGVybSAiaW50ZXJtZWRpYXJ5IiBpcyBkZWZpbmVkIGlu IFNlY3Rpb24gMiBvZiA8eHJlZiB0YXJnZXQ9IlJGQzc5ODkiLz47IGl0IHJlZmVycyB0byBhbnkg ZW50aXR5IGFsb25nIHRoZSBjYWxsIHNpZ25hbGluZyBwYXRoLjwvdD4NCjwvc2VjdGlvbj4NCg0K UkZDOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxMjMjc2VjdGlvbi0zLjMNCltC b0JdIE9LLCB0aGF0IHdvcmtzDQoNCg0KDQoNCig1KSBTZWN0aW9uIDYuMy4yPGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3NlY3Rp b24tNi4zLjI+DQoNCiAgIEFuIGFuc3dlcmVyIHRoYXQgcmVjZWl2ZXMgaW5kaWNhdGlvbiBpbiBh biBvZmZlciBvZiBhbiBTQ0lEIGJlaW5nDQogICBpbml0aWFsbHkgcGF1c2VkIFNIT1VMRCBtYXJr IHRoYXQgU0NJRCBhcyBpbml0aWFsbHkgcGF1c2VkIGFsc28gaW4NCiAgIHRoZSBhbnN3ZXIsIHJl Z2FyZGxlc3Mgb2YgZGlyZWN0aW9uLCB1bmxlc3MgaXQgaGFzIGdvb2QgcmVhc29uIGZvcg0KICAg dGhlIFNDSUQgbm90IGJlaW5nIGluaXRpYWxseSBwYXVzZWQuICBPbmUgc3VjaCByZWFzb24gY291 bGQsIGZvcg0KICAgZXhhbXBsZSwgYmUgdGhhdCB0aGUgYW5zd2VyZXIgd291bGQgb3RoZXJ3aXNl IGluaXRpYWxseSBub3QgcmVjZWl2ZQ0KICAgYW55IG1lZGlhIG9mIHRoYXQgdHlwZSBhdCBhbGwu DQoNClRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLiBDYW4geW91IHBsZWFzZSBleHBs YWluIGEgc2NlbmFyaW8gaW4gd2hpY2ggdGhlIGV4YW1wbGUgYXBwbGllcz8NCltCb0JdIFNheSB0 aGF0IHlvdSBoYXZlIGEgc2ltdWxjYXN0IHdpdGggc2V2ZXJhbCBkaWZmZXJlbnQgbWVkaWEgcXVh bGl0eSBsZXZlbHMgYmVpbmcgb2ZmZXJlZC4gVGhlIG9mZmVyZXIgZXhwZWN0cyBtb3N0IHJlY2Vp dmVycyB0byBhY2NlcHQgdGhlIGhpZ2hlc3QgcXVhbGl0eSBsZXZlbCwgYW5kIHRoYXQgdGhleSBh cmUgdGhlbiB1bmludGVyZXN0ZWQgdG8gcmVjZWl2ZSB0aGUgbG93ZXIgcXVhbGl0eSBsZXZlbHMu IFRoZSBvZmZlcmVyIGhhcyB0aGVyZWZvcmUgc2V0IHRoZSBsb3dlciBxdWFsaXR5IHNpbXVsY2Fz dCBzdHJlYW1zIHRvIGluaXRpYWxseSBwYXVzZWQuIEZ1cnRoZXIgYXNzdW1lIGEgc29tZXdoYXQg cmVzdHJpY3RlZCBhbnN3ZXJlciB0aGF0IGNhbm5vdCBjb3BlIHdpdGggdGhlIGhpZ2hlc3QgcXVh bGl0eSBsZXZlbC4gSXQgdGhlcmVmb3JlIHdhbnRzIHRvIGFjY2VwdCBhIGxvd2VyIHF1YWxpdHkg bGV2ZWwgc2ltdWxjYXN0IHN0cmVhbSBhbmQgd291bGQgbm90IHJlY2VpdmUgYW55dGhpbmcgYXQg dGhlIGJlZ2lubmluZyBvZiB0aGUgc2Vzc2lvbiAodW50aWwgaXNzdWluZyBhbiBSRkMgNzcyOCBS RVNVTUUpIGlmIGl0IGFjY2VwdHMgdGhpcyBsb3dlciBxdWFsaXR5IHNpbXVsY2FzdCBzdHJlYW0g YXMgaW5pdGlhbGx5IHBhdXNlZC4gV2l0aG91dCBpbmNsdWRpbmcgc3VjaCBmYWlybHkgZXh0ZW5z aXZlIGV4YW1wbGUgdGV4dCwgSSBkb27igJl0IGtub3cgaG93IHRvIGJlc3QgbWFrZSBhIGNsYXJp ZmljYXRpb24uIERvIHlvdSBoYXZlIGEgcHJvcG9zYWw/DQoNCkdvdCBpdC4gTmljZSBleGFtcGxl Lg0KDQpIb3cgYWJvdXQgZm9sbG93aW5nOg0KDQogICBPbmUgc3VjaCByZWFzb24gY291bGQsIGZv ciBleGFtcGxlLCBiZSB0aGF0IHRoZSBhbnN3ZXJlciBkb2VzbuKAmXQgaGF2ZSB0aGUgYWJpbGl0 eSB0bw0KICAgcHJvY2VzcyBhbnkgdW5wYXVzZWQgc2ltdWxjYXN0IHN0cmVhbXMgb2ZmZXJlZCBm b3IgYSBnaXZlbiBtZWRpYSBzb3VyY2UuIEl0IGNob29zZXMNCiAgIG9uZSBvZiB0aGUgcGF1c2Vk IHNpbXVsY2FzdCBzdHJlYW0gaW4gdGhlIG9mZmVyIGFuZCBtYXJrcyBpdCBhcyBub3QgcGF1c2Vk IGluIHRoZSBhbnN3ZXIuDQoNCltCb0JdIE9LLCBidXQgc3VnZ2VzdCBtaW5vciB3b3JkaW5nIGNo YW5nZSB0byBrZWVwIGl0IGVudGlyZWx5IGNsZWFyIHRoYXQgdGhlIHNjb3BlIGlzIFNEUCBhbmQg aW5pdGlhbGx5IHBhdXNlZCBzdHJlYW1zOg0KT25lIHN1Y2ggcmVhc29uIGNvdWxkLCBmb3IgZXhh bXBsZSwgYmUgdGhhdCB0aGUgYW5zd2VyZXIgZG9lc24ndCBoYXZlIHRoZSBhYmlsaXR5IHRvIHBy b2Nlc3MgYW55IGluaXRpYWxseSB1bnBhdXNlZCBzaW11bGNhc3Qgc3RyZWFtcyBvZmZlcmVkIGZv ciBhIGdpdmVuIG1lZGlhIHNvdXJjZS4gSXQgdGhlbiBjaG9vc2VzIG9uZSBvZiB0aGUgaW5pdGlh bGx5IHBhdXNlZCBzaW11bGNhc3Qgc3RyZWFtcyBpbiB0aGUgb2ZmZXIgYW5kIG1hcmtzIGl0IGFz IG5vdCBwYXVzZWQgaW4gdGhlIGFuc3dlci4NCg0KDQoNCg0KDQooNikgU2VjdGlvbiA3LjIuMTxo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2Fz dC0wOCNzZWN0aW9uLTcuMi4xPg0KDQogICBUaGlzIHdpbGwgcmVzdWx0IGluIGEgc2luZ2xlIFJU UCBzdHJlYW0gYmVpbmcgdXNlZCBmb3IgYSBwYXJ0aWN1bGFyDQogICBvZiB0aGUgUlRQIG1peGVy 4oCZcyBtZWRpYSBzb3VyY2VzLg0KDQoNClRoaXMgc2VudGVuY2Ugc2VlbXMgdG8gYmUgbWlzc2lu ZyBhIHdvcmQgLSDigJzigKZ0b3IgYSBwYXJ0aWN1bGFyIF9fX19fX18gb2YgdGhlIFJUUCBtaXhl cuKAmXPigKYu4oCdDQpbQm9CXSBXaGF0IGFib3V0IHJlcGxhY2luZyDigJxhIHBhcnRpY3VsYXIg b2bigJ0gd2l0aCDigJxlYWNoIG9uZSBvZuKAnT8NCg0KV2UgY2FuIHVzZSDigJxlYWNoIG9m4oCd Og0KDQogICBUaGlzIHdpbGwgcmVzdWx0IGluIGEgc2luZ2xlIFJUUCBzdHJlYW0gYmVpbmcgdXNl ZCBmb3IgZWFjaA0KICAgb2YgdGhlIFJUUCBtaXhlcidzIG1lZGlhIHNvdXJjZXMuDQoNCltCb0Jd IE9LDQoNCg0KDQoNCig3KSBTZWN0aW9uIDcuMi4xPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3NlY3Rpb24tNy4yLjE+DQoNCiAg ICBUaGlzIGFzIHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIHNpZ25hbGxpbmcgYmV0d2VlbiB0aGUg bWl4ZXIgYW5kIHRoZSByZWNlaXZlciB0aGF0IGlzIHN0cnVjdHVyZWQgYXJvdW5kIHRoZSBvcmln aW5hdGluZyBtZWRpYSBzb3VyY2VzLCBvbmx5IHRoZSBtaXhlcuKAmXMgbWVkaWEgc291cmNlcy4N Cg0KIEkgdGhpbmsg4oCcVGhpcyBhc+KAnSBuZWVkcyB0byBiZSBjaGFuZ2VkIHRvIOKAnFRoYXQg aXPigJ0uDQpbQm9CXSBPSy4gSSBhc3N1bWUg4oCcVGhhdCBpcywg4oCcICh3aXRoIGEgY29tbWEp Pw0KDQoNCg0KWWVzLg0KDQoNCg0KKDgpIFNlY3Rpb24gNy4yLjE8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3QtMDgjc2VjdGlvbi03LjIu MT4NCg0KICAgSWYgUnRwU3RyZWFtSWRzIGFyZSB1c2VkIGluIHRoaXMgc2NlbmFyaW8sIGl0IHNo b3VsZCBiZSBub3RlZCB0aGF0DQogICB0aGUgUnRwU3RyZWFtSWQgb24gYSBwYXJ0aWN1bGFyIFNT UkMgd2lsbCBjaGFuZ2UgYmFzZWQgb24gdGhlIGFjdHVhbA0KICAgc2ltdWxjYXN0IHN0cmVhbSBz ZWxlY3RlZCBmb3Igc3dpdGNoaW5nLiAgVGhlc2UgUnRwU3RyZWFtSWQNCiAgIGlkZW50aWZpZXJz IHdpbGwgYmUgbG9jYWwgdG8gdGhpcyBsZWfigJlzIHNpZ25hbGxpbmcgY29udGV4dC4gIEluDQog ICBhZGRpdGlvbiwgdGhlIGRlZmluZWQgUnRwU3RyZWFtSWRzIGFuZCB0aGVpciBwYXJhbWV0ZXJz IG5lZWQgdG8gY292ZXINCiAgIGFsbCB0aGUgbWVkaWEgc291cmNlcyBhbmQgc2ltdWxjYXN0IHN0 cmVhbXMgdGhhdCBjYW4gYmUgc3dpdGNoZWQgaW50bw0KICAgdGhpcyBtZWRpYSBzb3VyY2UuDQoN CkluIHRoZSBhYm92ZSBwYXJhZ3JhcGggd2hhdCBkb2VzIOKAnHRoaXMgc2NlbmFyaW/igJ0gcmVm ZXIgdG8/IElzIGl0IHRoZSBzY2VuYXJpbyBvZiB1c2luZyBtZWRpYSBzb3VyY2XigJlzIHJ0cCBz dHJlYW0gU1NSQyBpbiB0aGUgQ1NSQyBvZiB0aGUgcnRwIG1peGVy4oCZcyBydHAgc3RyZWFtIChv cikgaXMgaXQgcmVmZXJyaW5nIHRvIOKAnFJUUCBNaXhlciAtIFJlY2VpdmVy4oCdIHNjZW5hcmlv cyBpbiBnZW5lcmFsPw0KW0JvQl0g4oCcVGhpcyBzY2VuYXJpb+KAnSBtZWFucyB0byByZWZlciB0 byB0aGlzIHNlY3Rpb24gKDcuMi4xKS4gV2lsbCBjbGFyaWZ5Lg0KDQpEb2VzIOKAnHRoaXMgbGVn 4oCZcyBzaWduYWxpbmcgY29udGV4dOKAnSByZWZlciB0byB0aGUg4oCcUlRQIG1peGVyIC0gUmVj ZWl2ZXLigJ0gY2FsbCBsZWc/DQpbQm9CXSBOb3QgbmVjZXNzYXJpbHkganVzdCBSVFAgc3RyZWFt IHJlY2VpdmVyLCBpdCBjb3VsZCBhbHNvIGJlIFJUUCBzdHJlYW0gc2VuZGVyLCBvdGhlcndpc2Ug eWVzLiBJdCBpcyB0aGUgY29udGV4dCBvZiBhIHNpbmdsZSBTRFAgb2ZmZXIvYW5zd2VyIGJldHdl ZW4gdHdvIHBhcnRpY2lwYW50cyAoUlRQIG1peGVyIGFuZCB3aGF0ZXZlciBlbmRwb2ludCBpcyB0 aGUgY291bnRlcnBhcnQg4oCTIHBvc3NpYmx5IGV2ZW4gYW5vdGhlciBSVFAgbWl4ZXIpLg0KDQpU aGUgc2VudGVuY2Ug4oCcSW4gYWRkaXRpb24sIHRoZSBkZWZpbmVkIFJ0cFN0cmVhbUlkc+KApi50 aGF0IGNhbiBiZSBzd2l0Y2hlZCBpbnRvIHRoaXMgbWVkaWEgc291cmNlIiBpcyBub3QgY2xlYXIg dG8gbWUuIFNwZWNpZmljYWxseSB3aHkgd291bGQgd2Ugc3dpdGNoaW5nIGFuIFJUUCBzdHJlYW0g aW50byBhIG1lZGlhIHNvdXJjZS4gV2FzIGl0IGludGVuZGVkIHRvIGJlIOKAnHN3aXRjaGVkIGZy b20gdGhpcyBtZWRpYSBzb3VyY2XigJ0gb3Ig4oCcc3dpdGNoZWQgdG8gYSBSVFAgcmVjZWl2ZXLi gJ0/IFBsZWFzZSBleHBsYWluLg0KW0JvQl0gVGhlIFJUUCBtaXhlciByZWNlaXZlcyAocG90ZW50 aWFsbHkgc2ltdWxjYXN0KSBSVFAgc3RyZWFtcyBmcm9tIG9yaWdpbmF0aW5nIG1lZGlhIHNvdXJj ZXMgYW5kIHN3aXRjaGVzIHRob3NlIFJUUCBwYWNrZXRzIGludGVybmFsbHkgdG8gcHJvdmlkZSBk YXRhIGZvciB0aGUgUlRQIG1peGVy4oCZcyBvd24gbWVkaWEgc291cmNlcyBhbmQgUlRQIHN0cmVh bXMsIGFzIHNlZW4gYnkgdGhlIGZpbmFsIHJlY2VpdmVyIG9mIHRoZSBSVFAgc3RyZWFtcyBmcm9t IHRoZSBSVFAgbWl4ZXIuIFdoYXQgYWJvdXQgcmUtZm9ybXVsYXRpbmcgdG8g4oCcSW4gYWRkaXRp b24sIHRoZSBkZWZpbmVkIFJ0cFN0cmVhbUlkcyBhbmQgdGhlaXIgcGFyYW1ldGVycyBuZWVkIHRv IGNvdmVyIGFsbCB0aGUgbWVkaWEgc291cmNlcyBhbmQgc2ltdWxjYXN0IHN0cmVhbXNyZWNlaXZl ZCBieSB0aGUgUlRQIG1peGVyIHRoYXQgY2FuIGJlIHN3aXRjaGVkIGludG8gdGhpcyBtZWRpYSBz b3VyY2UsIHNlbnQgYnkgdGhlIFJUUCBtaXhlcuKAnT8NCg0KWWVzISB0aGlzIGdpdmVzIG1vcmUg Y2xhcml0eS4NCg0KVGhhbmtzIQ0KQXJ1bg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9u IE1hciAzMCwgMjAxNywgYXQgNTo0MiBQTSwgQXJ1biBBcnVuYWNoYWxhbSAoY2FydW5hY2gpIDxj YXJ1bmFjaEBjaXNjby5jb208bWFpbHRvOmNhcnVuYWNoQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpI aSBGbGVtbWluZywNCg0KSSB0aGluayBpbiBhYm91dCBhIHdlZWsgaS5lIGJ5IEVPQiA0LzcuDQoN ClRoYW5rcyENCkFydW4NClNlbnQgZnJvbSBteSBpUGhvbmUNCg0KT24gTWFyIDMwLCAyMDE3LCBh dCA0OjMzIFBNLCBGbGVtbWluZyBBbmRyZWFzZW4gKGZhbmRyZWFzKSA8ZmFuZHJlYXNAY2lzY28u Y29tPG1haWx0bzpmYW5kcmVhc0BjaXNjby5jb20+PiB3cm90ZToNClRoYW5rcyBBcnVuIC0gd2hl biBkbyB5b3UgdGhpbmsgeW91IHdpbGwgaGF2ZSB0aGUgcmV2aWV3IHJlYWR5ID8NCg0KLS0gRmxl bW1pbmcNCk9uIDMvMzAvMTcgNDozMCBQTSwgQXJ1biBBcnVuYWNoYWxhbSAoY2FydW5hY2gpIHdy b3RlOg0KSGkgRmxlbW1pbmcsDQoNCkFzIGRpc2N1c3NlZCwgaSB3b3VsZCBiZSBnbGFkIHRvIHJl dmlldyBkcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0PGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdD4gZHJhZnQu DQoNClRoYW5rcyENCkFydW4NCg0KDQouDQoNCg0K --_000_25CE009172AC4751A18E2808B89F7A56ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5F88D86DF732E04BA49B1A36539A5AA6@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgQm8sDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgbWlub3IgY2hhbmdlIGlu IFNlY3Rpb24gNi4zLjIgbG9va3MgZ29vZC4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGFua3MhPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkFydW48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBNYXkg OCwgMjAxNywgYXQgMzozOSBBTSwgQm8gQnVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86Ym8uYnVy bWFuQGVyaWNzc29uLmNvbSIgY2xhc3M9IiI+Ym8uYnVybWFuQGVyaWNzc29uLmNvbTwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3Jk U2VjdGlvbjE7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+T0ssIHRoYW5rcyEgV2lsbCBtYWtlIGNvcnJl c3BvbmRpbmcgdXBkYXRlcyBpbiBuZXh0IHZlcnNpb24hIFNlZSBhbHNvIGEgZmV3IGNvbW1lbnRz IGlubGluZSBiZWxvdy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pi9CbzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PG86cCBjbGFz cz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6 IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogYmx1ZTsgYm9yZGVyLWxl ZnQtd2lkdGg6IDEuNXB0OyBwYWRkaW5nOiAwY20gMGNtIDBjbSA0cHQ7IiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsg Ym9yZGVyLXRvcC1jb2xvcjogcmdiKDIyNSwgMjI1LCAyMjUpOyBib3JkZXItdG9wLXdpZHRoOiAx cHQ7IHBhZGRpbmc6IDNwdCAwY20gMGNtOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QXJ1biBBcnVuYWNoYWxhbSAoY2FydW5hY2gpIFs8 YSBocmVmPSJtYWlsdG86Y2FydW5hY2hAY2lzY28uY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsg dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tYWlsdG86Y2FydW5hY2hAY2lz Y28uY29tPC9hPl08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmRlbiA3IG1haiAyMDE3IDE5OjE3PGJyIGNs YXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5CbyBCdXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpiby5idXJt YW5AZXJpY3Nzb24uY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IiBjbGFzcz0iIj5iby5idXJtYW5AZXJpY3Nzb24uY29tPC9hPiZndDs8YnIgY2xh c3M9IiI+DQo8YiBjbGFzcz0iIj5DYzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPm1tdXNpYyAoPGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9y ZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xh c3M9IiI+bW11c2ljQGlldGYub3JnPC9hPikgJmx0OzxhIGhyZWY9Im1haWx0bzptbXVzaWNAaWV0 Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsi IGNsYXNzPSIiPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7Ow0KIEZsZW1taW5nIEFuZHJlYXNlbiAo ZmFuZHJlYXMpICZsdDs8YSBocmVmPSJtYWlsdG86ZmFuZHJlYXNAY2lzY28uY29tIiBzdHlsZT0i Y29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5mYW5k cmVhc0BjaXNjby5jb208L2E+Jmd0Ozs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11 bGNhc3QuYXV0aG9yc0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2Fz dC5hdXRob3JzQGlldGYub3JnPC9hPjsNCiBBcnVuIEFydW5hY2hhbGFtIChjYXJ1bmFjaCkgJmx0 OzxhIGhyZWY9Im1haWx0bzpjYXJ1bmFjaEBjaXNjby5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmNhcnVuYWNoQGNpc2NvLmNv bTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBSZXZpZXc6IGRyYWZ0 LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3Q8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpUaGFua3MgQm8gITxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NClBsZWFzZSBzZWUgaW5saW5lLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0 OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIE1heSAzLCAyMDE3LCBhdCAxMjoxNCBQTSwgQm8gQnVy bWFuICZsdDs8YSBocmVmPSJtYWlsdG86Ym8uYnVybWFuQGVyaWNzc29uLmNvbSIgc3R5bGU9ImNv bG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+Ym8uYnVy bWFuQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj5IaSBBcnVuLDwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5U aGFuayB5b3UgZm9yIHRoZSBjb21tZW50cyEgUGxlYXNlIHNlZSBteSByZXNwb25zZXMgaW5saW5l IGJlbG93Ljwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5DaGVlcnMsPC9zcGFuPjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4vQm88 L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXIt bGVmdC1jb2xvcjogYmx1ZTsgYm9yZGVyLWxlZnQtd2lkdGg6IDEuNXB0OyBwYWRkaW5nOiAwY20g MGNtIDBjbSA0cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3Jk ZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyNSwgMjI1 LCAyMjUpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDNwdCAwY20gMGNtOyIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkFydW4NCiBBcnVuYWNoYWxhbSAo Y2FydW5hY2gpIFs8YSBocmVmPSJtYWlsdG86Y2FydW5hY2hAY2lzY28uY29tIiBzdHlsZT0iY29s b3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iY29sb3I6IHB1cnBsZTsiIGNsYXNzPSIiPm1haWx0bzpjYXJ1bmFjaEBjaXNjby5jb208 L3NwYW4+PC9hPl08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmRlbiA5IGFwcmlsIDIwMTcgMTM6MDQ8YnIg Y2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkJvIEJ1cm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJvLmJ1 cm1hbkBlcmljc3Nvbi5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9 IiI+Ym8uYnVybWFuQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+RmxlbW1pbmcgQW5kcmVhc2VuIChmYW5kcmVhcykgJmx0OzxhIGhyZWY9Im1haWx0 bzpmYW5kcmVhc0BjaXNjby5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRp b246IHVuZGVybGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xh c3M9IiI+ZmFuZHJlYXNAY2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7Ow0KIEFydW4gQXJ1bmFjaGFs YW0gKGNhcnVuYWNoKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNhcnVuYWNoQGNpc2NvLmNvbSIgc3R5 bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj5jYXJ1bmFjaEBjaXNjby5jb208 L3NwYW4+PC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFJldmlldzog ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdDwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkhpIEJvLDxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClJldmll d2VkIHRoZSBkcmFmdCBhbmQgaGF2ZSBhIGZldyBjb21tZW50cyBhbmQgcXVlc3Rpb25zIChzaG93 biBiZWxvdykuJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClRoYW5rcyE8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCkFydW48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNs YXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDI1NSwgMTA2LCAwKTsiIGNsYXNzPSIiPkNv bW1lbnRzIC8gUXVlc3Rpb25zPC9zcGFuPjwvYj46PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQooMSkmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTEiIHN0eWxl PSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9IiI+U2VjdGlvbiAxPC9zcGFuPjwvYT48 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDt0 cmFuc3BvcnQgb3ZlciBSVFAuICZuYnNwO1RoZSBtZWRpYSB0cmFuc3BvcnQgdG9wb2xvZ2llcyBj b25zaWRlcmVkIGFyZTxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3BvaW50IHRvIHBvaW50PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPlJU UCBzZXNzaW9uczwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+YXMgd2VsbCBhcyBjZW50cmFsaXplZCBtdWx0aS1wYXJ0eSBSVFA8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZu YnNwOyAmbmJzcDtzZXNzaW9ucywgd2hlcmUgYSBtZWRpYSBzZW5kZXIgd2lsbCBwcm92aWRlIHRo ZSBzaW11bGNhc3RlZCBzdHJlYW1zPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7dG8gYW4gUlRQIG1p ZGRsZWJveCBvciBlbmRwb2ludCwgYW5kIG1pZGRsZWJveGVzIG1heSBmdXJ0aGVyPG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQombmJzcDsgJm5ic3A7ZGlzdHJpYnV0ZSB0aGUgc2ltdWxjYXN0IHN0cmVhbXMgdG8gb3RoZXIg bWlkZGxlYm94ZXMgb3IgZW5kcG9pbnRzLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NClNldmVyYWwgcGxhY2VzIGluIHRoZSBkb2MgdXNlIHRoZSB0ZXJtIOKAnFJUUCBTZXNzaW9u 4oCdIGFuZCDigJxSVFAgc3RyZWFtc+KAnSBoZW5jZSBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gcHJv dmlkZSBhIHJlZmVyZW5jZSBzbyB0aGF0IHJlYWRlcnMgY2FuIGtub3cgdGhlIGRpZmZlcmVuY2Uu PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClJUUCBTZXNzaW9uIOKAlCZndDsmbmJzcDs8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzU1MCNzZWN0aW9uLTEuMSIgc3R5 bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjMzU1MCNzZWN0aW9uLTEuMTwvc3Bhbj48L2E+PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPltCb0JdIEFzIHNhaWQgYXQgdGhlIHN0YXJ0IG9mIHNlY3Rpb24gMi4xIOKAnFRl cm1pbm9sb2d54oCdLCB0aGUgZHJhZnQgZ2VuZXJhbGx5IHVzZXMgdGVybXMgZnJvbSBSVFAgVGF4 b25vbXkgKFJGQyA3NjU2KS4gQm90aCBSVFAgc3RyZWFtIGFuZCBSVFAgc2Vzc2lvbiBhcmUgdGVy bXMNCiBkZXNjcmliZWQgdGhlcmUuIFJUUCBzZXNzaW9uIGlzLCBhcyB5b3Ugc2F5LCBhbHNvIGRl ZmluZWQgYnkgUkZSQyAzNTUwLCBidXQgdGhlcmUgaGFzIGJlZW4gc2lnbmlmaWNhbnQgY29uZnVz aW9uIGFyb3VuZCB3aGF0IHRoZSB0ZXJtIHJlYWxseSBtZWFucywgc28gYWRkaXRpb25hbCBjbGFy aWZpY2F0aW9uIHdhcyBhZGRlZCBpbiBSRkMgNzY1Ni4gSSBoYXZlIG5vIHByb2JsZW0gYWRkaW5n IHRoZW0gYXMgZXhwbGljaXQgdGVybXMgaW4gc2VjdGlvbg0KIDIuMSwgYnV0IHdpbGwgdGhlbiBt b3JlIG9yIGxlc3MganVzdCByZWZlcmVuY2UgUkZDIDM1NTAgYW5kIFJGQyA3NjU2IGZyb20gdGhl cmUuPC9zcGFuPjwvaT48L2I+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpHb29k LiBUaGUgcmVmZXJlbmNlIGluIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uIHNob3VsZCBiZSBzdWZm aWNpZW50LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBj bGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVm dC1jb2xvcjogYmx1ZTsgYm9yZGVyLWxlZnQtd2lkdGg6IDEuNXB0OyBwYWRkaW5nOiAwY20gMGNt IDBjbSA0cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KKDIpJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNh c3QtMDgjc2VjdGlvbi0zLjEiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9 IiI+U2VjdGlvbiAzLjE8L3NwYW4+PC9hPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAn Q291cmllciBOZXcnOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgQml0cmF0ZTombmJzcDsgVGhp cyByZWxhdGVzIHRvIHRoZSBhbW91bnQgb2YgYml0cyA8YiBjbGFzcz0iIj5zcGVudCBwZXIgc2Vj b25kPC9iPiB0bzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAn Q291cmllciBOZXcnOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dHJhbnNtaXQgdGhlIG1lZGlhIHNvdXJjZSBhcyBhbiBSVFAgc3RyZWFtLCB3aGljaCB0eXBpY2Fs bHkgYWxzbzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291 cmllciBOZXcnOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2Es IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWZm ZWN0cyB0aGUgUXVhbGl0eSBvZiBFeHBlcmllbmNlIChRb0UpIGZvciB0aGUgcmVjZWl2aW5nIHVz ZXIuPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wcmU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KSSB0aGluayB0aGUgYXV0aG9ycyBtYXkgaGF2 ZSBpbnRlbmRlZCB0byB1c2Ug4oCcPGIgY2xhc3M9IiI+c2VudDwvYj7igJ0gaW5zdGVhZCBvZiDi gJxzcGVudCZxdW90Oy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+W0JvQl0gSSB0aGluayBh IHNlbmRlciBjYW4g4oCcc3BlbmTigJ0gYml0cyBpdCDigJxoYXMgYXZhaWxhYmxl4oCdIHRvIHNl bmQsIGJ1dCBJIGFncmVlIHRoYXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIGNoYW5nZSB0byDigJxz ZW504oCdLjwvc3Bhbj48L2k+PC9iPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQooMykmbmJz cDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMt c2RwLXNpbXVsY2FzdC0wOCNzZWN0aW9uLTYuMSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJw bGU7IiBjbGFzcz0iIj5TZWN0aW9uIDYuMTwvc3Bhbj48L2E+PG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ZGlyZWN0aW9uYWxpdHkgaXMgcmV2 ZXJzZWQuICZuYnNwO1RoaXMgZXhhbXBsZSBhbnN3ZXIgaGFzIHJlbW92ZWQgYWxsPG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQombmJzcDsgJm5ic3A7b2ZmZXJlZCBhbHRlcm5hdGl2ZSBmb3JtYXRzIGZvciB0aGUgZmlyc3Qg c2ltdWxjYXN0IHN0cmVhbSAoa2VlcGluZzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO29ubHkgU0NJ RCAxKSwgYnV0IGtlcHQgYWx0ZXJuYXRpdmUgZm9ybWF0cyBmb3IgdGhlIHNlY29uZCBzaW11bGNh c3Q8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtzdHJlYW0gaW4gcmVjZWl2ZSBkaXJlY3Rpb24gKDQs IDUpLiAmbmJzcDtUaGUgYW5zd2VyPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPjxzIGNsYXNzPSIiPnRodXM8L3M+PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hY2NlcHRzIHRvIHNlbmQ8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDt0d28gc2ltdWxjYXN0IHN0cmVhbXMsIHdpdGhvdXQgYWx0 ZXJuYXRpdmVzLiAmbmJzcDtUaGUgYW5zd2VyIGRvZXMgbm90PG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7YWNjZXB0IGluaXRpYWwgcGF1c2Ugb2YgYW55IHNpbXVsY2FzdCBzdHJlYW1zLCBpbiBlaXRo ZXIgZGlyZWN0aW9uLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO01vcmUgZXhhbXBsZXMgY2FuIGJl IGZvdW5kIGluIFNlY3Rpb24gNi42LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N ClBsZWFzZSByZW1vdmUgdGhlIHdvcmQg4oCcdGh1c+KAnSBzaW5jZSB0aGVyZSBpcyBubyByZWFz b24gcHJvdmlkZWQgcHJpb3IgdG8gdGhpcyBzZW50ZW5jZS48bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+W0JvQl0gT0suPC9zcGFuPjwvaT48L2I+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KKDQpJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3QtMDgjc2VjdGlvbi02LjIiIHN0 eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9IiI+U2VjdGlvbiA2LjI8L3NwYW4+ PC9hPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwO2luc3RlYWQgb2YgbWFraW5nIGl0IGVxdWl2YWxlbnQgdG8gaW1wbGljaXRseSBzZW5kaW5n IGEgcGF1c2U8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtyZXF1ZXN0LCBpcyBiZWNhdXNlIHRoZSBw YXVzaW5nIFJUUCBzZW5kZXIgY2Fubm90IGtub3cgd2hpY2g8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJz cDtyZWNlaXZpbmcgU1NSQyBvd25zIHRoZSByZXN0cmljdGlvbiB3aGVuPHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPlRNTUJSL1RNTUJO PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hcmUg dXNlZCBmb3I8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtwYXVzZS9yZXN1bWUgc2lnbmFsaW5nIHNp bmNlIHRoZSBSVFAgcmVjZWl2ZXIncyBTU1JDIGluIHNlbmQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJz cDtkaXJlY3Rpb24gaXMgc29tZXRpbWVzIG5vdCB5ZXQga25vd24uPG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KSXQgd291bGQgYmUgZ29vZCB0byBhIGdpdmUgcmVmZXJlbmNlIGZv ciBUTU1CUi9UTU1CTiBwb2ludGluZyB0byZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM3NzI4I3NlY3Rpb24tMi4xIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6IHB1 cnBsZTsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NzI4I3NlY3Rp b24tMi4xPC9zcGFuPjwvYT4mbmJzcDtvciZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM3NzI4I3NlY3Rpb24tNS42IiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iY29sb3I6IHB1 cnBsZTsiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NzI4I3NlY3Rp b24tNS42PC9zcGFuPjwvYT4uPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPltCb0JdIE9LLiBQ cmVmZXIgc2VjdGlvbiA1LjYgb2YgUkZDIDc3MjguIEhvd2V2ZXIsIHRoZSBkcmFmdCBzb3VyY2Ug aXMgWE1MIGFuZCBJIGRvbuKAmXQgdGhpbmsgeG1sMnJmYyAmbHQ7eHJlZiZndDsgc3VwcG9ydHMg cmVmZXJlbmNpbmcgYSBwYXJ0aWN1bGFyIHNlY3Rpb24sIHNvIEnigJltIG5vdA0KIHN1cmUgaG93 IHRvIGFjaGlldmUgdGhhdC48L3NwYW4+PC9pPjwvYj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkkgdGhp bmsgd2UgY2FuIHVzZSAmcXVvdDtTZWN0aW9uIDUuNiBvZiAmbHQ7eHJlZiB0YXJnZXQ9JnF1b3Q7 UkZDNzcyOOKAnS8mZ3Q74oCdIGluIHRoZSBYTUwgdmVyc2lvbiBvZiB0aGUgZG9jLjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8 L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpSZWZlcmVuY2U6Jm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly94bWwycmZjLnRvb2xzLmlldGYub3JnL3htbDJyZmNGQVEuaHRtbCNhbmNob3IxOCIgc3R5 bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ aHR0cHM6Ly94bWwycmZjLnRvb2xzLmlldGYub3JnL3htbDJyZmNGQVEuaHRtbCNhbmNob3IxODwv YT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KV29ya2luZyBleGFtcGxlOjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpYTUw6PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4m bmJzcDs8L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombHQ7c2VjdGlvbiB0aXRsZT0mcXVv dDtJbnRlcm1lZGlhcnkmcXVvdDsmZ3Q7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQombHQ7dCZndDtUaGUgdGVybSAmcXVvdDtpbnRlcm1lZGlhcnkmcXVvdDsgaXMg ZGVmaW5lZCBpbiBTZWN0aW9uIDIgb2YgJmx0O3hyZWYgdGFyZ2V0PSZxdW90O1JGQzc5ODkmcXVv dDsvJmd0OzsgaXQgcmVmZXJzIHRvIGFueSBlbnRpdHkgYWxvbmcgdGhlIGNhbGwgc2lnbmFsaW5n IHBhdGguJmx0Oy90Jmd0OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KJmx0Oy9zZWN0aW9uJmd0OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NClJGQzo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTIzI3NlY3Rpb24tMy4zIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODEyMyNzZWN0aW9uLTMuMzwvYT48bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ W0JvQl0gT0ssIHRoYXQgd29ya3M8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1s ZWZ0LWNvbG9yOiBibHVlOyBib3JkZXItbGVmdC13aWR0aDogMS41cHQ7IHBhZGRpbmc6IDBjbSAw Y20gMGNtIDRwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KKDUpJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3QtMDgjc2VjdGlvbi02 LjMuMiIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIg Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj5TZWN0aW9uIDYu My4yPC9zcGFuPjwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7IEFu IGFuc3dlcmVyIHRoYXQgcmVjZWl2ZXMgaW5kaWNhdGlvbiBpbiBhbiBvZmZlciBvZiBhbiBTQ0lE IGJlaW5nPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsgaW5pdGlhbGx5IHBhdXNlZCBTSE9VTEQgbWFy ayB0aGF0IFNDSUQgYXMgaW5pdGlhbGx5IHBhdXNlZCBhbHNvIGluPG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDsgdGhlIGFuc3dlciwgcmVnYXJkbGVzcyBvZiBkaXJlY3Rpb24sIHVubGVzcyBpdCBoYXMg Z29vZCByZWFzb24gZm9yPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsgdGhlIFNDSUQgbm90IGJlaW5n IGluaXRpYWxseSBwYXVzZWQuJm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPk9uZSBzdWNoIHJlYXNvbiBjb3VsZCwgZm9yPC9i PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IGV4YW1wbGUsIGJlIHRoYXQgdGhl IGFuc3dlcmVyIHdvdWxkIG90aGVyd2lzZSBpbml0aWFsbHkgbm90IHJlY2VpdmU8L2I+PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8YiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgYW55IG1lZGlhIG9mIHRoYXQgdHlwZSBhdCBh bGwuPC9iPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KVHJ5aW5n IHRvIHVuZGVyc3RhbmQgdGhlIGV4YW1wbGUuIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4gYSBzY2Vu YXJpbyBpbiB3aGljaCB0aGUgZXhhbXBsZSBhcHBsaWVzPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFz cz0iIj5bQm9CXSBTYXkgdGhhdCB5b3UgaGF2ZSBhIHNpbXVsY2FzdCB3aXRoIHNldmVyYWwgZGlm ZmVyZW50IG1lZGlhIHF1YWxpdHkgbGV2ZWxzIGJlaW5nIG9mZmVyZWQuIFRoZSBvZmZlcmVyIGV4 cGVjdHMgbW9zdCByZWNlaXZlcnMgdG8gYWNjZXB0IHRoZSBoaWdoZXN0IHF1YWxpdHkNCiBsZXZl bCwgYW5kIHRoYXQgdGhleSBhcmUgdGhlbiB1bmludGVyZXN0ZWQgdG8gcmVjZWl2ZSB0aGUgbG93 ZXIgcXVhbGl0eSBsZXZlbHMuIFRoZSBvZmZlcmVyIGhhcyB0aGVyZWZvcmUgc2V0IHRoZSBsb3dl ciBxdWFsaXR5IHNpbXVsY2FzdCBzdHJlYW1zIHRvIGluaXRpYWxseSBwYXVzZWQuIEZ1cnRoZXIg YXNzdW1lIGEgc29tZXdoYXQgcmVzdHJpY3RlZCBhbnN3ZXJlciB0aGF0IGNhbm5vdCBjb3BlIHdp dGggdGhlIGhpZ2hlc3QgcXVhbGl0eSBsZXZlbC4NCiBJdCB0aGVyZWZvcmUgd2FudHMgdG8gYWNj ZXB0IGEgbG93ZXIgcXVhbGl0eSBsZXZlbCBzaW11bGNhc3Qgc3RyZWFtIGFuZCB3b3VsZCBub3Qg cmVjZWl2ZSBhbnl0aGluZyBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBzZXNzaW9uICh1bnRpbCBp c3N1aW5nIGFuIFJGQyA3NzI4IFJFU1VNRSkgaWYgaXQgYWNjZXB0cyB0aGlzIGxvd2VyIHF1YWxp dHkgc2ltdWxjYXN0IHN0cmVhbSBhcyBpbml0aWFsbHkgcGF1c2VkLiBXaXRob3V0IGluY2x1ZGlu ZyBzdWNoDQogZmFpcmx5IGV4dGVuc2l2ZSBleGFtcGxlIHRleHQsIEkgZG9u4oCZdCBrbm93IGhv dyB0byBiZXN0IG1ha2UgYSBjbGFyaWZpY2F0aW9uLiBEbyB5b3UgaGF2ZSBhIHByb3Bvc2FsPzwv c3Bhbj48L2k+PC9iPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxv OnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KR290IGl0LiBO aWNlIGV4YW1wbGUuPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCkhvdyBhYm91 dCBmb2xsb3dpbmc6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO09uZSBzdWNoIHJlYXNvbiBjb3Vs ZCwgZm9yIGV4YW1wbGUsIGJlIHRoYXQgdGhlIGFuc3dlcmVyIGRvZXNu4oCZdCBoYXZlIHRoZSBh YmlsaXR5IHRvPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJz cDsgJm5ic3A7cHJvY2VzcyBhbnkgdW5wYXVzZWQgc2ltdWxjYXN0IHN0cmVhbXMgb2ZmZXJlZCBm b3IgYSBnaXZlbiBtZWRpYSBzb3VyY2UuIEl0IGNob29zZXM8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtvbmUgb2YgdGhlIHBhdXNlZCBzaW11 bGNhc3Qgc3RyZWFtIGluIHRoZSBvZmZlciBhbmQgbWFya3MgaXQgYXMgbm90IHBhdXNlZCBpbiB0 aGUgYW5zd2VyLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5bQm9CXSBPSywgYnV0IHN1Z2dlc3QgbWlub3Igd29yZGlu ZyBjaGFuZ2UgdG8ga2VlcCBpdCBlbnRpcmVseSBjbGVhciB0aGF0IHRoZSBzY29wZSBpcyBTRFAg YW5kPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjx1IGNs YXNzPSIiPmluaXRpYWxseTwvdT48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+cGF1c2VkDQogc3RyZWFtczo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+T25lIHN1Y2ggcmVhc29uIGNvdWxkLCBmb3IgZXhhbXBs ZSwgYmUgdGhhdCB0aGUgYW5zd2VyZXIgZG9lc24ndCBoYXZlIHRoZSBhYmlsaXR5IHRvIHByb2Nl c3MgYW55IGluaXRpYWxseSB1bnBhdXNlZCBzaW11bGNhc3Qgc3RyZWFtcyBvZmZlcmVkIGZvciBh IGdpdmVuIG1lZGlhIHNvdXJjZS4gSXQgdGhlbiBjaG9vc2VzDQogb25lIG9mIHRoZSBpbml0aWFs bHkgcGF1c2VkIHNpbXVsY2FzdCBzdHJlYW1zIGluIHRoZSBvZmZlciBhbmQgbWFya3MgaXQgYXMg bm90IHBhdXNlZCBpbiB0aGUgYW5zd2VyLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5v bmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IGJsdWU7IGJvcmRlci1sZWZ0LXdpZHRo OiAxLjVwdDsgcGFkZGluZzogMGNtIDBjbSAwY20gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCig2KSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3Nl Y3Rpb24tNy4yLjEiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9IiI+U2Vj dGlvbiA3LjIuMTwvc3Bhbj48L2E+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtUaGlzIHdpbGwgcmVzdWx0IGluIGEgc2luZ2xlIFJU UCBzdHJlYW0gYmVpbmcgdXNlZCBmb3IgYTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0iIj5wYXJ0aWN1bGFyPC9iPjxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIg Y2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7b2Y8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnRoZSBSVFAgbWl4ZXLigJlzIG1lZGlhIHNvdXJjZXMu Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQpUaGlzIHNlbnRlbmNlIHNlZW1zIHRvIGJlIG1pc3NpbmcgYSB3b3JkIC0g4oCc4oCmdG9yIGEg cGFydGljdWxhciBfX19fX19fIG9mIHRoZSBSVFAgbWl4ZXLigJlz4oCmLuKAnTxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj5bQm9CXSBXaGF0IGFib3V0IHJlcGxhY2luZyDigJxhIHBhcnRpY3Vs YXIgb2bigJ0gd2l0aCDigJxlYWNoIG9uZSBvZuKAnT88L3NwYW4+PC9pPjwvYj48bzpwIGNsYXNz PSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CldlIGNhbiB1c2Ug4oCcZWFjaCBvZuKAnTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7VGhpcyB3aWxsIHJlc3VsdCBpbiBhIHNpbmdsZSBS VFAgc3RyZWFtIGJlaW5nIHVzZWQgZm9yIGVhY2gmbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtvZiB0aGUgUlRQIG1peGVyJ3MgbWVk aWEgc291cmNlcy4mbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+W0JvQl08c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj5PSzxvOnAgY2xhc3M9IiI+ PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2lu LWJvdHRvbTogNXB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9y ZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IGJsdWU7 IGJvcmRlci1sZWZ0LXdpZHRoOiAxLjVwdDsgcGFkZGluZzogMGNtIDBjbSAwY20gNHB0OyIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86 cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCig3KSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA4I3NlY3Rpb24t Ny4yLjEiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsi IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9IiI+U2VjdGlvbiA3 LjIuMTwvc3Bhbj48L2E+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQombmJzcDsgJm5ic3A7Jm5ic3A7PGIgY2xhc3M9IiI+VGhpcyBhczwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+dGhlcmUgaXMgbm90aGluZyBpbiB0 aGUgc2lnbmFsbGluZyBiZXR3ZWVuIHRoZSBtaXhlciBhbmQgdGhlIHJlY2VpdmVyIHRoYXQgaXMg c3RydWN0dXJlZCBhcm91bmQgdGhlIG9yaWdpbmF0aW5nIG1lZGlhIHNvdXJjZXMsIG9ubHkgdGhl IG1peGVy4oCZcyBtZWRpYSBzb3VyY2VzLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJz cDtJIHRoaW5rIOKAnFRoaXMgYXPigJ0gbmVlZHMgdG8gYmUgY2hhbmdlZCB0byDigJxUaGF0IGlz 4oCdLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9 IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5bQm9CXSBPSy4gSSBhc3N1bWUg4oCcVGhh dCBpcywg4oCcICh3aXRoIGEgY29tbWEpPzwvc3Bhbj48L2k+PC9iPjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNw OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClllcy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyIgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5v bmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IGJsdWU7IGJvcmRlci1sZWZ0LXdpZHRo OiAxLjVwdDsgcGFkZGluZzogMGNtIDBjbSAwY20gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KKDgpJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1zaW11bGNhc3QtMDgjc2Vj dGlvbi03LjIuMSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJs aW5lOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7IiBjbGFzcz0iIj5TZWN0 aW9uIDcuMi4xPC9zcGFuPjwvYT48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNw O0lmIFJ0cFN0cmVhbUlkcyBhcmUgdXNlZCBpbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0iIj50aGlzIHNjZW5hcmlvPC9iPiwgaXQgc2hv dWxkIGJlIG5vdGVkIHRoYXQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwO3RoZSBSdHBTdHJl YW1JZCBvbiBhIHBhcnRpY3VsYXIgU1NSQyB3aWxsIGNoYW5nZSBiYXNlZCBvbiB0aGUgYWN0dWFs PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDtzaW11bGNhc3Qgc3RyZWFtIHNlbGVjdGVkIGZv ciBzd2l0Y2hpbmcuJm5ic3A7Jm5ic3A7VGhlc2UgUnRwU3RyZWFtSWQ8bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNw OyZuYnNwOyZuYnNwO2lkZW50aWZpZXJzIHdpbGwgYmUgbG9jYWwgdG88c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGIgY2xhc3M9IiI+dGhpcyBsZWfigJlz IHNpZ25hbGxpbmcgY29udGV4dDwvYj4uJm5ic3A7Jm5ic3A7SW48bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOyZu YnNwOyZuYnNwO2FkZGl0aW9uLCB0aGUgZGVmaW5lZCBSdHBTdHJlYW1JZHMgYW5kIHRoZWlyIHBh cmFtZXRlcnMgbmVlZCB0byBjb3ZlcjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7YWxsIHRo ZSBtZWRpYSBzb3VyY2VzIGFuZCBzaW11bGNhc3Qgc3RyZWFtcyB0aGF0IGNhbiBiZSBzd2l0Y2hl ZDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFz cz0iIj5pbnRvPC9iPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhp cyBtZWRpYSBzb3VyY2UuPC9iPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCklu IHRoZSBhYm92ZSBwYXJhZ3JhcGggd2hhdCBkb2VzIOKAnHRoaXMgc2NlbmFyaW/igJ0gcmVmZXIg dG8/IElzIGl0IHRoZSBzY2VuYXJpbyBvZiB1c2luZyBtZWRpYSZuYnNwO3NvdXJjZeKAmXMgcnRw IHN0cmVhbSBTU1JDIGluIHRoZSBDU1JDIG9mIHRoZSBydHAgbWl4ZXLigJlzIHJ0cCBzdHJlYW0g KG9yKSBpcyBpdCByZWZlcnJpbmcgdG8g4oCcUlRQIE1peGVyIC0gUmVjZWl2ZXLigJ0gc2NlbmFy aW9zIGluIGdlbmVyYWw/PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPltCb0JdIOKAnFRoaXMg c2NlbmFyaW/igJ0gbWVhbnMgdG8gcmVmZXIgdG8gdGhpcyBzZWN0aW9uICg3LjIuMSkuIFdpbGwg Y2xhcmlmeS48L3NwYW4+PC9pPjwvYj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KRG9lcyDi gJx0aGlzIGxlZ+KAmXMgc2lnbmFsaW5nIGNvbnRleHTigJ0gcmVmZXIgdG8gdGhlIOKAnFJUUCBt aXhlciAtIFJlY2VpdmVy4oCdIGNhbGwgbGVnPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5b Qm9CXSBOb3QgbmVjZXNzYXJpbHkganVzdCBSVFAgc3RyZWFtIHJlY2VpdmVyLCBpdCBjb3VsZCBh bHNvIGJlIFJUUCBzdHJlYW0gc2VuZGVyLCBvdGhlcndpc2UgeWVzLiBJdCBpcyB0aGUgY29udGV4 dCBvZiBhIHNpbmdsZSBTRFAgb2ZmZXIvYW5zd2VyIGJldHdlZW4gdHdvIHBhcnRpY2lwYW50cw0K IChSVFAgbWl4ZXIgYW5kIHdoYXRldmVyIGVuZHBvaW50IGlzIHRoZSBjb3VudGVycGFydCDigJMg cG9zc2libHkgZXZlbiBhbm90aGVyIFJUUCBtaXhlcikuPC9zcGFuPjwvaT48L2I+PG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NClRoZSBzZW50ZW5jZSDigJxJbiBhZGRpdGlvbiwgdGhlIGRlZmlu ZWQgUnRwU3RyZWFtSWRz4oCmLnRoYXQgY2FuIGJlIHN3aXRjaGVkIGludG8gdGhpcyBtZWRpYSBz b3VyY2UmcXVvdDsgaXMgbm90IGNsZWFyIHRvIG1lLiBTcGVjaWZpY2FsbHkgd2h5IHdvdWxkIHdl IHN3aXRjaGluZyBhbiBSVFAgc3RyZWFtPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPmludG88L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmENCiBtZWRpYSBzb3VyY2UuIFdhcyBpdCBpbnRl bmRlZCB0byBiZSDigJxzd2l0Y2hlZCBmcm9tIHRoaXMgbWVkaWEgc291cmNl4oCdIG9yIOKAnHN3 aXRjaGVkIHRvIGEgUlRQIHJlY2VpdmVy4oCdPyBQbGVhc2UgZXhwbGFpbi48bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+W0JvQl0gVGhlIFJUUCBtaXhlciByZWNlaXZlcyAocG90ZW50aWFsbHkg c2ltdWxjYXN0KSBSVFAgc3RyZWFtcyBmcm9tIG9yaWdpbmF0aW5nIG1lZGlhIHNvdXJjZXMgYW5k IHN3aXRjaGVzIHRob3NlIFJUUCBwYWNrZXRzIGludGVybmFsbHkgdG8gcHJvdmlkZSBkYXRhIGZv ciB0aGUNCiBSVFAgbWl4ZXLigJlzIG93biBtZWRpYSBzb3VyY2VzIGFuZCBSVFAgc3RyZWFtcywg YXMgc2VlbiBieSB0aGUgZmluYWwgcmVjZWl2ZXIgb2YgdGhlIFJUUCBzdHJlYW1zIGZyb20gdGhl IFJUUCBtaXhlci4gV2hhdCBhYm91dCByZS1mb3JtdWxhdGluZyB0byDigJxJbiBhZGRpdGlvbiwg dGhlIGRlZmluZWQgUnRwU3RyZWFtSWRzIGFuZCB0aGVpciBwYXJhbWV0ZXJzIG5lZWQgdG8gY292 ZXIgYWxsIHRoZSBtZWRpYSBzb3VyY2VzIGFuZCBzaW11bGNhc3Qgc3RyZWFtczxzcGFuIHN0eWxl PSJjb2xvcjogcmVkOyIgY2xhc3M9IiI+cmVjZWl2ZWQNCiBieSB0aGUgUlRQIG1peGVyPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj50aGF0IGNh biBiZSBzd2l0Y2hlZCBpbnRvIHRoaXMgbWVkaWEgc291cmNlPHNwYW4gc3R5bGU9ImNvbG9yOiBy ZWQ7IiBjbGFzcz0iIj4sIHNlbnQgYnkgdGhlIFJUUCBtaXhlcjwvc3Bhbj7igJ0/PC9zcGFuPjwv aT48L2I+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KWWVzISB0aGlzIGdpdmVzIG1vcmUgY2xh cml0eS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KVGhhbmtzITxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KQXJ1bjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1 cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6 IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjogYmx1ZTsgYm9yZGVyLWxl ZnQtd2lkdGg6IDEuNXB0OyBwYWRkaW5nOiAwY20gMGNtIDBjbSA0cHQ7IiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZu YnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7 PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBj bGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KT24gTWFyIDMwLCAyMDE3LCBhdCA1OjQyIFBNLCBBcnVu IEFydW5hY2hhbGFtIChjYXJ1bmFjaCkgJmx0OzxhIGhyZWY9Im1haWx0bzpjYXJ1bmFjaEBjaXNj by5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsi IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjb2xvcjogcHVycGxlOyIgY2xhc3M9IiI+Y2FydW5hY2hA Y2lzY28uY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBj bGFzcz0iIj4NCkhpIEZsZW1taW5nLDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7PG86cCBjbGFzcz0iIj48L286 cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpJIHRoaW5r IGluIGFib3V0IGEgd2VlayBpLmUgYnkgRU9CIDQvNy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KVGhhbmtzITxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MTJwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyI+DQpBcnVuPG86cCBjbGFzcz0iIj48L286cD48L3A+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQpTZW50IGZyb20gbXkgaVBob25lPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDEycHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPGJyIGNsYXNzPSIiPg0KT24gTWFyIDMwLCAy MDE3LCBhdCA0OjMzIFBNLCBGbGVtbWluZyBBbmRyZWFzZW4gKGZhbmRyZWFzKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmZhbmRyZWFzQGNpc2NvLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQt ZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJw bGU7IiBjbGFzcz0iIj5mYW5kcmVhc0BjaXNjby5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86 cCBjbGFzcz0iIj48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMTJwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQpUaGFu a3MgQXJ1biAtIHdoZW4gZG8geW91IHRoaW5rIHlvdSB3aWxsIGhhdmUgdGhlIHJldmlldyByZWFk eSA/PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tIEZsZW1taW5nPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KT24gMy8zMC8xNyA0OjMwIFBNLCBBcnVuIEFydW5hY2hhbGFt IChjYXJ1bmFjaCkgd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1 cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KSGkgRmxlbW1pbmcsPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KQXMgZGlzY3Vz c2VkLCBpIHdvdWxkIGJlIGdsYWQgdG8gcmV2aWV3Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0 IiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFz cz0iIj48c3BhbiBzdHlsZT0iY29sb3I6IHB1cnBsZTsiIGNsYXNzPSIiPmRyYWZ0LWlldGYtbW11 c2ljLXNkcC1zaW11bGNhc3Q8L3NwYW4+PC9hPiZuYnNwO2RyYWZ0LjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KJm5ic3A7 PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQpUaGFua3MhPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpBcnVuPG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQombmJzcDs8bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQouPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxv OnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8 L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_25CE009172AC4751A18E2808B89F7A56ciscocom_-- From nobody Mon May 8 02:04:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9620712785F for ; Mon, 8 May 2017 02:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 jwlsgkEjRtVj for ; Mon, 8 May 2017 02:04:44 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A411287A3 for ; Mon, 8 May 2017 02:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mSalVg+Xj8NuwlciSONGUYg93aeGQnk3lN7FZZD3r/s=; b=APAwF1qqtqZnf+uVTvJyUwNhod6+xXNaFgpdjnyQIhYheZpJo4XcvtmYTxytbhs7dD3wSL3A0wiBNPhXBTbfY2q44D5enkbqwAgX9Dgbsc8Ddsifb3TxLdjNTCczAEeEpH4OuuYpw5MWT7LGkN5zqydsec7GB769Ohbxm2xn5Pk= Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0179.outbound.protection.outlook.com [216.32.180.179]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-116-tb15hIXUOEW7hiPh09dgxQ-1; Mon, 08 May 2017 05:04:40 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Mon, 8 May 2017 09:04:38 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1075.019; Mon, 8 May 2017 09:04:38 +0000 From: "Asveren, Tolga" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? Thread-Index: AQHSvOgCNt6Dk7x2uEaNj1LXZRgEJKHUeB1AgAyW1oCAABq+MIAAJkiwgAjpqaA= Date: Mon, 8 May 2017 09:04:38 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CB8F961@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB8F961@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:zpfN8T72hoguy/AAm6FnbWuGvNZ8wPvqDqAKTR0y6k43yTIvVZ1ozDLNTq9D/jWqnrfhtGmBrMMdW+K3vqer89hUGPO2chp5MZmxhXioY2VCxPvKK+Gohk+mtwtzXpWEI0f5bcP+0n2/NW9wthX/QrUNaPirRxAPRITBYqmG9klkYrkvmANc5nmew5NNzz9GEyYWUqllmwFGTr57VG3iY5t1wdkgyeI4KHa/83b9ZFazeI1Vz9TCViQapm+Oud7c0hpuX4pIf3W6wQneLAY1gY8A6sOKB6c+vwI5G+uBUo8Zex67J7fkXZsKogiRFQMwftACiEHmlb4ggJWa5rSAJg==; 20:PcwQgMNe0+GnTHD7rkOzFSbMtOCzNhP70qh8GW0yDyrMhOortu2wkk5j60zXDSXMnmxaI3zX0LW28AIkQfE46UoWAhG9ByVQzvtnSpDo1vIt4/Ps96IKb7RDWmVOdAl+hZRqbr5aLhPFVbHLqTnfkOxrv66c3ZTgX/4DeqMt+yQ= x-ms-office365-filtering-correlation-id: 919e2740-c495-49fe-b10b-08d495f14194 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN2PR03MB2352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 0301360BF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39410400002)(39450400003)(39830400002)(377454003)(6506006)(77096006)(3846002)(66066001)(6116002)(86362001)(7696004)(229853002)(81166006)(122556002)(76176999)(54356999)(189998001)(50986999)(33656002)(8936002)(6436002)(99286003)(8676002)(2950100002)(2501003)(102836003)(25786009)(53546009)(3660700001)(790700001)(478600001)(7906003)(74316002)(7736002)(54896002)(6306002)(236005)(6246003)(55016002)(9686003)(38730400002)(53936002)(93886004)(2906002)(3280700002)(230783001)(5660300001)(606005); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2017 09:04:38.3190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: tb15hIXUOEW7hiPh09dgxQ-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB235045C9283D4FD73C089E93B2EE0SN2PR03MB2350namp_" Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 09:04:46 -0000 --_000_SN2PR03MB235045C9283D4FD73C089E93B2EE0SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Yes, agreed but rtcp-mux-only inherits bidirectional semantics indirectly b= y virtue of being an extension of rtcp-mux, which itself is bidirectional. Having said that, I believe all this discussions is probably a bit too much= in the "philosophical domain" and I do not have any objection to move thin= gs forward the way you suggested. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 12:59 PM To: Asveren, Tolga ; mmusic@ietf.org Subject: RE: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Hi, >Yes agreed. All I am asking for is a sentence to prevent confusion: > >"It should be noted that both rtcp-mux (per updates in RFC8035) and rtcp-m= ux-only >have bidirectional semantics. They are either accepted and used by= both sides or not at >all." The only semantics of a=3Drtcp-mux-only is to indicate that one is not able= to fallback to non-mux. a=3Drtcp-mux is used to negotiate the actual mux. Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 7:58 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Hi, I took a look at this again. I am not sure I understand what it meant by rt= cp-mux-only being bidirectional. If rtp/rtcp-mux is negotiated, it will be bidirectional according to RFC803= 5. Note that, with rtcp-mux-only, you still need to include a=3Drtcp-mux, s= o the bidirectional rules associated with rtcp-mux still apply. Regards, Christer From: Tolga Asveren > Date: Monday 24 April 2017 at 21:29 To: Christer Holmberg >, "mmusic@ietf.org" > Subject: RE: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Thanks for pointing this out. The issue still would be applicable for alrea= dy deployed RFC5761 compliant/RFC8035 non-compliant entities. Therefore IMH= O it could be a good idea to explicitly mention that "rtcp-mux-only" is bid= irectional as "rtcp-mux" per RFC8035. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, April 24, 2017 6:46 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Hi, RFC 5761 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.t= xt), where we clarify that negotiated mux is always bidirectional. "This document updates RFC 5761 [RFC5761] by clarifying that an answerer can only include an "a=3Drtcp-mux" attribute in an answer if the associated offer contained the attribute. It also clarifies that the negotiation of RTP and RTCP multiplexing is for usage in both directions." Regards, Christer From: mmusic > on b= ehalf of Tolga Asveren = > Date: Monday 24 April 2017 at 13:24 To: "mmusic@ietf.org" > Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional= ? It seems draft-ietf-mmusic-mux-exclusive-11 assumes that mux support will b= e always bidirectional. OTOH, I think RFC5761 allows unidirectional semanti= cs: 5.1.1. SDP Signaling ... When SDP is used in a declarative manner, the presence of an "a=3Drtcp- mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth. Actually this part of RFC5761 sounds a bit odd as in declarative mode I tho= ught an attribute would convey information about the "receipt properties" t= herefore "rtcp-mux" would mean that the sender wants to receive RTP/RTCP mu= ltiplexed on the same port. It could be good to explicitly state in draft-ietf-mmusic-mux-exclusive tha= t unidirectional multiplexing with declarative mode is not supported. Example scenario: A sends rtcp-mux/rtcp-mux-only B does not support rtcp-mux-only and ignores it. It interprets rtcp-mux in = declarative mode and is ready to receive RTP/RTCP on the same port. OTOH, i= t does not want to send multiplexed RTP/RTCP hence does not include rtcp-mu= x in the reply. A terminates the session because the answer does not contain rtcp-mux. It c= an't determine whether multiplexing is not supported at all or whether B wa= nts to use it in a unidirectional way. Thanks, Tolga --_000_SN2PR03MB235045C9283D4FD73C089E93B2EE0SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Yes, agreed but rtcp-mux-only inherits bidirectional= semantics indirectly by virtue of being an extension of rtcp-mux, which it= self is bidirectional.

 

Having said that, I believe all this discussions is = probably a bit too much in the “philosophical domain” and I do = not have any objection to move things forward the way you suggested.

 

Thanks,

Tolga

 

From: Christer Holmberg [mailto:christer.holm= berg@ericsson.com]
Sent: Tuesday, May 2, 2017 12:59 PM
To: Asveren, Tolga <tasveren@sonusnet.com>; mmusic@ietf.org Subject: RE: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

 

Hi,

 

>Yes agreed.= All I am asking for is a sentence to prevent confusion:

> =

>“It s= hould be noted that both rtcp-mux (per updates in RFC8035) and rtcp-mux-onl= y >have bidirectional semantics. They= are either accepted and used by both sides or not at >all.”

 

The only semantics of = a=3Drtcp-mux-only is to indicate that one is not able to fallback to non-mu= x. a=3Drtcp-mux is used to negotiate the actual mux.

 

Regards,

 

Christer

 

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, May 2, 2017 7:58 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

 

Hi,

&n= bsp;

I took = a look at this again. I am not sure I understand what it meant by rtcp-mux-= only being bidirectional.

&n= bsp;

If rtp/= rtcp-mux is negotiated, it will be bidirectional according to RFC8035. Note= that, with rtcp-mux-only, you still need to include a=3Drtcp-mux, so the b= idirectional rules associated with rtcp-mux still apply.

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

&n= bsp;

From: Tolga Asveren <tasveren@sonusnet.com>
Date: Monday 24 April 2017 at 21:29
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: RE: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

&n= bsp;

Thanks for pointing this= out. The issue still would be applicable for already deployed RFC5761 comp= liant/RFC8035 non-compliant entities. Therefore IMHO it could be a good ide= a to explicitly mention that “rtcp-mux-only” is bidirectional as “rtcp-mux” per RFC8035. =

 =

Thanks,

Tolga<= /p>

 =

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, April 24, 2017 6:46 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

 =

Hi,

 <= /span>

RFC 576= 1 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.txt), where we clarify that = negotiated mux is always bidirectional.<= o:p>

 <= /span>

  =
 "This document updates RFC 5761 [RFC5761] by clarifying that an<=
/o:p>
   answerer can only include an =
"a=3Drtcp-mux" attribute in an answer if
   the associated offer containe=
d the attribute.  It also clarifies that
   the negotiation of RTP and RT=
CP multiplexing is for usage in both
   directions."<=
/span>

 <= /span>

Regards= ,

 <= /span>

Christe= r

 <= /span>

From: mmusic <mmusic-bounces@ietf.org> on behalf of Tolga Asveren <tasveren@sonusnet.com>
Date: Monday 24 April 2017 at 13:24
To: "mmusic@ietf.org&quo= t; <mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidire= ctional?

 <= /span>

It seems draft-ietf-mmus= ic-mux-exclusive-11 assumes that mux support will be always bidirectional. = OTOH, I think RFC5761 allows unidirectional semantics:

 =

5.1.1. SDP Signaling

…

 =

   When SDP is used in a declarative= manner, the presence of an "a=3Drtcp-

   mux" attribute signals that = the sender will multiplex RTP and RTCP on

   the same port.  The receiver= MUST be prepared to receive RTCP packets

   on the RTP port, and any resource= reservation needs to be made=

   including the RTCP bandwidth.

 =

Actually this part of RF= C5761 sounds a bit odd as in declarative mode I thought an attribute would = convey information about the “receipt properties” therefore = 220;rtcp-mux” would mean that the sender wants to receive RTP/RTCP multiplexed on the same port.

 =

It could be good to expl= icitly state in draft-ietf-mmusic-mux-exclusive that unidirectional multipl= exing with declarative mode is not supported.

 =

Example scenario:

A sends rtcp-mux/rtcp-mu= x-only

B does not support rtcp-= mux-only and ignores it. It interprets rtcp-mux in declarative mode and is = ready to receive RTP/RTCP on the same port. OTOH, it does not want to send = multiplexed RTP/RTCP hence does not include rtcp-mux in the reply.

A terminates the session= because the answer does not contain rtcp-mux. It can’t determine whe= ther multiplexing is not supported at all or whether B wants to use it in a= unidirectional way.

 =

Thanks,

Tolga<= /p>

--_000_SN2PR03MB235045C9283D4FD73C089E93B2EE0SN2PR03MB2350namp_-- From nobody Mon May 8 02:05:07 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A7E1287A3 for ; Mon, 8 May 2017 02:05:06 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 sSj45NXrCCGT for ; Mon, 8 May 2017 02:04:58 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23ADD12783A for ; Mon, 8 May 2017 02:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rjUpcEDrqCJp6+8LunoxsbsryWi34n45yi9OzU28wpk=; b=hbNuJ0KRW66aAangvWXtSHTlK5SUkM8l6qIhwXNvJaWN8VNZkUv9bIbjEzvI9BwaXrB0WQOFbiUXTPg2ntgbECpr0WfH7qoMNY7i3b2ntUhacLCK3Dt4U/hppqQv3mzwi9g+os7k7+vhl0zi5Z4AMiBmG2aCJ+F1ydraCHzE61k= Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0051.outbound.protection.outlook.com [216.32.180.51]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-150-a2-vu1R4PaSTwBMoiFiZmw-1; Mon, 08 May 2017 05:04:52 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Mon, 8 May 2017 09:04:50 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1075.019; Mon, 8 May 2017 09:04:50 +0000 From: "Asveren, Tolga" To: Flemming Andreasen , Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Thread-Index: AQHSxMbB9tlWASzsjUecixZeUtGAbKHltLAAgAR2AEA= Date: Mon, 8 May 2017 09:04:50 +0000 Message-ID: References: <18c1c5e6-9c26-cbad-7174-946592f9e6e5@cisco.com> In-Reply-To: <18c1c5e6-9c26-cbad-7174-946592f9e6e5@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:yda8PRFG3G35lkGmFfPQce/GRSxm6EacPSkM210Bpwk8+HCuujXx8wQKV8EpZvOPvuezzMTAXbQy13NvFm63A/rhwat+FjtQ3uEuFc/4cOhy2Rew8F7tT7cQXVbOQ8cejM4KrCgSe55iyYnEmQ9zyPrG8IQ3EOvEHZ7FGBqmLJABw4O8+u93zWJilqGkqS694cBIt8G8wxnZ4iHgNAK5R9Bm/FY+5zWB1jyfW+SvWhjykS0tO2lUcNc+tz1yFgKHbcUS1u8pu2qeYFYe7KujnQqLGl9Y9LeWnhXzkHcDpAOYcUyiH571o2PWcnx94dr+SzfYZ3+e4vwjMeGABqPeRw==; 20:cRRajAdsL76xHyE3/xSNIt35/TtN+movvll+obZZbZZxVQ3SAUGG7LCJ9xT1C5JGqbIyUStw9ol6Q5gLyXrDdU4UWjCwb0vwuHhisyOd2cYd7lGd6O87fMhik3Ml4a+i16OBVBvsZPwQikj3LN8i5mWNWo8fJklujP6klz1J+2Q= x-ms-office365-filtering-correlation-id: 50258008-1c71-4cff-9ff4-08d495f148b0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN2PR03MB2352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 0301360BF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39410400002)(39450400003)(39830400002)(24454002)(377454003)(6506006)(77096006)(3846002)(66066001)(6116002)(86362001)(2420400007)(7696004)(229853002)(15650500001)(81166006)(122556002)(76176999)(54356999)(7110500001)(189998001)(50986999)(33656002)(8936002)(6436002)(99286003)(8676002)(2950100002)(2501003)(102836003)(25786009)(53546009)(3660700001)(790700001)(10710500007)(478600001)(7906003)(74316002)(7736002)(54896002)(6306002)(236005)(6246003)(55016002)(9686003)(38730400002)(53936002)(2906002)(3280700002)(230783001)(5660300001)(606005); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2017 09:04:50.3212 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: a2-vu1R4PaSTwBMoiFiZmw-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB23507F3E3BC9B0DB19BE6D03B2EE0SN2PR03MB2350namp_" Archived-At: Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 09:05:06 -0000 --_000_SN2PR03MB23507F3E3BC9B0DB19BE6D03B2EE0SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable The same here. Thanks, Tolga From: Flemming Andreasen [mailto:fandreas@cisco.com] Sent: Friday, May 5, 2017 8:57 AM To: Christer Holmberg ; Asveren, Tolga ; mmusic@ietf.org Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC = 8035 Sounds reasonable to me -- Flemming (as individual) On 5/4/17 7:08 AM, Christer Holmberg wrote: Hi, I intend to move forward with option 2), and submit a new version of draft-= mux-exclusive. I.e., the draft will NOT update RFC 8035, but simply indicat= e that RFC 8035 updates the same section and moves the location of the para= graph updated by draft-mux-exclusive. Regards, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Tuesday 2 May 2017 at 14:09 To: Tolga Asveren >, "m= music@ietf.org" > Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC = 8035 Hi, >I got your point but that made me think about a more fundamental issue: Do= es draft-mux-exclusive indeed update RFC5761? >IMHO it is not. It defines a new indicator with its own semantics. This is= a new capability, not something changing a capability already defined. And >it seems "backward compatibility concerns" are already addressed in a reas= onable way by mux-exclusive and RFC8035 updates on RFC5761. > >So, I would: >i- Remove "Updates: RFC5761" statement from the prologue >ii- Remove Section 5. > >If you still want to keep rtcp-mux-exclusive as an "update on RFC5761", th= en 2) sounds reasonable to me as well. It was previously agreed to add the text to draft-mux-exclusive= , so I don't want to change that at this point. At the end of the day, it's= just a clarification specifying that if there is SOME mechanism to indicat= e that separate ports cannot be used, the stream must be disabled. Unfortun= ately, the RFC8035 update does not add such specification. Option 2) would be adding something like this to draft-mux-exclusive: "NOTE: RFC8035 also updates section 5.1.1 of RFC5761. While the paragraph u= pdated in this document is not updated by RFC8035, the location of the para= graph within section 5.1.1 is moved." Regards, Christer From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Tuesday, May 2, 2017 4:25 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, >i- "rtcp-mux-exclusive" is a new capability/indication, not an update on R= FC5761/8035 per se. >ii- RFC8035 updates RFC5761 so that rtcp-mux is used only as bidirectional= . >iii- rtcp-mux-exclusive is defined as bidirectional. > >Adding all these together, I fail to see the rationale behind the text. Therefore, I think "4) Do Nothing" is the way to go here. Note that the text is already in draft-mux-exclusive, and optio= n 4) would not remove it. The issue is that, based on the update in RFC8035, the text is no longer wi= thin the "4th paragraph", as RFC8035 adds new paragraphs, and my question i= s whether we should somehow point that out within draft-mux-exclusive. >OTOH, I still think that draft-mux-exclusive explicitly should indicate th= at "rtcp-mux-exclusive itself is bidirectional" and that RFC8035 updated RF= C5761 to clarify that "rtcp-mux is birectional". I think we should look at that suggestion (which, btw, I think seems reason= able) as a separate thing. THIS issue is more administrative. Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: Friday, April 28, 2017 5:57 AM To: mmusic@ietf.org Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035 Hi, draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also u= pdates section 5.1.1 of RFC 8035. draft-mux-exclusive keeps the existing text, and adds some new (= ). Update to 4th paragraph of section 5.1.1 OLD TEXT (RFC 5761): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. NEW TEXT (RFC 8035): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signalled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. As we can see, the original text is identical in 5761 and 8035. So, there i= s no clash. So far so good. draft-mux-exclusive keeps the existing text, and adds some new (= ). NEW TEXT (draft-mux-exclusive): If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer MUST NOT multiplex RTP and RTCP packets on a single port. Instead, it should send and receive RTCP on a port allocated according to the usual port-selection rules (either the port pair, or a signaled port if the "a=3Drtcp:" attribute [10] is also included). This will occur when talking to a peer that does not understand the "a=3Drtcp-mux" attribute. However, if the offerer indicated in the offer that it = is not able to send and receive RTCP on a separate port, the offerer MUST disable the media streams associated with the attribute. The mechanism for indicating that the offerer is not able to send and receive RTCP on a separate port is outside the scope of this specification. Now, the issue is that, following the update in RFC 8035, the text is no lo= nger within the 4th paragraph of section 5.1.1. So, should we: 1) within draft-mux-exclusive, indicate that both RFC 5761 and RFC 803= 5 are updated; or 2) within draft-mux-exclusive, add a note indicating which paragraph i= s affected following the update in RFC 8035 3) within draft-mux-exclusive, ONLY update RFC 8035; or 4) o nothing My first reaction would be to go for option 2), as there IMO is no reason t= o formally update the text in RFC 8035. Regards, Christer _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic --_000_SN2PR03MB23507F3E3BC9B0DB19BE6D03B2EE0SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

The same here.=

 

Thanks,<= /span>

Tolga

 

From:= Flemming Andreasen [mailto:fandreas@cisco= .com]
Sent: Friday, May 5, 2017 8:57 AM
To: Christer Holmberg <christer.holmberg@ericsson.com>; Asvere= n, Tolga <tasveren@sonusnet.com>; mmusic@ietf.org
Subject: Re: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive a= nd RFC 8035

 

Sounds reasonable to = me

-- Flemming (as individual)

On 5/4/17 7:08 AM, Christer Holmberg wrote:

Hi,

 

I intend to move forward with option 2), and submit = a new version of draft-mux-exclusive. I.e., the draft will NOT update RFC 8= 035, but simply indicate that RFC 8035 updates the same section and moves t= he location of the paragraph updated by draft-mux-exclusive.

 

Regards,

 

Christer

 

 

Hi,

 

>I got your point but that made me think about a = more fundamental issue: Does draft-mux-exclusive indeed update RFC5761?

>IMHO it is not. It defines a new indicator with = its own semantics. This is a new capability, not something changing a capab= ility already defined. And

>it seems= “backward compatibility concerns” are already addressed in a r= easonable way by mux-exclusive and RFC8035 updates on RFC5761.

> 

>So, I would:

>i- Remove “Updates: RFC5761” stateme= nt from the prologue

>ii- Remove Section 5.

> 

>If you still want to keep rtcp-mux-exclusive as = an “update on RFC5761”, then 2) sounds reasonable to me as well= .

 

It was previously a= greed to add the <new></new> text to draft-mux-exclusive, so I = don’t want to change that at this point. At the end of the day, it= 217;s just a clarification specifying that if there is SOME mechanism to indicate that separate ports cannot be used, the stream must = be disabled. Unfortunately, the RFC8035 update does not add such specificat= ion.

 

Option 2) would be = adding something like this to draft-mux-exclusive:

 

"NOTE: RFC8035= also updates section 5.1.1 of RFC5761. While the paragraph updated in this= document is not updated by RFC8035, the location of the paragraph within s= ection 5.1.1 is moved."

 

Regards,=

 

Christer=

 

 

 

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Tuesday, May 2, 2017 4:25 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: RFC 5761 updated by both draft-mux-exclusive and RFC 80= 35

 

Hi,

 <= /o:p>

>i- “rtcp-mux-exclusive” is a new cap= ability/indication, not an update on RFC5761/8035 per se.

>ii- RFC8035 updates RFC5761 so that rtcp-mux is = used only as bidirectional.

>iii- rtcp-mux-exclusive is defined as bidirectio= nal.

> 

>Adding all these together, I fail to see the rat= ionale behind the <new></new> text. Therefore, I think “4= ) Do Nothing” is the way to go here.

 

Note that the <n= ew></new> text is already in draft-mux-exclusive, and option 4) wo= uld not remove it. 

 <= /o:p>

The issue is that, = based on the update in RFC8035, the text is no longer within the “4th= paragraph”, as RFC8035 adds new paragraphs, and my question is wheth= er we should somehow point that out within draft-mux-exclusive.=

 <= /o:p>

>OTOH, I still think that draft-mux-exclusive exp= licitly should indicate that “rtcp-mux-exclusive itself is bidirectio= nal” and that RFC8035 updated RFC5761 to clarify that “rtcp-mux= is birectional”.

 <= /o:p>

I think we should l= ook at that suggestion (which, btw, I think seems reasonable) as a separate= thing. THIS issue is more administrative.

 <= /o:p>

Regards,

 <= /o:p>

Christer

 <= /o:p>

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, April 28, 2017 5:57 AM
To: mmusic@ietf.org
Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and R= FC 8035

 

Hi,
draft-mu=
x-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also updates s=
ection 5.1.1 of RFC 8035.
draft-mux-exclusive keeps the existing text, and adds some new=
 (<new></new>).
 
Update to 4th paragraph of section 5.=
1.1
 
 
OLD TEXT (RFC 5761):
 
   If the answer does not contain an "a=3Drtcp-mux"=
; attribute, the offerer
   MUST NOT multiplex RTP and RTCP packets on a single port.=
  Instead,
   it should send and receive RTCP on a port allocated accor=
ding to the
   usual port-selection rules (either the port pair, or a si=
gnalled port
   if the "a=3Drtcp:" attribute [10] is also inclu=
ded).  This will occur
   when talking to a peer that does not understand the "=
;a=3Drtcp-mux"
   attribute.
 
NEW TEXT (RFC 8035):
   If the answer does not cont=
ain an "a=3Drtcp-mux" attribute, the offerer
   MUST NOT multiplex RTP and RTCP packets on a single port.=
  Instead,
   it should send and receive RTCP on a port allocated accor=
ding to the
   usual port-selection rules (either the port pair, or a si=
gnalled port
   if the "a=3Drtcp:" attribute [10] is also inclu=
ded).  This will occur
   when talking to a peer that does not understand the "=
;a=3Drtcp-mux"
   attribute.
 
As we can see, the original text is iden=
tical in 5761 and 8035. So, there is no clash. So far so good.

draft-mux-exclusive keeps the existing t=
ext, and adds some new (<new></new>).


 


NEW TEXT (draft-mux-exclusive):


 


   If the answer does not contain an "a=3Drtcp-mux"=
; attribute, the offerer


   MUST NOT multiplex RTP and RTCP packets on a single port.=
  Instead,


   it should send and receive RTCP on a port allocated accor=
ding to the


   usual port-selection rules (either the port pair, or a si=
gnaled port


   if the "a=3Drtcp:" attribute [10] is also inclu=
ded).  This will occur


   when talking to a peer that does not understand the "=
;a=3Drtcp-mux"


   attribute. <new> However,=
 if the offerer indicated in the offer that it is


   not able to send and receive RT=
CP on a separate port, the offerer


   MUST disable the media streams =
associated with the attribute. The


   mechanism for indicating that t=
he offerer is not able to send and


   receive RTCP on a separate port=
 is outside the scope of this


   specification.</new>




 






Now, the issue is that, following the update in RFC 8035, the text is =
no longer within the 4th paragraph of section 5.1.1. So, should we:






 






1)      within draft-mux-exclusive, indicate that both RFC 5761 and RFC 8035 are u=
pdated; or






2)      with=
in draft-mux-exclusive, add a note indicating which paragraph is affected f=
ollowing the update in RFC 8035






3)      within draft-mux-exclusive, ONLY update RFC 8035; or






4)      o nothing






 






My first reaction would be to go for option 2), as there IMO is no rea=
son to formally update the text in RFC 8035. 






 






Regards,






 






Christer






 






 








_______________________________________________
mmusic mailing list
mmusic@ietf.org

https://www.i=
etf.org/mailman/listinfo/mmusic

 

--_000_SN2PR03MB23507F3E3BC9B0DB19BE6D03B2EE0SN2PR03MB2350namp_-- From nobody Mon May 8 02:07:22 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555E91287A3 for ; Mon, 8 May 2017 02:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 6CLuQTgDUj7R for ; Mon, 8 May 2017 02:07:20 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [63.128.21.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074B112783A for ; Mon, 8 May 2017 02:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=f7w8VFXQNaAg3RcOrdRsJgiEHgAi77eFmEmtBYdtAwM=; b=EN9Yv2s2yiTAzlBD0gPoFoxsTh0+/BX3mYRzFjNGE623Ocq1ISyPL9NOyX1WG+5dF+x7Z+b6pYLXsRzIf/dO1JLGdurrChYASzaIwB7IP7lSZu0VEOZnqQS6qhMT+A9/SaLyZo/rgVkPCDGtEcjb/gBgOdXrfW8+YTdPC3VoCZY= Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0117.outbound.protection.outlook.com [207.46.163.117]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-116-cPkKQvhnP4C4T9blSoScBw-1; Mon, 08 May 2017 05:07:17 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1075.11; Mon, 8 May 2017 09:07:15 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1075.019; Mon, 8 May 2017 09:07:15 +0000 From: "Asveren, Tolga" To: Bo Burman , "mmusic (mmusic@ietf.org)" Thread-Topic: Consensus call for adoption of draft-hutton-mmusic-opportunistic-negotiation-00 Thread-Index: AdLFpZOd/EvsNyttRoO7HypCm1zI/gCNMyLw Date: Mon, 8 May 2017 09:07:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:YCun894b7HuUVwMl63DAVe9gmla1gBZ1qhSJvSo0RjX3ybFQzQaCZnl8lOqSKB2JYuniF1CZ7Xr8+MBo9ks8caTA7lPFYxZUo4N+TfUA9TyBf7J125BIzqe51x/dFdeMj0DZjjAfhXuwYg0AwVGDL5FL8lRFdCGcJFgcu80vFvuN28NFOgQ9sIdG6axH6vC9ZEMwfz20QFQx5z0/s1YqVM4yta5fjMv2dxTTmL7O5n6J9XmuwANCEWPyfEZhL4l/APmHj2js+0YOjCRBf5cD4CPWh2YoiQrNFCsOcL2vOI/EVDzigMTDyMFFjPmGfTSvncNNZmoF5U2zU0OdUkPLpA==; 20:3sr2WdbHEtw/BxcROxpyBwpoyT8TftitjSgokrFJdUBboZnYK9qu3szz0UFzJOdyT7bPw5Bf5uyLu93Y/9ptt5XiWrsnx1NKcgdAFckfoPk/qE+f0Mj/cI6FSlWeGMuvuyIHoOAiAlV95XngzIJKWpu99yluilOcfkTxlQI7tUM= x-ms-office365-filtering-correlation-id: c7d81ad3-fe95-4f5b-0b26-08d495f19f44 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:SN2PR03MB2352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 0301360BF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39400400002)(39410400002)(39450400003)(39830400002)(377454003)(6506006)(77096006)(3846002)(66066001)(6116002)(86362001)(7696004)(229853002)(81166006)(122556002)(76176999)(54356999)(189998001)(50986999)(33656002)(8936002)(6436002)(99286003)(8676002)(2950100002)(102836003)(25786009)(53546009)(3660700001)(790700001)(478600001)(7906003)(74316002)(7736002)(54896002)(6306002)(236005)(6246003)(55016002)(9686003)(38730400002)(53936002)(2906002)(3280700002)(230783001)(19609705001)(5660300001)(606005); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2017 09:07:15.6615 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: cPkKQvhnP4C4T9blSoScBw-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB235033238A72BFDC6A91A03CB2EE0SN2PR03MB2350namp_" Archived-At: Subject: Re: [MMUSIC] Consensus call for adoption of draft-hutton-mmusic-opportunistic-negotiation-00 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 09:07:21 -0000 --_000_SN2PR03MB235033238A72BFDC6A91A03CB2EE0SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I support adopting this draft. It really would help to deal with some exist= ing problems in a practical way. Thanks, Tolga From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman Sent: Friday, May 5, 2017 10:04 AM To: mmusic (mmusic@ietf.org) Subject: [MMUSIC] Consensus call for adoption of draft-hutton-mmusic-opport= unistic-negotiation-00 MMUSIC, Based on the feedback we received at the IETF 98 meeting in Chicago, it see= ms there is strong consensus for adopting this draft in MMUSIC. This = mail starts a one-week consensus call to confirm that consensus. Please ans= wer to state your support or if you have any objections. Unless someone objects, we will ask for a milestone and adopt it as an MMUS= IC WG draft. Please answer before midnight UTC on May 12, 2017. /Bo MMUSIC co-chair --_000_SN2PR03MB235033238A72BFDC6A91A03CB2EE0SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

I support adopting this draft. It really would help = to deal with some existing problems in a practical way.

 

Thanks,

Tolga

 

From: mmusic [mailto:mmusic-bounces@ietf.org]= On Behalf Of Bo Burman
Sent: Friday, May 5, 2017 10:04 AM
To: mmusic (mmusic@ietf.org) <mmusic@ietf.org>
Subject: [MMUSIC] Consensus call for adoption of draft-hutton-mmusic= -opportunistic-negotiation-00

 

MMUSIC,

 

Based on the feedback we received at the IETF 98 mee= ting in Chicago, it seems there is strong consensus for adopting this draft in MMUSIC. This mail starts a one-week consensus call to con= firm that consensus. Please answer to state your support or if you have any= objections.

 

Unless someone objects, we will ask for a milestone = and adopt it as an MMUSIC WG draft.

 

Please answer before midnight UTC on May 12, 2017.

 

/Bo

MMUSIC co-chair

 

--_000_SN2PR03MB235033238A72BFDC6A91A03CB2EE0SN2PR03MB2350namp_-- From nobody Mon May 8 06:16:28 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DD7129467; Mon, 8 May 2017 06:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 lc983qMlS730; Mon, 8 May 2017 06:16:25 -0700 (PDT) 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 3CA8912946D; Mon, 8 May 2017 06:16:25 -0700 (PDT) X-AuditID: c1b4fb2d-b3dff7000000196b-53-59106fa6c0d8 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FD.08.06507.6AF60195; Mon, 8 May 2017 15:16:23 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.339.0; Mon, 8 May 2017 15:16:22 +0200 To: "mmusic (E-mail)" , "rtcweb@ietf.org" From: Magnus Westerlund Message-ID: Date: Mon, 8 May 2017 15:16:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkluLIzCtJLcpLzFFi42KZGbFdUXd5vkCkwa1eOYupyx+zWKz9187u wOSxZMlPpgDGKC6blNSczLLUIn27BK6M2RdPMhfc4ax4fukPYwNjM0cXIyeHhICJxM/zt5i6 GLk4hASOMErMa90E5SxjlGh7tJgVpEpEwEeic1U3E4jNJmAhcfNHI1sXIweHsICBxNXDUiBh XgF7iSt/N4GVswioSMxevZoZxBYViJFoWfKBEaJGUOLkzCcsIK3MQPUPtpaBhJkF5CWat84G KxcS0JZoaOpgncDIOwtJxyyEjllIOhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAyg g1t+6+5gXP3a8RCjAAejEg/vgxn8kUKsiWXFlbmHGCU4mJVEeLelCkQK8aYkVlalFuXHF5Xm pBYfYpTmYFES53XYdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwLjsyA7XKv+9EXlSM5y0gyYXxyil +eo5LjI+dGPhQwVl57wrt5vqv4Su3Z0w8+y+jaoS9qne5q+3q57XLTgiIPTrU5ZBdnDJwids ixV3fFVe6Jj3fvP5cyyX87MCq+WDm2xDYj/Lus417FXl/B5t6OJmoLyDZ0YIc/SfpCzR8nnz 17NufzN3nRJLcUaioRZzUXEiABoWZZYcAgAA Archived-At: Subject: [MMUSIC] AVTCORE discussion of extmap and BUNDLE X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 13:16:27 -0000 MMUSIC and RTCWeb, I would like to make you aware of an ongoing discussion around how the SDP attribute for RTP header extensions (a=extmap) should work with BUNDLE. This is going on in the context of the update of RFC5285: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5285-bis/ Thread start: https://www.ietf.org/mail-archive/web/avt/current/msg17531.html This discussion started as result of the SDP expert reviewer who noticed that we failed to take muxing into account for the SDP attributes. And extmap is non-trivial and classified as special. So far we agreed that clarificatio is needed, but we have not yet agreed to what clarifications and their impact. So please review the discussion and contribute on the AVTCORE mailing list. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Tue May 9 02:44:23 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DB2128BA2; Tue, 9 May 2017 02:44:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149432306204.23888.7508271969686658364.idtracker@ietfa.amsl.com> Date: Tue, 09 May 2017 02:44:22 -0700 Archived-At: Subject: [MMUSIC] The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state "Call For Adoption By WG Issued" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 09:44:22 -0000 The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state Call For Adoption By WG Issued (entered by Bo Burman) The document is available at https://datatracker.ietf.org/doc/draft-hutton-mmusic-opportunistic-negotiation/ Comment: Based on the feedback we received at the IETF 98 meeting in Chicago, it seems there is strong consensus for adopting this draft in MMUSIC. From nobody Tue May 9 08:08:20 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2187F12AF6E for ; Tue, 9 May 2017 08:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 MmiR3moZxtYV for ; Tue, 9 May 2017 08:08:16 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (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 D2084129487 for ; Tue, 9 May 2017 08:08:16 -0700 (PDT) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-10v.sys.comcast.net with SMTP id 86jxdRgId61D986kKdZR0S; Tue, 09 May 2017 15:08:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1494342496; bh=UyM6GMsC1WfIWxz5Cu4MobKhvHzCBOJLQZoXIWe0zvE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=awE9hwC46Oq6A/MPxeb1BQzO2OVYQxUzIaVgCxwTHiTMZX2WHUPiOSo3ajhB/4TpH +xJftj27LPRO0/Ruxcv2sRDdhy0JFmX9vz+JpWjMzUvOST9yvcRXgZcJccS/TJS0PX jDv6x9EzVhGdu4i7UasWlqFJIVxUp4BHXfOSvMPTpgBR1VsY5I3CaqoTRVfRzxlYI4 iIbBduFurydS9dEKFXJLhhDSZwLxOzEyXdzKdvcphVIqNXSu+fKyRhKo63mIFodd4X NGDBZi4VyKm5PVfNa6D9H8Pcw5hYTcL4pLR2WZlxWulF8/ZAFLgYl6ZQbm58pKXzG9 kGq/ZLOxoGAww== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-15v.sys.comcast.net with SMTP id 86kJdmVtnXTPj86kJd5Uj0; Tue, 09 May 2017 15:08:16 +0000 To: mmusic@ietf.org References: <149432306204.23888.7508271969686658364.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Tue, 9 May 2017 11:08:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149432306204.23888.7508271969686658364.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJJmRl6VbzMDenGSG/YnXAm33x6ERJpGEMmdS1fWsZy0GRFO/AAUSXkZhaPB2WkA3UqQEg0o3ikWjIyz8haVgUT1SHRA3wlVRkbPfr16fgHS3c5MtduS W+2qPmoLvDS3EoLGohfTI7bVy2iz1P1jaKXageVH+gZVLU/0Xmv6qPbq Archived-At: Subject: Re: [MMUSIC] The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state "Call For Adoption By WG Issued" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 15:08:18 -0000 On 5/9/17 5:44 AM, IETF Secretariat wrote: > > The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in > state > Call For Adoption By WG Issued (entered by Bo Burman) > > The document is available at > https://datatracker.ietf.org/doc/draft-hutton-mmusic-opportunistic-negotiation/ > > > Comment: > Based on the feedback we received at the IETF 98 meeting in Chicago, it > seems there is strong consensus for adopting this draft in MMUSIC. I don't understand why both this draft and draft-ietf-sipbrandy-osrtp are needed. Wouldn't one draft do? Thanks, Paul From nobody Tue May 9 10:13:15 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25818127735 for ; Tue, 9 May 2017 10:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 31Y1drQuaF7M for ; Tue, 9 May 2017 10:13:11 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71FBC1294DC for ; Tue, 9 May 2017 10:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1248; q=dns/txt; s=iport; t=1494349990; x=1495559590; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jDwRHKwCMFwujPvRD3VWaaMRYfNe2JMnCUHBQHE38wA=; b=RBs+aepCCMZZw8lfwKNiJujOrhT1+qB3InI1REwJ7tDckr1QWt1DhlaL gv/n+sLPSNSYb5EP0zg4rJi4lCIJaxP5PEJQl3psSAzjrwZBc7pUk4Us7 g3OzqeQpbhxxm4UBQKNM0OaU2PnoFASaGVVaQor40IFcJQNFX/kToWxru c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AAD39xFZ/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHjXqRNiGVcoIPIQ2FLEoChGw/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEBARsdNAsFCwIBCBgeBQsnCyUCBA4FigkDDQgOtQaHLAiDPQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFhl+BXisLgmWEY4M4gjEFngUBhxuLfQuRYJQ/AR8?= =?us-ascii?q?4gQpwFUYSAYUWgUp2h2eBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,315,1491264000"; d="scan'208";a="419005365" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2017 17:13:09 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v49HD9ct013378 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2017 17:13:09 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 May 2017 12:13:08 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Tue, 9 May 2017 12:13:08 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat CC: "mmusic (E-mail)" Thread-Topic: [MMUSIC] The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state "Call For Adoption By WG Issued" Thread-Index: AQHSyNZ5p+Z17tlesUCxfMRqW+zzXqHskTMA Date: Tue, 9 May 2017 17:13:08 +0000 Message-ID: References: <149432306204.23888.7508271969686658364.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.212.167] Content-Type: text/plain; charset="us-ascii" Content-ID: <02041A1C7985684D98AF713756FA56F7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state "Call For Adoption By WG Issued" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 17:13:13 -0000 SIPBRANDY WG is not chartered to produce PS specs, which the original draft= (draft-ietf-sipbrandy-osrtp) would have been since it was updating a curre= nt PS. The WG made the decision (vetted by AD and IESG) to not re-charter a= nd instead decided split off the piece that updates a PS into a new PS (dra= ft-hutton-mmusic-opportunistic-negotiation). -G > On May 9, 2017, at 11:08 AM, Paul Kyzivat wrot= e: >=20 > On 5/9/17 5:44 AM, IETF Secretariat wrote: >>=20 >> The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation i= n >> state >> Call For Adoption By WG Issued (entered by Bo Burman) >>=20 >> The document is available at >> https://datatracker.ietf.org/doc/draft-hutton-mmusic-opportunistic-negot= iation/ >>=20 >>=20 >> Comment: >> Based on the feedback we received at the IETF 98 meeting in Chicago, it >> seems there is strong consensus for adopting this draft in MMUSIC. >=20 > I don't understand why both this draft and draft-ietf-sipbrandy-osrtp are= needed. Wouldn't one draft do? >=20 > Thanks, > Paul >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Tue May 9 10:28:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF9F12EAA7 for ; Tue, 9 May 2017 10:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 Xv0TFjVD0OwV for ; Tue, 9 May 2017 10:28:38 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 B5A3812E05D for ; Tue, 9 May 2017 10:28:38 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-08v.sys.comcast.net with SMTP id 88vDdFyBrAfZs88wAdRA9E; Tue, 09 May 2017 17:28:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1494350918; bh=yJzSrcrvYFJzhcbFDOZt3yqL2SOzok2nPUM3zHwDvxA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=X7ny9Coq3lUi1cPnBGVFH4xaq8cbEmtEnyEsDhayIMCc4RI1LvP1vNwZPSUO5IUKU ElWH0tEvzKSxddDBcTMGNQyj+bpb/CDw4WquJTvISe//xUf0bQx91L/LdVYXpBGAdk tRG96r0r+MX4kH2n88LeiYh3GI1/uCzwfbwnjCDMUAyYlFt6o/ILVBmY0cksOazRsa GVrNEREaxfcEf9IqQM8HLoJu66z3NWIWx72X9LHE8vRbuyZy/jOfDmte4ZPp73cGEF 9lEZL0TEctY2PP6kpCCpEvT5GS9GrJSlEKBYNwQoUa5U5Vzl4dTZRMtls+i0BhmSRA 4iWP18LJCEGwg== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-06v.sys.comcast.net with SMTP id 88w9dqygOeyvG88w9dlKrD; Tue, 09 May 2017 17:28:37 +0000 To: "Gonzalo Salgueiro (gsalguei)" References: <149432306204.23888.7508271969686658364.idtracker@ietfa.amsl.com> Cc: "mmusic (E-mail)" From: Paul Kyzivat Message-ID: <66434d8c-1e4f-c401-c5ba-83eada18d372@comcast.net> Date: Tue, 9 May 2017 13:28:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfEKQsB2gFeAiNL97WGwzoYZkRUJ/Zoer2eNGAtZNrO4Q1COB5zEvLgTT+xj2wLTI2WqBJD8vYlw/h7FDQ+EtXeDkwYwNhZCPB18/ExZmx8jokC5/7xF7 Zst6YxEK+Wck6M8SBkNWNLTOr1+VttoaCdZ2E8XlrBuv6mElzOpDHG/zOQq9vMemIAzFiNWlZpnqGYiW18W6NbVjMYI/xW5uHIA= Archived-At: Subject: Re: [MMUSIC] The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state "Call For Adoption By WG Issued" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 17:28:44 -0000 On 5/9/17 1:13 PM, Gonzalo Salgueiro (gsalguei) wrote: > SIPBRANDY WG is not chartered to produce PS specs, which the original draft (draft-ietf-sipbrandy-osrtp) would have been since it was updating a current PS. The WG made the decision (vetted by AD and IESG) to not re-charter and instead decided split off the piece that updates a PS into a new PS (draft-hutton-mmusic-opportunistic-negotiation). OK. But then couldn't everything be put into the MMUSIC document? ISTM that given the limited content in these documents that splitting it into two, with a lot of overlap, is confusing. Thanks, Paul > -G > >> On May 9, 2017, at 11:08 AM, Paul Kyzivat wrote: >> >> On 5/9/17 5:44 AM, IETF Secretariat wrote: >>> >>> The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in >>> state >>> Call For Adoption By WG Issued (entered by Bo Burman) >>> >>> The document is available at >>> https://datatracker.ietf.org/doc/draft-hutton-mmusic-opportunistic-negotiation/ >>> >>> >>> Comment: >>> Based on the feedback we received at the IETF 98 meeting in Chicago, it >>> seems there is strong consensus for adopting this draft in MMUSIC. >> >> I don't understand why both this draft and draft-ietf-sipbrandy-osrtp are needed. Wouldn't one draft do? >> >> Thanks, >> Paul >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > From nobody Tue May 9 10:35:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5A412EAA5 for ; Tue, 9 May 2017 10:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 EPxPLuLTFyGX for ; Tue, 9 May 2017 10:35:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20681129511 for ; Tue, 9 May 2017 10:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2061; q=dns/txt; s=iport; t=1494351341; x=1495560941; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fvrhnUlT1y7o8Aew3JQvU2V/6FuZ+GqhCe2vgT9gQGU=; b=j/8dxkU8Cg3KgRbPPYxxCrn68RRSyKDk/P43hQzIeTm/2BhKxi2ie98R paSPpp1rENEoj4O/J1lxHchql8Y3LttE+ahS/I8x2Y4c0HFZsh0UILRHP 7JFTj/9XZEpzi+QpzkqzWGff6QNDt6yUetYH2EVFWLoZuYLXQnXFurqA9 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AAC3/BFZ/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1VigQwHjXqRNSGVcoIPIQ2FLEoChGw/GAECAQEBAQEBAWsohRU?= =?us-ascii?q?BAQEBAgEBARsdNAsFCwIBCBgeBQsnCyUCBA4FigkDDQgOtROHKwiDPQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFhl+BXisLgmWEPySDOIIxBZ4FAYcbgQOKeoIEj2e?= =?us-ascii?q?UPwEfOIEKcBVGEgGFFoFKdoY3gTCBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.38,315,1491264000"; d="scan'208";a="243186368" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2017 17:35:40 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v49HZddG003014 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2017 17:35:39 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 May 2017 12:35:39 -0500 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Tue, 9 May 2017 12:35:39 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Paul Kyzivat CC: "mmusic (E-mail)" Thread-Topic: [MMUSIC] The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state "Call For Adoption By WG Issued" Thread-Index: AQHSyNZ5p+Z17tlesUCxfMRqW+zzXqHskTMAgAAEUgCAAAH3AA== Date: Tue, 9 May 2017 17:35:39 +0000 Message-ID: References: <149432306204.23888.7508271969686658364.idtracker@ietfa.amsl.com> <66434d8c-1e4f-c401-c5ba-83eada18d372@comcast.net> In-Reply-To: <66434d8c-1e4f-c401-c5ba-83eada18d372@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.212.167] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [MMUSIC] The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state "Call For Adoption By WG Issued" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 17:35:43 -0000 > On May 9, 2017, at 1:28 PM, Paul Kyzivat wrote= : >=20 > On 5/9/17 1:13 PM, Gonzalo Salgueiro (gsalguei) wrote: >> SIPBRANDY WG is not chartered to produce PS specs, which the original dr= aft (draft-ietf-sipbrandy-osrtp) would have been since it was updating a cu= rrent PS. The WG made the decision (vetted by AD and IESG) to not re-charte= r and instead decided split off the piece that updates a PS into a new PS (= draft-hutton-mmusic-opportunistic-negotiation). >=20 > OK. But then couldn't everything be put into the MMUSIC document? > ISTM that given the limited content in these documents that splitting it = into two, with a lot of overlap, is confusing. I see your point but Currently SIPBRANDY is chartered to produce Opportunis= tic SRTP as a BCP. There is also a milestone to inform MMUSIC or other appr= opriate WGs of any changes needed to support Opportunistic SRTP (Not expect= ed to be published as an RFC). I think SIPBRANDY is just carrying out what= they are chartered to do. -G >=20 > Thanks, > Paul >=20 >> -G >>=20 >>> On May 9, 2017, at 11:08 AM, Paul Kyzivat wr= ote: >>>=20 >>> On 5/9/17 5:44 AM, IETF Secretariat wrote: >>>>=20 >>>> The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation= in >>>> state >>>> Call For Adoption By WG Issued (entered by Bo Burman) >>>>=20 >>>> The document is available at >>>> https://datatracker.ietf.org/doc/draft-hutton-mmusic-opportunistic-neg= otiation/ >>>>=20 >>>>=20 >>>> Comment: >>>> Based on the feedback we received at the IETF 98 meeting in Chicago, i= t >>>> seems there is strong consensus for adopting this draft in MMUSIC. >>>=20 >>> I don't understand why both this draft and draft-ietf-sipbrandy-osrtp a= re needed. Wouldn't one draft do? >>>=20 >>> Thanks, >>> Paul >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >>=20 >=20 From nobody Wed May 10 08:09:41 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0471294A2 for ; Wed, 10 May 2017 08:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.822 X-Spam-Level: X-Spam-Status: No, score=-11.822 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 6tJPK2ERywY0 for ; Wed, 10 May 2017 08:09:38 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FCA129490 for ; Wed, 10 May 2017 08:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=612; q=dns/txt; s=iport; t=1494428978; x=1495638578; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=7sm6mP4YffhtxkCu8+Jj/UZZXqKtzdqA2Tv6l0384u4=; b=eCVABM6uozcN5XUDGNnqDIb+x+dAKBI/pN9WYfkbRZjgNlVbZc4D1fTU mgpfzckFcPGTIp56dYElSrMyxdwVi7UxFJwNn20kWuusEE1Nz6KvsA6jO 77mSJmj93qKTQRK5qbR2zOgAHFV65aTv5ajRUmMnH1vUj+6l0UqEI6ZAK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BaAQAyLBNZ/5NdJa1dGwEBAQMBAQEJA?= =?us-ascii?q?QEBg1VigQyDaYoYp0qCDyyKej8YAQIBAQEBAQEBayiFPxU2QAIfBwJfDQgBAYo?= =?us-ascii?q?QDQ6iVpALgiaKcwEBAQEGAQEBAR8FgQuFVIIJimGCYAEEngqTG4FsGIU7g0OGa?= =?us-ascii?q?ZRDHziBCk8hFUaFK4FmJDYBiRgBAQE?= X-IronPort-AV: E=Sophos;i="5.38,320,1491264000"; d="scan'208";a="422344453" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2017 15:09:37 +0000 Received: from [10.98.149.197] (bxb-fandreas-8814.cisco.com [10.98.149.197]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v4AF9aPH003058 for ; Wed, 10 May 2017 15:09:37 GMT From: Flemming Andreasen To: mmusic Message-ID: <6f9c4cde-2f92-1d10-15a1-d3a4dff24345@cisco.com> Date: Wed, 10 May 2017 11:09:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] WG Interest in Unknown Key Share Attacks and poll for adoption of draft-thomson-mmusic-sdp-uks-00 as WG draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:09:39 -0000 Greetings MMUSIC The topic of Unknown Key Share Attacks on TLS with SDP has been discussed on the mailing list more recently and it was also presented at the Chicago IETF. Based on that, we would like to 1) Poll the WG for interest in this work, including willingness to actively participate in and/or review this work 2) Assuming sufficient interest, ask if people would like to adopt https://www.ietf.org/id/draft-thomson-mmusic-sdp-uks-00.txt as a starting point for such work. Please send your reply to the mailing list by May 24, 2018. Thanks -- Flemming & Bo (MMUSIC chairs) From nobody Wed May 10 10:53:13 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50AB12DDD2 for ; Wed, 10 May 2017 10:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 L-27pfaVAsKJ for ; Wed, 10 May 2017 10:53:08 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (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 84DC512E03E for ; Wed, 10 May 2017 10:53:08 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id j29so2740093qtj.1 for ; Wed, 10 May 2017 10:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O7eOLEJLGDRsr16O/Pm0FpMjbRSKsxMEjcmchv2C6H8=; b=gZ92USmyv8vxMbC/HjBgG6AXkEIjDU7gUTpVPPJDip3caoipNRl4zZMpa+g6ZsA2gt v5+zvBMatdLGQBVyLpilW0JinmxmAkcnMu21OWax68YLlkmuZHyx/bfqy+26UgCzGFXe IM2viqyQ0BJ5y1mLafAFpRP5bdl/c7ViVThiwj9LJYitOvTm14yccERB8OnRzpiLch4c aNVA4GxdRzZGUKddit8V/TULBBb1V7G6wVHiUZaarWL2YkGkr4Z7fLuRb/LUai3O1WQ+ FeSwUdMs+K0zpAz4iQTCivxemGZo8FzOR9/Yw8IOP60cMqRXpX8FOnsnPmdJK6jDoIBe XI0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=O7eOLEJLGDRsr16O/Pm0FpMjbRSKsxMEjcmchv2C6H8=; b=HGUcyIVLDb3FJb6LC/T0F7m69CYeVRlOn/3K3j/ScAqhnTio/mBsld2+yXebCXxl0o 9twCmz1aMig/OYCz2prZBN5fl3SKAizf0kaPIQ9b9yW4o8qWjtmZshfazyzWKnndGR6/ /9Ue2KODTT/R/Sl7NqYZBn+T2CaFR46g8d/kTXTTam4YbqpduvJ3JRlE4YwyG7JmFpTV RZGaPSo8klUKNjtq+eiWNmuHQrkOv1Re0BaM3vrQpURmAJWwe4BfpHnI0g7VynJzMy8i xVe1M/lN8lBJvUbUSttuf8tJRd5xAAYLEGzdW43TNQgmvAHE4uB0BPjoHNJIrKxKBtNe vdiA== X-Gm-Message-State: AODbwcBWpNN01Z2nsOPXNiT2x64Uobb9iP+N1lbl20F/bZjnCzhzT5Th 2pRUT2vItYTw0l2+R/Tb9SqVYu9CSg== X-Received: by 10.200.52.165 with SMTP id w34mr6946335qtb.77.1494438787762; Wed, 10 May 2017 10:53:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.47.5 with HTTP; Wed, 10 May 2017 10:53:07 -0700 (PDT) In-Reply-To: <6f9c4cde-2f92-1d10-15a1-d3a4dff24345@cisco.com> References: <6f9c4cde-2f92-1d10-15a1-d3a4dff24345@cisco.com> From: Suhas Nandakumar Date: Wed, 10 May 2017 10:53:07 -0700 Message-ID: To: Flemming Andreasen Cc: mmusic Content-Type: multipart/alternative; boundary=001a113f523e15502c054f2f2516 Archived-At: Subject: Re: [MMUSIC] WG Interest in Unknown Key Share Attacks and poll for adoption of draft-thomson-mmusic-sdp-uks-00 as WG draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 17:53:12 -0000 --001a113f523e15502c054f2f2516 Content-Type: text/plain; charset=UTF-8 I support adopting this and am willing to participate. Thanks Suhas On Wed, May 10, 2017 at 8:09 AM, Flemming Andreasen wrote: > Greetings MMUSIC > > The topic of Unknown Key Share Attacks on TLS with SDP has been discussed > on the mailing list more recently and it was also presented at the Chicago > IETF. Based on that, we would like to > > 1) Poll the WG for interest in this work, including willingness to > actively participate in and/or review this work > > 2) Assuming sufficient interest, ask if people would like to adopt > https://www.ietf.org/id/draft-thomson-mmusic-sdp-uks-00.txt as a starting > point for such work. > > > Please send your reply to the mailing list by May 24, 2018. > > Thanks > > -- Flemming & Bo (MMUSIC chairs) > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a113f523e15502c054f2f2516 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support adopting this and am willing to participate.

Thanks
Suhas

On Wed, May 10, 2017 at 8:0= 9 AM, Flemming Andreasen <fandreas@cisco.com> wrote:
Greetings MMUSIC

The topic of Unknown Key Share Attacks on TLS with SDP has been discussed o= n the mailing list more recently and it was also presented at the Chicago I= ETF. Based on that, we would like to

1) Poll the WG for interest in this work, including willingness to actively= participate in and/or review this work

2) Assuming sufficient interest, ask if people would like to adopt https://www.ietf.org/id/draft-thomson-mmusi= c-sdp-uks-00.txt as a starting point for such work.


Please send your reply to the mailing list by May 24, 2018.

Thanks

-- Flemming & Bo (MMUSIC chairs)


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

--001a113f523e15502c054f2f2516-- From nobody Wed May 10 11:43:50 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3DC129C37 for ; Wed, 10 May 2017 11:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 seBuoa-d7dbi for ; Wed, 10 May 2017 11:43:47 -0700 (PDT) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 EF03512951F for ; Wed, 10 May 2017 11:43:46 -0700 (PDT) Received: by mail-pf0-x234.google.com with SMTP id e64so1959370pfd.1 for ; Wed, 10 May 2017 11:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oEi5FkNNV+labLRF2OHF3mtcGgt5ZJHXWsf8LQFUbEU=; b=G93TdCwtRx0u69hG6E9zjE7CanfEFPjA71QXcCPyBjY9i7POlcyZ3W4e/DW++1cHdK +2Qz3pAg/CuRKQmf5BAr8a8WorkEWMpKXx8V9DTRDvC4m0g1NnOha5CitdOh+fp4OQrw otOM49oMMk7X9QmGb/TKZrpfsj6hEPWSleFU4NfJ3fJjMCT1BvHgbdOKotLtOF52VmLc 0RN0SJud02iGduyagKbXs02Zt1KBCtYKw0ULyFpAcaPnTWzB0nI0NQZIgIhS/1z3kTbK Bu7yQazJgeCg9EjY7xEtlneTR/Oo2ijAXTra5fRcOwlyGF5MoQkFAFEJMW3mRi1l53yA aQNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oEi5FkNNV+labLRF2OHF3mtcGgt5ZJHXWsf8LQFUbEU=; b=SrrbHL8DB/WoMkRveog23HaVF5GnLZXRUYXKSbafJ4u8Ca0NTxXNjuN++8A4l5zJvo zYbAN1AIRHiXZs4NpK9zEX4PClSCjGrTmUS8ROFrd1F9u7Fphsh/NfB9xHQr/poXeqCB KstfUTsjYho7BHe+xYsVBsU0eEFsJ9LzD9TEuL4hfVR+oHRWNKkn0p+l46Yuad3IbgaF vIo6B8JGA7XK/GY4b02oVZ/XBNLHtciu6d8M3oJS6Decp57jWNmAPZkL9w6p3Q/p1gSe OXhb8qQGWq3uTSY5mxUmiQ5P6AFzuwNb4SpznBFZzGgrAKApzUukx8XLaGeua9srEdN8 KXaA== X-Gm-Message-State: AODbwcDa7bz/ymLj14ct2o5vp4+HVRCRp01ZRPxx0jbWk8pQz0cP0WSx FnrktxXWkXDrvdp+ X-Received: by 10.84.151.3 with SMTP id i3mr10117617pli.29.1494441826378; Wed, 10 May 2017 11:43:46 -0700 (PDT) Received: from mail-pf0-f171.google.com (mail-pf0-f171.google.com. [209.85.192.171]) by smtp.gmail.com with ESMTPSA id u74sm7330110pfk.58.2017.05.10.11.43.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 May 2017 11:43:45 -0700 (PDT) Received: by mail-pf0-f171.google.com with SMTP id m17so1899927pfg.3 for ; Wed, 10 May 2017 11:43:45 -0700 (PDT) X-Received: by 10.99.147.67 with SMTP id w3mr7980530pgm.145.1494441825436; Wed, 10 May 2017 11:43:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.150 with HTTP; Wed, 10 May 2017 11:43:44 -0700 (PDT) In-Reply-To: <6f9c4cde-2f92-1d10-15a1-d3a4dff24345@cisco.com> References: <6f9c4cde-2f92-1d10-15a1-d3a4dff24345@cisco.com> From: Roman Shpount Date: Wed, 10 May 2017 14:43:44 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Flemming Andreasen Cc: mmusic Content-Type: multipart/alternative; boundary=f403045c604a248eed054f2fda31 Archived-At: Subject: Re: [MMUSIC] WG Interest in Unknown Key Share Attacks and poll for adoption of draft-thomson-mmusic-sdp-uks-00 as WG draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 18:43:49 -0000 --f403045c604a248eed054f2fda31 Content-Type: text/plain; charset=UTF-8 I support adopting this draft. _____________ Roman Shpount On Wed, May 10, 2017 at 11:09 AM, Flemming Andreasen wrote: > Greetings MMUSIC > > The topic of Unknown Key Share Attacks on TLS with SDP has been discussed > on the mailing list more recently and it was also presented at the Chicago > IETF. Based on that, we would like to > > 1) Poll the WG for interest in this work, including willingness to > actively participate in and/or review this work > > 2) Assuming sufficient interest, ask if people would like to adopt > https://www.ietf.org/id/draft-thomson-mmusic-sdp-uks-00.txt as a starting > point for such work. > > > Please send your reply to the mailing list by May 24, 2018. > > Thanks > > -- Flemming & Bo (MMUSIC chairs) > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --f403045c604a248eed054f2fda31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I support adopting this draft.

_____________
Roman Shpount

On Wed, May 10, 2017 at 11:09 AM, Flemming A= ndreasen <fandreas@cisco.com> wrote:
Greetings MMUSIC

The topic of Unknown Key Share Attacks on TLS with SDP has been discussed o= n the mailing list more recently and it was also presented at the Chicago I= ETF. Based on that, we would like to

1) Poll the WG for interest in this work, including willingness to actively= participate in and/or review this work

2) Assuming sufficient interest, ask if people would like to adopt https://www.ietf.org/id/draft-thomson-mmusi= c-sdp-uks-00.txt as a starting point for such work.


Please send your reply to the mailing list by May 24, 2018.

Thanks

-- Flemming & Bo (MMUSIC chairs)


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

--f403045c604a248eed054f2fda31-- From nobody Wed May 10 12:41:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4915E12EAAE for ; Wed, 10 May 2017 12:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 bwbTbLsaxzyx for ; Wed, 10 May 2017 12:40:51 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 E0C0D12EAB5 for ; Wed, 10 May 2017 12:40:30 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id l135so3018661ywb.2 for ; Wed, 10 May 2017 12:40:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=50uOctnhX2J0/SiHrk9Y3EmFLrlxaEAzGBWqEMDsQZI=; b=lA6vL1321hHnRy0p4AeWliQLIhgkGL8+VYBpltJ4Kb0VsmpvG278VLGvbqKKEiRaav Pi9JxNOGbAm6oJUIp41qquQ3n2As+3wU68IV+fx4HgwP9lgxYHIL+diDj/8nynYUW5b2 pztN1AgsDuBlEcAUI8Kr8RNlOMRFKrH5HAXFR2JElqv34UoC91wuAkpEgZ4k87SBRSoV C0vetjnqOebCasOb+zNx8dUnE50VMpebQBU1Ci6meZ1HxuFz2R23hQ18y3rP4D0zIDQg PrtbTtypvC4av+2ou9URWC5MuOTODKCExVsviUMCN46vTL21W69KXrSpc1PEnYx9Yo57 aN5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=50uOctnhX2J0/SiHrk9Y3EmFLrlxaEAzGBWqEMDsQZI=; b=UHWaUU0wZMNHo2ce1sQza59aRIw0S2zaV3L19LIArRLgGGYwF2t3/gXQPs6DpryL07 Zt9HQx5ztYbO7uIsd8R0UwaF9wrVftnyXAFVSdW0jmxSSwEMCeeSTWrbNP9Q4t7OkrNj 7KLPeOWAbQ3ocpfcFQPENixjFvvVI8S/6T80CsBaPu1wmQeWusQHI/AStEeTgLvQKni9 NxbzR7mTmBQGwFlTZ43ATNcfhP0rPMWKLp4bp96Sfw8A/h8H/g2lbYd5lCcFyvjloTpu Xjz80fl1Z8qxZI/4Jml7/gwcLzqcEvN4gnVjZIefM71c2t/KCTltBIOt8lGNeK7wTuzc 2vMA== X-Gm-Message-State: AODbwcD3mqfGmXV5tKADmg473ZJ3GxBL3t02RPEeHVJcqqlLlsLr5/Xr b5qR9XmgOWpQqZ1+Ux4VRkO3Ds5Hbw== X-Received: by 10.129.146.210 with SMTP id j201mr6541645ywg.3.1494445230103; Wed, 10 May 2017 12:40:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Wed, 10 May 2017 12:39:49 -0700 (PDT) In-Reply-To: References: <6f9c4cde-2f92-1d10-15a1-d3a4dff24345@cisco.com> From: Eric Rescorla Date: Wed, 10 May 2017 12:39:49 -0700 Message-ID: To: Roman Shpount Cc: Flemming Andreasen , mmusic Content-Type: multipart/alternative; boundary=94eb2c092a4013d1c9054f30a5cd Archived-At: Subject: Re: [MMUSIC] WG Interest in Unknown Key Share Attacks and poll for adoption of draft-thomson-mmusic-sdp-uks-00 as WG draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 19:40:53 -0000 --94eb2c092a4013d1c9054f30a5cd Content-Type: text/plain; charset=UTF-8 +1 On Wed, May 10, 2017 at 11:43 AM, Roman Shpount wrote: > I support adopting this draft. > > _____________ > Roman Shpount > > On Wed, May 10, 2017 at 11:09 AM, Flemming Andreasen > wrote: > >> Greetings MMUSIC >> >> The topic of Unknown Key Share Attacks on TLS with SDP has been discussed >> on the mailing list more recently and it was also presented at the Chicago >> IETF. Based on that, we would like to >> >> 1) Poll the WG for interest in this work, including willingness to >> actively participate in and/or review this work >> >> 2) Assuming sufficient interest, ask if people would like to adopt >> https://www.ietf.org/id/draft-thomson-mmusic-sdp-uks-00.txt as a >> starting point for such work. >> >> >> Please send your reply to the mailing list by May 24, 2018. >> >> Thanks >> >> -- Flemming & Bo (MMUSIC chairs) >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --94eb2c092a4013d1c9054f30a5cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Wed, May 10, 2017 at 11:43 AM, Roman Shpount &= lt;roman@telurix.com= > wrote:
I= support adopting this draft.

_____________
Roman Shpount

On Wed, May 10, 2017 at 11:09 AM, Flemming A= ndreasen <fandreas@cisco.com> wrote:
Greetings MMUSIC

The topic of Unknown Key Share Attacks on TLS with SDP has been discussed o= n the mailing list more recently and it was also presented at the Chicago I= ETF. Based on that, we would like to

1) Poll the WG for interest in this work, including willingness to actively= participate in and/or review this work

2) Assuming sufficient interest, ask if people would like to adopt https://www.ietf.org/id/draft-thomson-mmusi= c-sdp-uks-00.txt as a starting point for such work.


Please send your reply to the mailing list by May 24, 2018.

Thanks

-- Flemming & Bo (MMUSIC chairs)


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


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

--94eb2c092a4013d1c9054f30a5cd-- From nobody Wed May 10 14:10:57 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F4C129505 for ; Wed, 10 May 2017 14:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QEHF3yAEOkVC for ; Wed, 10 May 2017 14:10:55 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 D42B8128D2E for ; Wed, 10 May 2017 14:10:54 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id u65so18134024wmu.1 for ; Wed, 10 May 2017 14:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DgKcoS8Yt8PEUo5J/uIzka2Uj/hq/Rvd3BgAwsJ8zo4=; b=qJLVOfB/I2dSR1TcDsY1ULYJyj4d/E1qZRAzJVJXWRPh7PbonnRjx37U1XPSwZ7gNr 5HU+0lzPZYN/9iowLW/RTY4s65SszB8xBl025w9JQr/cB+2IiIBb+1xD1eqaNc0Kqj+L Rxz6t4W4ZSUf8X4+R8YaQ4Y93nupxCInMScZcgZDADNvBCanyp91YmjPtzGbbgT5bzpI 1AgtwS3nK/ABTdzjDPS7s1TMy1BRgr/Rgg8Qdp4PBZgtiusL6lwfWD1MIdM0ToE2quQB GJY7eCMD38nK4+c1ZyCmYkoppBmkEIT8R5DnEJNbKTaxD+PmLdKfvhNxQpJQVnUPIuvA vSLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DgKcoS8Yt8PEUo5J/uIzka2Uj/hq/Rvd3BgAwsJ8zo4=; b=CNaseddabEAatKafVLfypHwsRXR+nsmjfHaSNh/SmAZuYvVNAo3aeKwGX8UckZ6fHT V+U8hgk9cfBTDHB8PJ4ULOxKVuK52ECTX5Q8kYj6oA5XnIXv1cM0iL2xF3ZI3HFtFPtr 7ctsTCyVffOTzFa06WEgB8feOVJRUAohJQh7sB0wvyQGPlrl7YhE0zlF0QcewyOxrYcr /XE38/ICH8NJ0razQELeFuyN8DzzzD38Lwr08cR63oKvjRnUyT40bI/QUTVN9vTj73gB oqW3hIMyoI0g1iI1ZnU/P75CQZlG9nChWqdkROWrAnlD8hmPfEuEZnZxp7NlknU7GIRC jASw== X-Gm-Message-State: AODbwcD6k7/v5pmJrg2YhYhYJDHwmSvd/XF8UKZHWnsbQ/IG8KRlauya oHHlgSIAfKLy8P4jSopof6VJlacQRQ== X-Received: by 10.25.158.147 with SMTP id h141mr3973994lfe.130.1494450653253; Wed, 10 May 2017 14:10:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Wed, 10 May 2017 14:10:52 -0700 (PDT) In-Reply-To: References: <6f9c4cde-2f92-1d10-15a1-d3a4dff24345@cisco.com> From: Martin Thomson Date: Thu, 11 May 2017 07:10:52 +1000 Message-ID: To: Eric Rescorla Cc: Roman Shpount , Flemming Andreasen , mmusic Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [MMUSIC] WG Interest in Unknown Key Share Attacks and poll for adoption of draft-thomson-mmusic-sdp-uks-00 as WG draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 21:10:56 -0000 Author +1 On 11 May 2017 at 05:39, Eric Rescorla wrote: > +1 > > On Wed, May 10, 2017 at 11:43 AM, Roman Shpount wrote: >> >> I support adopting this draft. >> >> _____________ >> Roman Shpount >> >> On Wed, May 10, 2017 at 11:09 AM, Flemming Andreasen >> wrote: >>> >>> Greetings MMUSIC >>> >>> The topic of Unknown Key Share Attacks on TLS with SDP has been discussed >>> on the mailing list more recently and it was also presented at the Chicago >>> IETF. Based on that, we would like to >>> >>> 1) Poll the WG for interest in this work, including willingness to >>> actively participate in and/or review this work >>> >>> 2) Assuming sufficient interest, ask if people would like to adopt >>> https://www.ietf.org/id/draft-thomson-mmusic-sdp-uks-00.txt as a starting >>> point for such work. >>> >>> >>> Please send your reply to the mailing list by May 24, 2018. >>> >>> Thanks >>> >>> -- Flemming & Bo (MMUSIC chairs) >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri May 12 13:56:12 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0C4127977 for ; Fri, 12 May 2017 13:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 a7_fZIkTT7A0 for ; Fri, 12 May 2017 13:56:09 -0700 (PDT) Received: from smtp74.iad3a.emailsrvr.com (smtp74.iad3a.emailsrvr.com [173.203.187.74]) (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 467D8130F27 for ; Fri, 12 May 2017 13:51:31 -0700 (PDT) Received: from smtp26.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 698F75865; Fri, 12 May 2017 16:51:30 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp26.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8F80D57A8; Fri, 12 May 2017 16:51:29 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 12 May 2017 16:51:30 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <7db1eac1-1667-8371-34ae-1462910f561c@cisco.com> Date: Fri, 12 May 2017 14:51:28 -0600 Cc: Bo Burman , Ben Campbell , Multiparty Multimedia Session Control Discussion List , Alexey Melnikov , stefhak@gmail.com, alvestrand@gmail.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <149123343669.13157.18402606352918183703.idtracker@ietfa.amsl.com> <7db1eac1-1667-8371-34ae-1462910f561c@cisco.com> To: Flemming Andreasen X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] New Liaison Statement, "W3C WEBRTC WG to IETF MMUSIC WG" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 20:56:12 -0000 Just read this now and a few points ...=20 1) I don't think this answer the questions asked. 2) the a and b miss the discussion of the context where this happens = where things like a 2nd DTLS connection replacing a prior DTLS = connection but on the same flow.=20 I'm focused on getting JSEP completed right now so don't plan to spend = time on this till somewhat later.=20 > On Apr 21, 2017, at 6:44 AM, Flemming Andreasen = wrote: >=20 > Greetings MMUSIC. >=20 > The issue raised below has been discussed on the MMUSIC mailing (see = thread starting at = https://www.ietf.org/mail-archive/web/mmusic/current/msg17646.html) and = the recent MMUSIC meeting at IETF 98 (Chicago). A summary discussion has = been provided at = https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291194679 as = well. >=20 > Based on the above, we suggest to answer the liaison statement as = follows: >=20 > > Thank you for raising the question regarding playout of unverified = media to the MMUSIC WG. We have looked further into the issue raised and = we would like to request a clarification of the exact sequence of events = that WEBRTC believes can lead to this. In particular, we ask you to = please show either > (a) how ICE can complete prior to DTLS fingerprint exchange, or > (b) how media can be received prior to ICE completing >=20 > It is currently unclear to us how either of these situations can arise = in which case we do not believe the issue raised would apply to WebRTC. >=20 > For further background information, please refer to: > - https://www.ietf.org/mail-archive/web/mmusic/current/msg17646.html > - https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291194679 > >=20 > Please let the chairs know (before April 28) if you have any comments. >=20 > Thanks >=20 > -- Flemming >=20 >=20 >=20 > On 4/3/17 11:30 AM, Liaison Statement Management Tool wrote: >> Title: W3C WEBRTC WG to IETF MMUSIC WG >> Submission Date: 2017-04-03 >> URL of the IETF Web page: https://datatracker.ietf.org/liaison/1511/ >> Please reply by 2017-04-16 >> From: Bernard Aboba >> To: Flemming Andreasen ,Bo Burman = >> Cc: Adam Roach ,Flemming Andreasen = ,Ben Campbell ,Bo Burman = ,Alexey Melnikov = ,Multiparty Multimedia Session Control = Discussion List >> Response Contacts: bernard.aboba@gmail.com, alvestrand@gmail.com, = stefhak@gmail.com >> Technical Contacts: >> Purpose: For action >>=20 >> Body: Colleagues: >>=20 >> In the W3C WEBRTC WG, an issue has been submitted relating to playout = of unverified media: >> https://github.com/w3c/webrtc-pc/issues/849 >>=20 >> It has been suggested that if the browser is configured to do so, = that playout be allowed for a limited period >> (e.g. 5 seconds) prior to fingerprint verification: >> https://github.com/w3c/webrtc-pc/pull/1026 >>=20 >> Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the = following text, carried over from RFC 4572: >>=20 >> Note that when the offer/answer model is being used, it is possible >> for a media connection to outrace the answer back to the offerer. >> Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' >> role, it MUST (as specified in RFC 4145 [7]) begin listening for an >> incoming connection as soon as it sends its offer. However, it MUST >> NOT assume that the data transmitted over the TLS connection is valid >> until it has received a matching fingerprint in an SDP answer. If >> the fingerprint, once it arrives, does not match the client's >> certificate, the server endpoint MUST terminate the media connection >> with a bad_certificate error, as stated in the previous paragraph. >>=20 >> Given the outstanding issue relating to handling of unverified media, = the Chairs of the W3C WEBRTC WG >> would like to request clarification from the IETF MMUSIC WG as to the = meaning of the "MUST NOT" in the >> above paragraph. In particular, what is it permitted for a WebRTC = implementation to do with received data prior >> to verification? For example: >>=20 >> 1. May data received over the data channel be provided to the web = application prior to verification? >> 2. May received media be played out prior to verification? >> Attachments: >>=20 >> webrtc-liason-to-mmusic copy.pdf >> = https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-04-03-w3c-webrt= c-mmusic-w3c-webrtc-wg-to-ietf-mmusic-wg-attachment-1.pdf >>=20 >> . >>=20 >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Fri May 12 14:09:42 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EBA1296D2 for ; Fri, 12 May 2017 14:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 TQx-Ro0ytT0W for ; Fri, 12 May 2017 14:09:39 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (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 BB1A31289C3 for ; Fri, 12 May 2017 14:05:50 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id e193so35513061pfh.0 for ; Fri, 12 May 2017 14:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ydNsdxWbDSkN/6XwnE2qyqhms+MccPg22al/59NxIeE=; b=XogsHptQ0vCYdU4nHOW4FfHH7NcY9UmrFCtFqh0zH555goXZMyNHl6zdycedXx5La8 HAzmkZq8X2n7Uk5yq6RGn3tdXrvnnVJlxmqZatrkXrdu4iuxIMbdi0Oh9dNY2AQaxxCH 8MG8TjM3VFtJmkskjDQmUM182564DpExmDEcKLB3fDSc/aBTBa0MDj76mAgaeXhzx9OC ooRxLD/jnqY+GyY4Zo0/8qNxCD5v335732ypvFdLsJjL8GaaJiifXrJhC72bEYEZr6rG HUrtCiBY0avgWSHsZWOlO8DDciRYBRHZYymKh1rgU/6tgZbUSCl1IaDeFnW0nJz73GR8 QUUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ydNsdxWbDSkN/6XwnE2qyqhms+MccPg22al/59NxIeE=; b=YiPnEJlbc4mvFJ93WKWm890ewuoLXp8WiJykRTvSxD2KwDClOIICwvK8eJ0MtbVEOK m1JkzwUx54H8xHbrsHmmVWn42nlx28VRw0ZlK/l4OFkqnov2AykEp7oewbDKphEqBySX uOjuJeEw3lCXI+6jnPa1hYzquPc6NdpJf4iDNiOwIMkDuUpRMBw6PvRjaR6p4uKIUi2C U1WpG+Lj+Jw3BjYZ237jXdujgwoZ3erAJOSbw+u7RITKDCXet2ABGjoAqmWANpV+wboX 7bzTSsbtcfZHh2UXk1G505rlHepjHjm2p4vjhLKnbhw1gGxwUf0NQ738Md3q71CO8RNg 9iQg== X-Gm-Message-State: AODbwcD3hJdWrHzzlxUhP8b1jAJ1M7hmF4DTEYE+8O9hq9daS9vngSgd KxiNkPBswpxSAEyA X-Received: by 10.99.161.26 with SMTP id b26mr6525512pgf.115.1494623150197; Fri, 12 May 2017 14:05:50 -0700 (PDT) Received: from mail-pg0-f43.google.com (mail-pg0-f43.google.com. [74.125.83.43]) by smtp.gmail.com with ESMTPSA id d3sm7120398pfb.110.2017.05.12.14.05.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 May 2017 14:05:49 -0700 (PDT) Received: by mail-pg0-f43.google.com with SMTP id u187so35323949pgb.0 for ; Fri, 12 May 2017 14:05:49 -0700 (PDT) X-Received: by 10.84.238.206 with SMTP id l14mr8162714pln.189.1494623149252; Fri, 12 May 2017 14:05:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.150 with HTTP; Fri, 12 May 2017 14:05:48 -0700 (PDT) In-Reply-To: References: <149123343669.13157.18402606352918183703.idtracker@ietfa.amsl.com> <7db1eac1-1667-8371-34ae-1462910f561c@cisco.com> From: Roman Shpount Date: Fri, 12 May 2017 17:05:48 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: Flemming Andreasen , Ben Campbell , Multiparty Multimedia Session Control Discussion List , Alexey Melnikov , stefhak@gmail.com, alvestrand@gmail.com Content-Type: multipart/alternative; boundary="f403045fdf84e26bec054f5a1150" Archived-At: Subject: Re: [MMUSIC] New Liaison Statement, "W3C WEBRTC WG to IETF MMUSIC WG" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 21:09:40 -0000 --f403045fdf84e26bec054f5a1150 Content-Type: text/plain; charset="UTF-8" On Fri, May 12, 2017 at 4:51 PM, Cullen Jennings wrote: > > 2) the a and b miss the discussion of the context where this happens where > things like a 2nd DTLS connection replacing a prior DTLS connection but on > the same flow. > When you say flow, do you mean 5-tuple? If flow means 5-tuple, then per dtls-id a new 5-tuple must be established for each new DTLS connection since this is how DTLS is de-multiplexed. Regards, _____________ Roman Shpount --f403045fdf84e26bec054f5a1150 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, May 12, 2017 at 4:51 PM, Cullen Jennings <= ;fluffy@iii.ca> wrote:

2) the a and b miss the discussion of the= context where this happens where things like a 2nd DTLS connection replaci= ng a prior DTLS connection but on the same flow.

<= /div>
When you say flow, do you mean 5-tuple? If flow means 5-tuple, th= en per dtls-id a new 5-tuple must be established for each new DTLS connecti= on since this is how DTLS is de-multiplexed.

Regar= ds,
_____________
Roman Shpount=
=C2=A0
--f403045fdf84e26bec054f5a1150-- From nobody Mon May 15 05:52:30 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4A91286D6 for ; Mon, 15 May 2017 05:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 J9C-8IJo4ida for ; Mon, 15 May 2017 05:52:27 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 5AD42129436 for ; Mon, 15 May 2017 05:48:08 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id b84so82565012wmh.0 for ; Mon, 15 May 2017 05:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pyQ5fpYihnnwJpK3jNLpInuPt+P0ZOy8bRIvin+3ki0=; b=AsGum7VEq5EHV9dCkBnJDSRlKULwu2hiBekKPUPnYDjeoTCtdORIILImo6iQZhZm79 bAPJpyvRI8NfC5l7ziAMeNIRCZuS7WAQ3rkho82Hu/7b5l1MLQwb5q0Q35K039p6/Nc1 scSi1yOsnRDdmPipseai1p01iV92AvYqgSYppT1wzerJFPnDBn5wplL/FVH3j0iGKrkd yPgtOmKO3+5NNgW6PIhy5vPGJ72yB8NU3Y4ZcLw4iy+e599itAmteOpE9fkrSaj+/uVi xxuAQCB9NZPMw+wHu2Yy1sRT5oWqON7XG7rluwapcdhAj3545IGAwn0Ae9ATIJbKzEC1 /p0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pyQ5fpYihnnwJpK3jNLpInuPt+P0ZOy8bRIvin+3ki0=; b=dr9DcHKFrVZaT9HeOAysFk8ShX3cnUx142g1cnPhZW4G5P5L1O00qCI/9h00M1JOnL gV98tDiyCvNXSoq1EfKZ8KC/7b1i/CZhPQTU9utzqVxWAWYzJTqRAty9e8DFRAdjljki fHHxUj5lfC1EyQ6VuMIMkpIRT2mbw0W5DNuNHg7Yz8MuSlYhie73SUjNcM521wFIV6uv OSU2OutH/MOXrUpBrQJ7sp+HWGNIzbYFOZyoCqvE6sf/YvPl7xxWNasjjgGjkW/ke6t+ v28+Jtrr7+1sgtkcsNYpNTEv6/VomBXyUI87H5UCZYu4VYo0XJnhLrU5yRM3kpJdUquM uWmg== X-Gm-Message-State: AODbwcDth0/YJcc4wgbfMpc8HguZzW31dEs6VgyOpElSE3Net2ImGZ3q a81e6Sg9xv595kGTb6IHh3eXAuSJGg== X-Received: by 10.28.144.15 with SMTP id s15mr3563222wmd.137.1494852486903; Mon, 15 May 2017 05:48:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.156 with HTTP; Mon, 15 May 2017 05:48:06 -0700 (PDT) In-Reply-To: References: <149432306204.23888.7508271969686658364.idtracker@ietfa.amsl.com> <66434d8c-1e4f-c401-c5ba-83eada18d372@comcast.net> From: Andy Hutton Date: Mon, 15 May 2017 13:48:06 +0100 Message-ID: To: "Gonzalo Salgueiro (gsalguei)" Cc: Paul Kyzivat , "mmusic (E-mail)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state "Call For Adoption By WG Issued" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 12:52:29 -0000 On Tue, May 9, 2017 at 6:35 PM, Gonzalo Salgueiro (gsalguei) wrote: > >> On May 9, 2017, at 1:28 PM, Paul Kyzivat wrot= e: >> >> On 5/9/17 1:13 PM, Gonzalo Salgueiro (gsalguei) wrote: >>> SIPBRANDY WG is not chartered to produce PS specs, which the original d= raft (draft-ietf-sipbrandy-osrtp) would have been since it was updating a c= urrent PS. The WG made the decision (vetted by AD and IESG) to not re-chart= er and instead decided split off the piece that updates a PS into a new PS = (draft-hutton-mmusic-opportunistic-negotiation). >> >> OK. But then couldn't everything be put into the MMUSIC document? >> ISTM that given the limited content in these documents that splitting it= into two, with a lot of overlap, is confusing. > > I see your point but Currently SIPBRANDY is chartered to produce Opportun= istic SRTP as a BCP. There is also a milestone to inform MMUSIC or other ap= propriate WGs of any changes needed to support Opportunistic SRTP (Not expe= cted to be published as an RFC). I think SIPBRANDY is just carrying out wh= at they are chartered to do. > Agree this is largely procedural we started the work in SIPBrandy and then realised we needed to update RFC 4568 so were forced to go to MMUSIC to do that. The tidy thing to do now is just finish what we started in both MMUSIC and SIPBrandy. Andy From nobody Mon May 15 10:02:47 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4861243F6 for ; Mon, 15 May 2017 10:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 ChR-K6Uld2ml for ; Mon, 15 May 2017 10:02:44 -0700 (PDT) Received: from smtp82.iad3a.emailsrvr.com (smtp82.iad3a.emailsrvr.com [173.203.187.82]) (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 5F161129471 for ; Mon, 15 May 2017 09:59:51 -0700 (PDT) Received: from smtp19.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 4EE29533E; Mon, 15 May 2017 12:59:50 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 8A33B5027; Mon, 15 May 2017 12:59:49 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.24.58.24] ([UNAVAILABLE]. [128.107.241.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Mon, 15 May 2017 12:59:50 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 15 May 2017 06:59:47 -1000 Message-Id: <0F8243F1-BA73-4814-A35B-6924B609AE29@iii.ca> To: Multiparty Multimedia Session Control Discussion List Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [MMUSIC] Review of draft-ietf-mmusic-sdp-simulcast-08 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 17:02:45 -0000 Overall the actually protocol described by the spec seems fine with a = few very small technical details. However, it is a bit challenging to = understand the basic overview of how it works - I have a few = suggestions that I think would be not much work that would really help = people get up to speed by moving some of the later example text to = closer to where the overview section is now.=20 Technical Issues ----------- Issue 1: Pause in an SDP re-offer=20 The pause in section 6.3.4 seems problematic. If A is sending a re-offer = to B, there is no real way to know the pause state of a stream B is = sending to A at that point without glare issues. Saying A has to send = something that matches a state on B is not really possible to implement.=20= I think this should be changed to say A sets the pause flags in the SDP = for RIDs A is sending to match what A currently thinks the state of them = is, and A sets the the pause flags for the RIDs A is receiving to what A = wished they were. The way that B processes the offer and creates the = answer as well as the handling of the answer by A would be the same as = the initial offer/answer.=20 Given the timing issues of RTCP near at the start of the call, if we = don't make this change, it may take significant time to un-pause a = particular stream at the start of the call. The above change allows that = to happen so that if a user joined a call that perhaps had a paused = presentation stream and wanted to un-pause that right away, they could.=20= Issue 2: More than one simulcast line=20 Some SDP stacks to not preserve the order of a=3Dlines. I have no idea = if this is a bug in them or not. I think it would be better to phrase = this spec as each m=3D section MUST have at most one a=3Dsimulcast line. = The current phrasing of receiver ignores all but first just begs for = people to put proprietary stuff in a second simulcast line.=20 Issue 3: Relating simulcast streams using PT=20 When the PT are unique, they can be used instead of RID. Obviously, if = they are not unique they can't be used, but when they are, they often = result in being able to display the video sooner. Often RID/MID will not = be included in every RTP packet because of the bandwidth usage and are = instead sent periodically. Being able to join a conference and start = displaying stuff right away is nice when possible=20 I think section 6.5 needs to be updated to be clear that "RTP "Simulcast = streams MUST be related on RTP level through RID." still means it is = fine for the RTP receiver to use the PT of the RTP packet and if that = uniquely maps to a RID in the SDP, use that for the relation.=20 Editorial ---------------- The use cases and requirements go for awhile and the first thing that = starts to explain how this works is bullet point point 4 in the overview = section which says=20 o The codec configuration for a simulcast stream is expressed through use of separately specified RTP payload format restrictions [I-D.ietf-mmusic-rid] with an associated RTP-level identification mechanism [I-D.ietf-avtext-rid] to identify which RTP payload format restrictions an RTP stream adheres to. This complements and effectively extends simulcast stream identification and configuration possibilities that could be provided by using only SDP formats as identifier. Use of multiple RTP streams with the same (non-redundancy) media type in the context of a single media source, where those RTP streams are using different RtpStreamId, is a strong but not totally unambiguous indication of those RTP streams being part of a simulcast. Have a skim of the draft up to that point and ask yourself how much = sense it would make it you get to this point? Or how much you would = understand about how the mechahims of this draft actually worked before = you got to the ABNF shortly after this. I suspect that you will likely = come to the conclusion that it's a bit hard to understand the big = picture of how it works.=20 I really can't make head or tails of the paragraph I quoted above but = the draft would make more sense to me if we removed that, along with = rest of section 5. =46rom the bullet point above, the draft goes = straight into the ABNF for the new stuff. I think it would be easier to = understand if we: Moved section 4 to appendix, Greatly shortened section = 3. Then add an overview that starts with showing the offer and answer = from 6.6.1. and explaining how the only thing this draft adds is the = a=3Dsimulcast line. Explain the one m line means one source concept. = Then show how simulcast line allows sending the 1;2 RIDs. Then explain = how alternatives work. =46rom there jump into the details. I don't think = this would be much new text and it would not change how anything works, = just clear up the explanation.=20 Section 6.1. and 6.2 are confusing because they are written as if they = are not for offer/answer SDP. I think it would be better to state up = front as that this was offer/answer SDP only and write theses sections = to be clear about if they are referring to offers or answers when = talking about SDP. As a specific example, the pause discussion on page = 13 might be correct for answers but looks less correct for offers.=20 =20 The SCID is really confusing in the draft. The draft is never fully = clear about if this is a RID or not it calls them "identical too" but = that hard to see if they are different but same value or work the same = way or something else. I think we should remove the term SCID from the = draft and just use RID. Similarly, using RtpStreamID is confusing. I = think we should just refer to that as the header that carries the RID. The example on the top of page 11 makes no sense without enough of the = SDP to see the rids and m lines etc and needs to be broken apart to be a = Offer example followed by the Answer back to that offer.=20 NIT - defined SFM on first use=20 From nobody Mon May 15 23:47:34 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415ED129BA0 for ; Mon, 15 May 2017 23:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 O6-cm-4cm6ub for ; Mon, 15 May 2017 23:47:31 -0700 (PDT) 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 4DFA612EB41 for ; Mon, 15 May 2017 23:43:28 -0700 (PDT) X-AuditID: c1b4fb25-08bff70000006049-7b-591a9f8dbec1 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 03.FE.24649.D8F9A195; Tue, 16 May 2017 08:43:26 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0339.000; Tue, 16 May 2017 08:43:24 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHSzg+3LES5P8e96kuYQ2NFd1Iy/Q== Date: Tue, 16 May 2017 06:43:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_D5407B8A1C98Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2J7lG7ffKlIg1kT1CymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIe7LQsWS1esnWvUwPhMvIuRk0NCwESitfE6UxcjF4eQwBFG ic7rK9kgnCWMEm8WzmbtYuTgYBOwkOj+pw3SICKgLvF1bw8ziC0skCsx5XMHC0S8SGL56XmM ELaexN+ty8BqWARUJQ6ceMwGMoZXwFpi7rQgkDCjgJjE91NrmEBsZgFxiVtP5jNB3CMgsWTP eWYIW1Ti5eN/rCC2KNDIff++skHEFSU+vtrHCNGbIDF9wQ52EJtXQFDi5MwnLBMYhWYhGTsL SdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHgM1MsBZFtLdM9XQVaygJFjFaNocWpxUm66kbFe alFmcnFxfp5eXmrJJkZgjBzc8lt1B+PlN46HGAU4GJV4eD0mSkUKsSaWFVfmHmKU4GBWEuGt MwEK8aYkVlalFuXHF5XmpBYfYpTmYFES53XcdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwFg3Zdrl swk/dh8N8wrd++reAtHPjz2j1qn/0fXQNONnnOCfa7B15yEVu/lb2fyOl5i5b6nTM9nwqkPV 8g6HRdqqi5Ed/Jdz5af93eut552rKBsza8LUx8fyVmgFTlthvmvCy93f6mfm23HuUl9ydck5 Q75r5X8NedP4khhN2vWrzhYmXGGdrKvEUpyRaKjFXFScCACO+Ia0jQIAAA== Archived-At: Subject: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 06:47:33 -0000 --_000_D5407B8A1C98Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The pull request based on the WGLC comments from Roman S and Martin T, suggests text saying that if an offerer receives ClientHello it must not send ServerHello until it has received the answer (that carries the fingerprint associated with the DTLS association). It has been claimed that we DO need to allow the offerer to establish the DTLS association BEFORE it has received the answer, in order to support certain early media use-cases. Until the offerer has received the answer, such media would be considered un-authenticated. Others do not want to allo= w it, due to security concerns. We need to find a solution to this, so any input is welcome. The pull request: https://github.com/cdh4u/draft-dtls-sdp/pull/31/files Regards, Christer --_000_D5407B8A1C98Bchristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <31C24F81BAC14045BFE0785D47F11694@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

The pull request based on the= WGLC comments from Roman S and Martin T,
suggests text saying that if = an offerer receives ClientHello it must not
send ServerHello until it has= received the answer (that carries the
fingerprint associated with t= he DTLS association).

It has been claimed that we D= O need to allow the offerer to establish the
DTLS association BEFORE it ha= s received the answer, in order to support
certain early media use-cases= . Until the offerer has received the answer,
such media would be considere= d un-authenticated. Others do not want to allow
it, due to security concerns.=

We need to find a solution to= this, so any input is welcome.


Regards,

Christer

--_000_D5407B8A1C98Bchristerholmbergericssoncom_-- From nobody Tue May 16 06:58:09 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C3112EBB0 for ; Tue, 16 May 2017 06:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 cakLcaZHJYup for ; Tue, 16 May 2017 06:58:03 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 C624E12EB82 for ; Tue, 16 May 2017 06:54:43 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id 203so52989304ywe.0 for ; Tue, 16 May 2017 06:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d03deiM0x1P9h3fcaQ9uHcR0EuwhMHoLML6lkp3k7tQ=; b=aVH+8X31pEyf/Pec2RwafH+KP+FGa/vZXhXqb6d8Su3m+61UwpyU/lxRH8Bj/qBIx3 5zde+cuMUwQwhNDYBV1BA8W5D7FmUmNWNKTkzmHwtGVbFqni63ObiYWHde/c4NLwttM7 GibrCPn2FtGPjjd0pCA783n8bYtfIhiXXnubfH2AniaqITksLBWqmFWYguR1IxpH8jDb 1wxJbI8Boytscot9G932Y2Z9V87DdnA+nqpPKyP40Uati48MwNlrC4tf/RaExiyzyI6c 2pVkRE/rmkzaLqbZ03rpdbIMA70PpZH647R5I/w0VgulwIkA1Pwt8tBeVcgEF7QFrm6n pQhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d03deiM0x1P9h3fcaQ9uHcR0EuwhMHoLML6lkp3k7tQ=; b=KOJuxO/Y0fPuMDiPLFbxEJMAPC6zej/cScM13gdvqY9+S344LDNlDqn5cab5BzcXI7 Ci5otjwnLZEiJIZfnBoa05C93W0kFmRCGutjFCdhDTWvHbCBc0DMCKxxv7ba9mTcj0xC iZTk1nnFQMFk6++cxyKTNjitFtCMMpDNZu1HOpD2IShn2KiFoo/yuZ6og/Yq/9KFuqa6 X5GzNPoqyQqTl6vRLVEvBJ2bjEhjzhUoligBlSP/PPfaMs8pvuKGUNf6l/mcVMbx3emy fXccm2AWrZdrlHwPARIqOrcoFnpOL6L2+kuzUY8XZLA6C0bEBkBW1zi1F8GoMtM5efHL q91A== X-Gm-Message-State: AODbwcAtO9tZzt5BosZJnBihIeTqEfA/8u9Q5BwBTd0b6vgQuOnGj21r c1EA6FFjRhDxkHY2xTU44aKGiTdOgoKk X-Received: by 10.129.146.210 with SMTP id j201mr9949418ywg.3.1494942883068; Tue, 16 May 2017 06:54:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 06:54:02 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 16 May 2017 06:54:02 -0700 Message-ID: To: Christer Holmberg Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c092a40816cb2054fa4837e" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 13:58:08 -0000 --94eb2c092a40816cb2054fa4837e Content-Type: text/plain; charset="UTF-8" On Mon, May 15, 2017 at 11:43 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > The pull request based on the WGLC comments from Roman S and Martin T, > suggests text saying that if an offerer receives ClientHello it must not > send ServerHello until it has received the answer (that carries the > fingerprint associated with the DTLS association). > I may have missed their comments, but I don't understand why you would make that rule. In neither TLS 1.2 or 1.3 are you able to evaluate the fingerprint at this point anyway, because you don't have the cert. It's one thing not to determine that the handshake is complete until you receive the answer, but that's different from not sending the SH. That seems silly. [0] -Ekr [0] I want to preemptively acknowledge that in most full-ICE cases, you won't be able to send the SH at this point anyway, but that's a distinct question. > It has been claimed that we DO need to allow the offerer to establish the > DTLS association BEFORE it has received the answer, in order to support > certain early media use-cases. Until the offerer has received the answer, > such media would be considered un-authenticated. Others do not want to > allow > it, due to security concerns. > > We need to find a solution to this, so any input is welcome. > > The pull request: https://github.com/cdh4u/draft-dtls-sdp/pull/31/files > > Regards, > > Christer > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --94eb2c092a40816cb2054fa4837e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 15, 2017 at 11:43 PM, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:
Hi,

The pull request based on the W= GLC comments from Roman S and Martin T,
suggests text saying that if an= offerer receives ClientHello it must not
send ServerHello until it has r= eceived the answer (that carries the
fingerprint associated with the= DTLS association).

I may= have missed their comments, but I don't understand why you would make = that
rule. In neither TLS 1.2 or 1.3 are you able to evaluate the= fingerprint at this
point anyway, because you don't have the= cert.

It's one thing not to determine that th= e handshake is complete until you receive
the answer, but that= 9;s different from not sending the SH. That seems silly. [0]

=
-Ekr

[0] I want to preemptively acknowl= edge that in most full-ICE cases, you won't
be able to send t= he SH at this point anyway, but that's a distinct question.
<= br>
=C2=A0
It has been claimed that we DO = need to allow the offerer to establish the
DTLS association BEFORE it has = received the answer, in order to support
certain early media use-cases. = Until the offerer has received the answer,
such media would be considered = un-authenticated. Others do not want to allow
it, due to security concerns.

We need to find a solution to t= his, so any input is welcome.


Regards,

Christer


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

--94eb2c092a40816cb2054fa4837e-- From nobody Tue May 16 07:29:20 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3889A12EAB6 for ; Tue, 16 May 2017 07:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 iOJG_umpPB_U for ; Tue, 16 May 2017 07:29:16 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 31BEF12EBE0 for ; Tue, 16 May 2017 07:24:57 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id u28so77284877pgn.1 for ; Tue, 16 May 2017 07:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7E+T9Rnr6Zn/OqYPhS1phTWP05rYql+xWVQmYr8klC4=; b=owONb/M6QERUQ53f6qogwKD/bwQudWRJ73BlgHGJttt+yFKFLaJYv6yaHrUVqW3s6x Dro5TgvX0tCJCtWolXhllUtcMs3wyCWRC5iyxRrv066uYBdkiZ7Fo1Kt7TtdETCblizp DrvH0siyiOZuV2YTYec4Wr7SnmDsbVxJOYHsH7AMkZ/2tX8zyVZs/gBWG8DJ5fRR8Wi2 sr+t5VPdvGi38rB44+A2fUmKr7O0eaEvx70XWJsr2VYW/+hZNl14/bifeU5ovZIPnURf 4aqCN1EjLaWzEIO3YMV+TMdvxvaQoUYiwq0u6dn4KabDsNvRqgDLSAOnZ8HpLF1Loe5x jvTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7E+T9Rnr6Zn/OqYPhS1phTWP05rYql+xWVQmYr8klC4=; b=PLjq86XwFvbtWrPRQxmJqtgeCdALeUVsv0D+8vKUhVm0Oo4sYrFfREVP51UTsOibMR LAmlEfz/fw51+FfKuhVWCZXiChuvx7/o8rwabIxNrWqSl0mP/8vPng41fB6m+vAJ30uW qLfSTl0T425WSxi2R36lLVz8P4PO5SGuRTlmiHkj2gBjUqAtUpiw+uoy2kbvyJP6Yg5n 5Ui0B9dix9Fo6K0LbW4tAEQQQ8WpfY1hWYwWN3m1yM1i9JpxT7R2ZDfYukef4aj7Vy82 P32xCNOMkerGJrynZSoJ/dvsKDlBFzwnO8CLKyQfMLLqEh+XxUDlbNf0j7QI1Z5NeXu+ p+Uw== X-Gm-Message-State: AODbwcADbgAOIwys/vLLkgP8ftHpbisyBMAAafzJOIcKKhxUGK6xUORH iZ4M7FVxZZgFVENh X-Received: by 10.84.128.33 with SMTP id 30mr16044607pla.111.1494944695102; Tue, 16 May 2017 07:24:55 -0700 (PDT) Received: from mail-pg0-f50.google.com (mail-pg0-f50.google.com. [74.125.83.50]) by smtp.gmail.com with ESMTPSA id f24sm24950726pfk.66.2017.05.16.07.24.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 May 2017 07:24:54 -0700 (PDT) Received: by mail-pg0-f50.google.com with SMTP id x64so57828835pgd.3 for ; Tue, 16 May 2017 07:24:53 -0700 (PDT) X-Received: by 10.99.163.67 with SMTP id v3mr12773369pgn.210.1494944693070; Tue, 16 May 2017 07:24:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.150 with HTTP; Tue, 16 May 2017 07:24:52 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Tue, 16 May 2017 10:24:52 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: Christer Holmberg , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="f4030436399c63bb31054fa4efd7" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 14:29:18 -0000 --f4030436399c63bb31054fa4efd7 Content-Type: text/plain; charset="UTF-8" On Tue, May 16, 2017 at 9:54 AM, Eric Rescorla wrote: > > > On Mon, May 15, 2017 at 11:43 PM, Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> The pull request based on the WGLC comments from Roman S and Martin T, >> suggests text saying that if an offerer receives ClientHello it must not >> send ServerHello until it has received the answer (that carries the >> fingerprint associated with the DTLS association). >> > > I may have missed their comments, but I don't understand why you would > make that > rule. In neither TLS 1.2 or 1.3 are you able to evaluate the fingerprint > at this > point anyway, because you don't have the cert. > > It's one thing not to determine that the handshake is complete until you > receive > the answer, but that's different from not sending the SH. That seems > silly. [0] > > First of all, draft-thomson-mmusic-sdp-uks puts tls-id from the answer in ClientHello. This tls-id can be used to identify that received ClientHello is related to the current signaling exchange and refuse other ClientHello messages. Second, not sending ServerAnswer until signaling answer is received, prevents unverified media and removes significant number of execution paths that would need to be defined both in the dtls-id specification and then tested during development and interop of compliant solutions. I do not want to spend time defining this unless it is absolutely necessary. As a small historic reference, all that previous versions of specifications said is that ClientHello can be received by the offering party before the answer is received. It did not specify how such ClientHello should be processed. Webrtc group in W3C asked how unverified media should be handled. We have determined that this should not occur with WebRTC end points, but this does point out that handling of unverified media is indeed undefined. I think dtls-id is the right place to specify this and the simplest thing I can see is to prohibit it. Regards, _____________ Roman Shpount --f4030436399c63bb31054fa4efd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 16, 2017 at 9:54 AM, Eric Resc= orla <ekr@rtfm.com> wrote:

=

On Mon, May 15, 2017 at 11:43 PM, Christe= r Holmberg <christer.holmberg@ericsson.com> wrote:
The pull request based on= the WGLC comments from Roman S and Martin T,
suggests text saying that if an= offerer receives ClientHello it must not
send ServerHello until it has r= eceived the answer (that carries the
fingerprint associated with the= DTLS association).

I may have missed their comments, but I don't understand why you woul= d make that
rule. In neither TLS 1.2 or 1.3 are you able to evalu= ate the fingerprint at this
point anyway, because you don't h= ave the cert.

It's one thing not to determine = that the handshake is complete until you receive
the answer, but = that's different from not sending the SH. That seems silly. [0]


First of all, dr= aft-thomson-mmusic-sdp-uks puts tls-id from the answer in ClientHello. This= tls-id can be used to identify that received ClientHello is related to the= current signaling exchange and refuse other ClientHello messages.

Second, not se= nding ServerAnswer until signaling answer is received, prevents unverified = media and removes significant number of execution paths that would need to = be defined both in the dtls-id specification and then tested during develop= ment and interop of compliant solutions. I do not want to spend time defini= ng this unless it is absolutely necessary.
=
As a small historic reference, all tha= t previous versions of specifications said is that ClientHello can be recei= ved by the offering party before the answer is received. It did not specify= how such ClientHello should be processed. Webrtc group in W3C asked how un= verified media should be handled. We have determined that this should not o= ccur with WebRTC end points, but this does point out that handling of unver= ified media is indeed undefined. I think dtls-id is the right place to spec= ify this and the simplest thing I can see is to prohibit it.

Regards,
_____________
Ro= man Shpount
=C2=A0
--f4030436399c63bb31054fa4efd7-- From nobody Tue May 16 07:52:50 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB531292FC for ; Tue, 16 May 2017 07:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Vt2SWS3XB7ws for ; Tue, 16 May 2017 07:52:46 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 A49F81289B5 for ; Tue, 16 May 2017 07:49:02 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l74so39505063ywe.2 for ; Tue, 16 May 2017 07:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QOOD+MUG8AgQUiwOgLuk1783d2+xtbXc3dDC5nyZcAs=; b=J7g435Kfv1kKxySYw/wIp5oCTDkt/SI88yQYx74gIyxEz1H+i+sdKRXhyV9Jsa9s/X budHFqUzb4FZlVQKuL4reCW+nfHH/YN2CtaLHrLZgdnjyggjSdXLioFJzFRprMx5RDdk w9MCnVG3VUY5e8/VYuXxeI7km14VdIHBkTOT68FNT/esSOyLjeqW7oZoVpKYnVij5Cy5 qEtmT60PNl91ns7rHm9BvkPGYMGdoi35D63onAQ1iw4mxbdtBNV/b+theRrlQtvioKgT r144fNx/VbBBFEtzc1oJjui0zIkMLsuYGd/uU8dfpoQGCSNPA1jKyY/W0icae5GY4APA WD4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QOOD+MUG8AgQUiwOgLuk1783d2+xtbXc3dDC5nyZcAs=; b=X0e8288+r1Y1mA3rPGszIPg/Exbzmaa2HqRiuOdEoPYfKMqX3lGMVxo8lPcX7e3v9U 14KSHVzPXjgCTwrqG5V/ZDZx4kPHGYxf7E0YedYVQggLZkmPOy8yYJdshcDFRsxs21D3 UA3AsBmE/+26961odud+yixDAwLRpG79AZdyFGgqWtWP+QgFV071Qc6Fg3M7STmQUAFB f6T/oqb87UBQXBKQ2KSg1UB9x6a+i8rfP6jEcSCxiJFx9vrEcUAVAv1pxmkHqX84LpXW tfV8Wtjv7m36gyJDyMjkg0Umg0JSzPmYGBBRvuS3B2tVvgXwhp4exQMRUDiTJAaUQH1X vYAA== X-Gm-Message-State: AODbwcAdTnrjldfW2DprUBOBCNubnYeScekWGm58grzh1XrVSvGVYZst 7km6aBijr5kSWQygIAW0ww6n+07IVA== X-Received: by 10.13.212.1 with SMTP id w1mr9380453ywd.24.1494946141862; Tue, 16 May 2017 07:49:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Tue, 16 May 2017 07:48:21 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 16 May 2017 07:48:21 -0700 Message-ID: To: Roman Shpount Cc: Christer Holmberg , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="001a114fb0f6beb26c054fa545b8" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 14:52:48 -0000 --001a114fb0f6beb26c054fa545b8 Content-Type: text/plain; charset="UTF-8" On Tue, May 16, 2017 at 7:24 AM, Roman Shpount wrote: > On Tue, May 16, 2017 at 9:54 AM, Eric Rescorla wrote: > >> >> >> On Mon, May 15, 2017 at 11:43 PM, Christer Holmberg < >> christer.holmberg@ericsson.com> wrote: >> >>> The pull request based on the WGLC comments from Roman S and Martin T, >>> suggests text saying that if an offerer receives ClientHello it must not >>> send ServerHello until it has received the answer (that carries the >>> fingerprint associated with the DTLS association). >>> >> >> I may have missed their comments, but I don't understand why you would >> make that >> rule. In neither TLS 1.2 or 1.3 are you able to evaluate the fingerprint >> at this >> point anyway, because you don't have the cert. >> >> It's one thing not to determine that the handshake is complete until you >> receive >> the answer, but that's different from not sending the SH. That seems >> silly. [0] >> >> > First of all, draft-thomson-mmusic-sdp-uks puts tls-id from the answer in > ClientHello. This tls-id can be used to identify that received ClientHello > is related to the current signaling exchange and refuse other ClientHello > messages. > Not following why that is necessary at this stage. You can reject the handshake when it completes. Second, not sending ServerAnswer until signaling answer is received, > prevents unverified media and removes significant number of execution paths > that would need to be defined both in the dtls-id specification and then > tested during development and interop of compliant solutions. I do not want > to spend time defining this unless it is absolutely necessary. > I'm not sure what you're talking about in terms of "ServerAnswer". That's not a TLS concept AFAIK. -Ekr > As a small historic reference, all that previous versions of > specifications said is that ClientHello can be received by the offering > party before the answer is received. It did not specify how such > ClientHello should be processed. Webrtc group in W3C asked how unverified > media should be handled. We have determined that this should not occur with > WebRTC end points, but this does point out that handling of unverified > media is indeed undefined. I think dtls-id is the right place to specify > this and the simplest thing I can see is to prohibit it. > > Regards, > _____________ > Roman Shpount > > --001a114fb0f6beb26c054fa545b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 16, 2017 at 7:24 AM, Roman Shpount <roman@telurix.com&= gt; wrote:
On Tue, May 16, 2017 at 9:= 54 AM, Eric Rescorla <ekr@rtfm.com> wrote:
=


On Mon, May 15, 2017 at 11:43 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
<= /span>
The pull request based on= the WGLC comments from Roman S and Martin T,
suggests text saying that if an= offerer receives ClientHello it must not
send ServerHello until it has r= eceived the answer (that carries the
fingerprint associated with the= DTLS association).

I may have missed their comments, but I don't= understand why you would make that
rule. In neither TLS 1.2 or 1= .3 are you able to evaluate the fingerprint at this
point anyway,= because you don't have the cert.

It's one= thing not to determine that the handshake is complete until you receive
the answer, but that's different from not sending the SH. That = seems silly. [0]

=

First of all, draft-thomson-mmusic-sdp-uks puts tls-id from = the answer in ClientHello. This tls-id can be used to identify that receive= d ClientHello is related to the current signaling exchange and refuse other= ClientHello messages.

No= t following why that is necessary at this stage. You can reject the handsha= ke
when it completes.


Second, not sending ServerAnswer until signaling answer = is received, prevents unverified media and removes significant number of ex= ecution paths that would need to be defined both in the dtls-id specificati= on and then tested during development and interop of compliant solutions. I= do not want to spend time defining this unless it is absolutely necessary.=

I'm not sure what yo= u're talking about in terms of "ServerAnswer". That's not= a TLS
concept AFAIK.

-Ekr
=C2=A0
As a small historic = reference, all that previous versions of specifications said is that Client= Hello can be received by the offering party before the answer is received. = It did not specify how such ClientHello should be processed. Webrtc group i= n W3C asked how unverified media should be handled. We have determined that= this should not occur with WebRTC end points, but this does point out that= handling of unverified media is indeed undefined. I think dtls-id is the r= ight place to specify this and the simplest thing I can see is to prohibit = it.

Re= gards,
_____________
Roman Shpount
=C2=A0

--001a114fb0f6beb26c054fa545b8-- From nobody Tue May 16 10:17:07 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924D01270A3 for ; Tue, 16 May 2017 10:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1FyxKp94UDhm for ; Tue, 16 May 2017 10:17:04 -0700 (PDT) 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 E57351289B0 for ; Tue, 16 May 2017 10:12:43 -0700 (PDT) X-AuditID: c1b4fb2d-b25ff7000000196b-c9-591b330816c9 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3E.3B.06507.8033B195; Tue, 16 May 2017 19:12:41 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Tue, 16 May 2017 19:12:40 +0200 From: Christer Holmberg To: Eric Rescorla , Roman Shpount CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHSzg+3LES5P8e96kuYQ2NFd1Iy/aH22hkAgAAInQCAAAaQgIAASbSw Date: Tue, 16 May 2017 17:12:39 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CBA529BESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7ii6nsXSkwYPzOhYrXp9jt5i6/DGL xYwLU5kdmD2WLPnJ5DH5cRuzx60pBQHMUVw2Kak5mWWpRfp2CVwZu7/MZiw4Yl4xq2U6cwPj D9MuRk4OCQETicarp1i6GLk4hASOMEqsvLKSCcJZwiixb9Imxi5GDg42AQuJ7n/aIA0iAs4S J9pesIGEmQXUJa4uDgIJCwtUSdxZ/Y8VoqRaYvPxi2wQtpvEkt29YDaLgKrE+6PPWEBsXgFf iesn3zNDrJrAJHFy0mpmkASnQKBE74tX7CA2o4CYxPdTa5hAbGYBcYlbT+YzQRwtILFkz3lm CFtU4uVjiMUSAkoSi25/hqrPl+iZv5gNYpmgxMmZT1gmMIrMQjJqFpKyWUjKZoG9pimxfpc+ RImixJTuh+wQtoZE65y57MjiCxjZVzGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIExtnBLb91 dzCufu14iFGAg1GJh3eSunSkEGtiWXFl7iFGCQ5mJRFeBz2gEG9KYmVValF+fFFpTmrxIUZp DhYlcV6HfRcihATSE0tSs1NTC1KLYLJMHJxSDYxyd4X3d3wQMEk7n6Xb4jWpXfiWdNmCuc7a x+1+PfxwYpIhw/Rsg0VfQ7w2Rvk/lmKu/G+nd8wvUFPn3O0tk1TuMhoIek0pvPpAacWJ83bx mpZRa+z+RKy2MK2IffTiePn8WRcWG4mpbpSJM565l/feH4XG5w5Tvgdem7L8eofw6bi494bT X/YqsRRnJBpqMRcVJwIAdn0Wsa8CAAA= Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 May 2017 17:17:07 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CBA529BESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCuKApg0KDQpTZWNvbmQsIG5vdCBzZW5kaW5nIFNlcnZlckFuc3dlciB1bnRpbCBzaWdu YWxpbmcgYW5zd2VyIGlzIHJlY2VpdmVkLCBwcmV2ZW50cyB1bnZlcmlmaWVkIG1lZGlhIGFuZCBy ZW1vdmVzIHNpZ25pZmljYW50IG51bWJlciBvZiBleGVjdXRpb24gcGF0aHMgdGhhdCB3b3VsZCBu ZWVkIHRvIGJlIGRlZmluZWQgYm90aCBpbiB0aGUgZHRscy1pZCBzcGVjaWZpY2F0aW9uIGFuZCB0 aGVuIHRlc3RlZCBkdXJpbmcgZGV2ZWxvcG1lbnQgYW5kIGludGVyb3Agb2YgY29tcGxpYW50IHNv bHV0aW9ucy4gSSBkbyBub3Qgd2FudCB0byBzcGVuZCB0aW1lIGRlZmluaW5nIHRoaXMgdW5sZXNz IGl0IGlzIGFic29sdXRlbHkgbmVjZXNzYXJ5Lg0KDQpJJ20gbm90IHN1cmUgd2hhdCB5b3UncmUg dGFsa2luZyBhYm91dCBpbiB0ZXJtcyBvZiAiU2VydmVyQW5zd2VyIi4gVGhhdCdzIG5vdCBhIFRM UyBjb25jZXB0IEFGQUlLLg0KDQpJIGFzc3VtZSBoZSBtZWFucyBTZXJ2ZXJIZWxsby4NCg0KUmVn YXJkcywNCg0KQ2hyaXN0ZXINCg0K --_000_7594FB04B1934943A5C02806D1A2204B4CBA529BESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLm0tOTA3MzkzMzU3Mjk3 OTM1OTc1MmdtYWlsLW0tNDc0NTgzMTEyODIxNDIzNTg1N2dtYWlsLQ0KCXttc28tc3R5bGUtbmFt ZTptXy05MDczOTMzNTcyOTc5MzU5NzUyZ21haWwtbV8tNDc0NTgzMTEyODIxNDIzNTg1N2dtYWls LTt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj7igKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNlY29uZCwgbm90IHNlbmRpbmcgU2VydmVyQW5zd2VyIHVudGlsIHNp Z25hbGluZyBhbnN3ZXIgaXMgcmVjZWl2ZWQsIHByZXZlbnRzIHVudmVyaWZpZWQgbWVkaWEgYW5k IHJlbW92ZXMgc2lnbmlmaWNhbnQgbnVtYmVyIG9mIGV4ZWN1dGlvbiBwYXRocyB0aGF0IHdvdWxk IG5lZWQgdG8gYmUgZGVmaW5lZCBib3RoIGluIHRoZSBkdGxzLWlkIHNwZWNpZmljYXRpb24gYW5k IHRoZW4gdGVzdGVkIGR1cmluZyBkZXZlbG9wbWVudA0KIGFuZCBpbnRlcm9wIG9mIGNvbXBsaWFu dCBzb2x1dGlvbnMuIEkgZG8gbm90IHdhbnQgdG8gc3BlbmQgdGltZSBkZWZpbmluZyB0aGlzIHVu bGVzcyBpdCBpcyBhYnNvbHV0ZWx5IG5lY2Vzc2FyeS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkknbSBub3Qgc3VyZSB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0IGluIHRlcm1zIG9mICZx dW90O1NlcnZlckFuc3dlciZxdW90Oy4gVGhhdCdzIG5vdCBhIFRMUzxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4NCjwvc3Bhbj5jb25jZXB0IEFGQUlLLjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYXNzdW1l IGhlIG1lYW5zIFNlcnZlckhlbGxvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4CBA529BESESSMB109erics_-- From nobody Fri May 19 06:28:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A597128BBB for ; Fri, 19 May 2017 06:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.323 X-Spam-Level: X-Spam-Status: No, score=-11.323 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 DcSNLR1iIfMG for ; Fri, 19 May 2017 06:28:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A923212ECEF for ; Fri, 19 May 2017 06:19:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1752; q=dns/txt; s=iport; t=1495199992; x=1496409592; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5povp159LBn14cTqD0LSVwgkTPh71o0UzsaNopNhyvg=; b=Lo3GmAO/XYI8o573rvoqj0TXoLskQfolhMlFyN7txbDjkgsdBCg6qQQq /INRoMYyChYVD9D+xUvncLLTM1/5L7+GcuCBX20uo0MPKEChUsI6Nl0vu g/VKoj0Fpvu1NdGwyPdHBBLzOos9df1AaER+3gYdmt7HUqW7TgXK/Z0GI 8=; X-IronPort-AV: E=Sophos;i="5.38,364,1491264000"; d="scan'208";a="247438810" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 May 2017 13:19:51 +0000 Received: from [10.131.12.59] (dhcp-10-131-12-59.cisco.com [10.131.12.59]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v4JDJoMW019118; Fri, 19 May 2017 13:19:51 GMT To: Andy Hutton , "Gonzalo Salgueiro (gsalguei)" , Paul Kyzivat References: <149432306204.23888.7508271969686658364.idtracker@ietfa.amsl.com> <66434d8c-1e4f-c401-c5ba-83eada18d372@comcast.net> Cc: "mmusic (E-mail)" From: Flemming Andreasen Message-ID: Date: Fri, 19 May 2017 09:19:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state "Call For Adoption By WG Issued" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 13:28:46 -0000 Hi Paul Does this satisfy any concerns you may have had with taking on this work and adopting the draft as a WG item ? Thanks -- Flemming (as MMUSIC co-chair) On 5/15/17 8:48 AM, Andy Hutton wrote: > On Tue, May 9, 2017 at 6:35 PM, Gonzalo Salgueiro (gsalguei) > wrote: >>> On May 9, 2017, at 1:28 PM, Paul Kyzivat wrote: >>> >>> On 5/9/17 1:13 PM, Gonzalo Salgueiro (gsalguei) wrote: >>>> SIPBRANDY WG is not chartered to produce PS specs, which the original draft (draft-ietf-sipbrandy-osrtp) would have been since it was updating a current PS. The WG made the decision (vetted by AD and IESG) to not re-charter and instead decided split off the piece that updates a PS into a new PS (draft-hutton-mmusic-opportunistic-negotiation). >>> OK. But then couldn't everything be put into the MMUSIC document? >>> ISTM that given the limited content in these documents that splitting it into two, with a lot of overlap, is confusing. >> I see your point but Currently SIPBRANDY is chartered to produce Opportunistic SRTP as a BCP. There is also a milestone to inform MMUSIC or other appropriate WGs of any changes needed to support Opportunistic SRTP (Not expected to be published as an RFC). I think SIPBRANDY is just carrying out what they are chartered to do. >> > Agree this is largely procedural we started the work in SIPBrandy and > then realised we needed to update RFC 4568 so were forced to go to > MMUSIC to do that. The tidy thing to do now is just finish what we > started in both MMUSIC and SIPBrandy. > > Andy > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > . > From nobody Fri May 19 07:10:15 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37CC120454 for ; Fri, 19 May 2017 07:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 tJiFKwGZUjt7 for ; Fri, 19 May 2017 07:10:02 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 061C2127286 for ; Fri, 19 May 2017 07:10:01 -0700 (PDT) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-01v.sys.comcast.net with SMTP id Bialdl9yIO3QoBibRdAY5c; Fri, 19 May 2017 14:10:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1495203001; bh=1bf3r+R3UxSG8Wfjlk6MB3Fpyvs5BmPK+/HO9NHOk+8=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=iyUUvY+67bGs+ShNt9krUzZaWZPwt5T0roxAe4dzYQVsjp2BXH+1yti7qhFMXr1ep y3IOUcndnE4AitiYl6gaQ6Nyb7/o4SjCh7wJuIU/PzjP44inURq5Vy3K6iqsRBXGxw eOrMSsouSbHVON7hiextfnMn8HicuKitTTMPNiyO9efjHL2Vcbxdr3SrApLyHweSz1 +FzRxll5xFRSmQKqHTbO3yDjYmfWOdJIutcoS/ckXAE5go37uQipJFW7bqsjEaICON wA6Qzy7A6b497IN4TKgfgfNV8rYYiQwsdtmbn4lw+DPDol7Wqx7NR9Nrdmk4EeaANa i6I5KaSd5aFmQ== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-16v.sys.comcast.net with SMTP id BibQdEmDt9isyBibQdISBD; Fri, 19 May 2017 14:10:01 +0000 To: Flemming Andreasen , Andy Hutton , "Gonzalo Salgueiro (gsalguei)" References: <149432306204.23888.7508271969686658364.idtracker@ietfa.amsl.com> <66434d8c-1e4f-c401-c5ba-83eada18d372@comcast.net> Cc: "mmusic (E-mail)" From: Paul Kyzivat Message-ID: Date: Fri, 19 May 2017 10:10:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfBHQcp4UxwMJo2/ELFXfWFz/Qf0ouFPIRvDO0wQr+fVsCKsT1amBakVI1JBPNnL0X6to44/LMHjcaZSIvDYRLMIV7e9X3QJDDrUWuwndNvM1X88/wHRr BGJsVghp7LhNGj+4tPISMSlCHlRQ7zFoIzYFV/DVOEK6nVsVXuFzdHUsXhUR0Y7Uawu2pKW3NNQDtEbJIXDS4P0ivoB8p/N7RPfQLRMsL8dftJMXctx/aaTV HJstW5mgz8dcDYXemDlSYUte0YUuEQksWk1O+NSL9ZY= Archived-At: Subject: Re: [MMUSIC] The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state "Call For Adoption By WG Issued" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 14:10:13 -0000 On 5/19/17 9:19 AM, Flemming Andreasen wrote: > Hi Paul > > Does this satisfy any concerns you may have had with taking on this work > and adopting the draft as a WG item ? I still think this is just a silly artifact of the organizational structure. But it doesn't matter much so I have no objection to moving forward as-is. Thanks, Paul > Thanks > > -- Flemming (as MMUSIC co-chair) > > On 5/15/17 8:48 AM, Andy Hutton wrote: >> On Tue, May 9, 2017 at 6:35 PM, Gonzalo Salgueiro (gsalguei) >> wrote: >>>> On May 9, 2017, at 1:28 PM, Paul Kyzivat >>>> wrote: >>>> >>>> On 5/9/17 1:13 PM, Gonzalo Salgueiro (gsalguei) wrote: >>>>> SIPBRANDY WG is not chartered to produce PS specs, which the >>>>> original draft (draft-ietf-sipbrandy-osrtp) would have been since >>>>> it was updating a current PS. The WG made the decision (vetted by >>>>> AD and IESG) to not re-charter and instead decided split off the >>>>> piece that updates a PS into a new PS >>>>> (draft-hutton-mmusic-opportunistic-negotiation). >>>> OK. But then couldn't everything be put into the MMUSIC document? >>>> ISTM that given the limited content in these documents that >>>> splitting it into two, with a lot of overlap, is confusing. >>> I see your point but Currently SIPBRANDY is chartered to produce >>> Opportunistic SRTP as a BCP. There is also a milestone to inform >>> MMUSIC or other appropriate WGs of any changes needed to support >>> Opportunistic SRTP (Not expected to be published as an RFC). I think >>> SIPBRANDY is just carrying out what they are chartered to do. >>> >> Agree this is largely procedural we started the work in SIPBrandy and >> then realised we needed to update RFC 4568 so were forced to go to >> MMUSIC to do that. The tidy thing to do now is just finish what we >> started in both MMUSIC and SIPBrandy. >> >> Andy >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> . >> > > From nobody Mon May 22 01:24:57 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6AB4129BAF for ; Mon, 22 May 2017 01:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 BXSEhM5ok1jX for ; Mon, 22 May 2017 01:24:54 -0700 (PDT) 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 CB198129BAB for ; Mon, 22 May 2017 01:24:53 -0700 (PDT) X-AuditID: c1b4fb25-35fff700000055fe-3b-5922a0522f76 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 16.A7.22014.250A2295; Mon, 22 May 2017 10:24:52 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Mon, 22 May 2017 10:24:51 +0200 From: Christer Holmberg To: Christer Holmberg , Eric Rescorla , Roman Shpount CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHSzg+3LES5P8e96kuYQ2NFd1Iy/aH22hkAgAAInQCAAAaQgIAASbSwgAjtDoA= Date: Mon, 22 May 2017 08:24:50 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_D5487BC21CF8Echristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMIsWRmVeSWpSXmKPExsUyM2K7rm7IAqVIg2OneC1WvD7HbjF1+WMW ixkXpjI7MHssWfKTyWPy4zZmj1tTCgKYo7hsUlJzMstSi/TtErgynv1rZiu44lLRf/sbYwPj V5suRk4OCQETiZ5nu1m6GLk4hASOMEoc37qcDSQhJLCYUWLxl4AuRg4ONgELie5/2iBhEYFK iXfnXrODhJkF1CWuLg4CMYUFqiROPquDqKiW2Hz8IhuE7Sdx5d8sZhCbRUBV4v/LaUwgNq+A tcSuuw2sEFuvMEnsbV7DDpLgBGrYteItWAOjgJjE91NrwBqYBcQlbj2ZzwRxsoDEkj3nmSFs UYmXj/+xgtiiAnoS+/59ZYOIK0rsPNvODNGbIHF6329miMWCEidnPmGZwCg6C8nYWUjKZiEp g4gbSLw/N58ZwtaWWLbwNZStL7Hxy1lGCNta4sHBbyzIahYwcqxiFC1OLU7KTTcy1kstykwu Ls7P08tLLdnECIzKg1t+q+5gvPzG8RCjAAejEg+vZ69SpBBrYllxZe4hRgkOZiURXrZJQCHe lMTKqtSi/Pii0pzU4kOM0hwsSuK8jvsuRAgJpCeWpGanphakFsFkmTg4pRoYfecqfOVv+R7a 8O+DXutyZjWH9P67rHkdhiwnLyyeob3LaJPi6+YM5geVdyf8fMF5P9lzy7fXDXc91vMKfGZI tpfYxF30/eqhSXqrX6fa7ChdJpZkv1u29XnWjj3mT16b1N/9d+PXk4U/OrkCfolOn8H0u4nB KFSQhT/Hs5D1W6jalDaH5k3SSizFGYmGWsxFxYkA0DHJuMYCAAA= Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 08:24:56 -0000 --_000_D5487BC21CF8Echristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I have updated the PR. The text now allows the offerer to establish the DTL= S association before it has received the SDP answer, but that any media rec= eived before the answer shall be considered unauthenticated. https://github.com/cdh4u/draft-dtls-sdp/pull/31 I intend to submit a new version of the draft soon, so please indicate if y= ou don=92t agree with the text =96 together with text that you (and hopeful= ly others) would agree too :) Regards, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Tuesday 16 May 2017 at 20:12 To: Eric Rescorla >, Roman Shpount > Cc: "mmusic@ietf.org" > Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS assoc= iation before it has received the SDP answer? Hi, =85 Second, not sending ServerAnswer until signaling answer is received, preven= ts unverified media and removes significant number of execution paths that = would need to be defined both in the dtls-id specification and then tested = during development and interop of compliant solutions. I do not want to spe= nd time defining this unless it is absolutely necessary. I'm not sure what you're talking about in terms of "ServerAnswer". That's n= ot a TLSconcept AFAIK. I assume he means ServerHello. Regards, Christer --_000_D5487BC21CF8Echristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4F5B6E00AD4000449561C28A8CE31DBD@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I have updated the PR. The text now allows the offerer to establish th= e DTLS association before it has received the SDP answer, but that any medi= a received before the answer shall be considered unauthenticated.


I intend to submit a new version of the draft soon, so please indicate= if you don=92t agree with the text =96 together with text that you (and ho= pefully others) would agree too :)

Regards,

Christer 

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Tuesday 16 May 2017 at 20:12<= br> To: Eric Rescorla <ekr@rtfm.com>, Roman Shpount <roman@telurix.com>
Cc: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: Re: [MMUSIC] draft-dtls-sd= p: Allow offerer to establish DTLS association before it has received the S= DP answer?

Hi,

 = ;

=85

 = ;

Second, not sending ServerAnswer until signaling ans= wer is received, prevents unverified media and removes significant number o= f execution paths that would need to be defined both in the dtls-id specifi= cation and then tested during development and interop of compliant solutions. I do not want to spend time defining t= his unless it is absolutely necessary.

 

I'm not sure what you're talking about in terms of &= quot;ServerAnswer". That's not a TLSconcept AFAIK.

 

I assume he means ServerHello.

 

Regards,

 

Christer

 

 --_000_D5487BC21CF8Echristerholmbergericssoncom_-- From nobody Mon May 22 03:08:29 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B60F129BD8 for ; Mon, 22 May 2017 03:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hWyZRYrCfJjW for ; Mon, 22 May 2017 03:08:26 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 30837126CD8 for ; Mon, 22 May 2017 03:08:26 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id 99so28166268lfu.1 for ; Mon, 22 May 2017 03:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=EYLYXWTZ2EQVUCmIMevboF/0Zfi/0KsqBpq3NNt+AtQ=; b=g0pToJWW5hA9rrBzhtdXjlvL4aShQerc4AiRJI2givmgn8PJm9lL0/zHhJ7ocMZg+c Bo0wpTkmRhx8swb8IklLBGbDHuciKtzNDBvef3qLrkenloXuTrNK95VpB+VJp/EI3ONv ow2AFjfFkul+SKhK0k9QWAivhoNOUt4DVylSuioZbK7uRTG6w2yvnoVUED6TTEZYHtuN yq8Ld+BdvHi1fAyNjrDL+p6TwZHbrHNaehCgDAngbtOT3t8mWeNMteIjmPHS+GT4mmKS +FrZ8DXdEcd2ZrPRnsMAyBGNSuNCuxLyA3WA9gXdXkqm6IzEMNQH7bzGrnhme/8//JlQ QJiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=EYLYXWTZ2EQVUCmIMevboF/0Zfi/0KsqBpq3NNt+AtQ=; b=W1vzUiOk/Z81pbceO/fvHQbkfZqRS2mROdiTvvKBxs7jzXA4bcxlLFIFmki4E5C/xE FT2zunOpSM+CGljMwwaRdpM1xcik0AcO35S8jarmhTt2Am09BWTFUIUQOvFYj6fylLiA bahE16MDeK9MSanS7Pin82W2XyGu/pLL7hok+PKlgQavjeewXcvvV49wm46tI0jDOh6M p/Cs/Lp4yHUTbCLX110Jm737N3Bnb8gEECYdJKW09GwqxBuRc562itoCmAQiyZNDT3ti TbN3PY9W3JOAVVEPOlj4uU3kpD7xHG8A5poy+lMgxeLydNSxvtpERgbqlb4YhUC2TuVj ROeg== X-Gm-Message-State: AODbwcD1Fe682qPtWh5sSDoKT5nXtvmwKg6R7KbKo+/dXnX0bFJzwY4+ mTcMyTYXXE7ztF3VsncHTXc/V0706Q== X-Received: by 10.25.166.133 with SMTP id p127mr5133882lfe.43.1495447704319; Mon, 22 May 2017 03:08:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.22.73 with HTTP; Mon, 22 May 2017 03:08:23 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> From: Martin Thomson Date: Mon, 22 May 2017 20:08:23 +1000 Message-ID: To: Christer Holmberg Cc: Eric Rescorla , Roman Shpount , "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 10:08:28 -0000 On 22 May 2017 at 18:24, Christer Holmberg wrote: > I have updated the PR. The text now allows the offerer to establish the D= TLS > association before it has received the SDP answer, but that any media > received before the answer shall be considered unauthenticated. > > https://github.com/cdh4u/draft-dtls-sdp/pull/31 > > I intend to submit a new version of the draft soon, so please indicate if > you don=E2=80=99t agree with the text =E2=80=93 together with text that y= ou (and hopefully > others) would agree too :) Roman is right here, this is going too far. As ekr points out, we over-corrected by insisting that the handshake not proceed without the answer, but doesn't mean that we should let the handshake complete without knowing to whom we are completing the handshake with. There is a case for taking the data you receive and holding it until you get an answer; it would be OK to allow that, though it would need some careful writing. However, I believe that the reason we've been asked to do this is in aid of actually playing out media from a completely unauthenticated source. That's the point at which this goes pear-shaped. The whole point of this is to provide integrity, and that doesn't happen if an attacker gets to provide the first few bits of a stream. I realize that this makes Cullen's use case harder, but several alternative solutions have been offered. My preference is to forbid handshake completion until the anchors by which the handshake is assessed (a=3Dfingerprint, a=3Dtls-id) are available. Second in preference to that is to allow received data to be saved, but not used. In no circumstance should we allow data to be *sent*. It's very hard to guarantee that an error that is detected on the peer will actually result in the connection terminating in a reasonable period of time. The current draft is vague on this point. p.s., Tim's comment about media vs. data needs to be addressed. From nobody Mon May 22 19:39:46 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20A8126DED for ; Mon, 22 May 2017 19:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xjQA0rcteTgE for ; Mon, 22 May 2017 19:39:42 -0700 (PDT) Received: from smtp90.ord1d.emailsrvr.com (smtp90.ord1d.emailsrvr.com [184.106.54.90]) (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 B54F0126557 for ; Mon, 22 May 2017 19:39:42 -0700 (PDT) Received: from smtp4.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp4.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id E67274005A; Mon, 22 May 2017 22:39:41 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp4.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 7C30740059; Mon, 22 May 2017 22:39:41 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Mon, 22 May 2017 22:39:41 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: Date: Mon, 22 May 2017 20:39:40 -0600 Cc: "mmusic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <178E77C7-CB9B-4D5D-A0F9-627153C03FEE@iii.ca> References: To: Christer Holmberg X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 02:39:44 -0000 > On May 16, 2017, at 12:43 AM, Christer Holmberg = wrote: >=20 > The pull request based on the WGLC comments from Roman S and Martin T, > suggests text saying that if an offerer receives ClientHello it must = not > send ServerHello until it has received the answer (that carries the > fingerprint associated with the DTLS association). I strongly disagree with adding this at this level. Consider for example = an endpoint that does not do ICE. Will you also wait until the identity = checks are complete to check that the fingerprint is valid and not = inserted by a MITM? That might make sense for WebRTC but it is something = specified at a much higher system level than here. This should just be a = building block that allows systems to use dtls-sdp as they see fit = instead of trying to mandate how it will be used at a higher level. From nobody Tue May 23 02:52:14 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF95A128D19 for ; Tue, 23 May 2017 02:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 VxibOtiBzE8a for ; Tue, 23 May 2017 02:52:11 -0700 (PDT) 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 30422127286 for ; Tue, 23 May 2017 02:52:11 -0700 (PDT) X-AuditID: c1b4fb3a-6e3519a000004a6a-b9-59240649777f Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7C.10.19050.94604295; Tue, 23 May 2017 11:52:09 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0339.000; Tue, 23 May 2017 11:52:06 +0200 From: Christer Holmberg To: Cullen Jennings CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHSzg+3LES5P8e96kuYQ2NFd1Iy/aIBHgAAgACsxIA= Date: Tue, 23 May 2017 09:52:06 +0000 Message-ID: References: <178E77C7-CB9B-4D5D-A0F9-627153C03FEE@iii.ca> In-Reply-To: <178E77C7-CB9B-4D5D-A0F9-627153C03FEE@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-ID: <99F53828372708489B7AFB5FBC6FD69D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2K7ga4nm0qkwckrUhYf1v9gtJi6/DGL A5PHkiU/mTwun//IGMAUxWWTkpqTWZZapG+XwJUxfbNiwSyOikdvT7M3MB5j62Lk5JAQMJHY 9+0KYxcjF4eQwBFGiTn3OlghnMWMEhOnfWXqYuTgYBOwkOj+pw3SICKgLHFux11mkDCzgLrE 1cVBIKawQJXEyWd1EBXVEpuPX2SDsK0k5p69wg5iswioSiz8doUFxOYVsJa4dGMWmC0kkC2x dc09sBpOoPo9P2aD2YwCYhLfT61hArGZBcQlbj2ZzwRxsoDEkj3nmSFsUYmXj/+xgtiiAnoS +/59hXpLUaL9aQMjRK+OxILdn9ggbGuJl2eamCFsbYllC18zQ9wjKHFy5hOWCYzis5Csm4Wk fRaS9llI2mchaV/AyLqKUbQ4tbg4N93ISC+1KDO5uDg/Ty8vtWQTIzDSDm75bbWD8eBzx0OM AhyMSjy8X/8qRwqxJpYVV+YeYpTgYFYS4T38HSjEm5JYWZValB9fVJqTWnyIUZqDRUmc12Hf hQghgfTEktTs1NSC1CKYLBMHp1QDY+/tnbpfJi12ianeOrNVJG5r/U7p/duivvap6rFwry4/ cEZs1oWUifoLuD2d3r7RrnHQ23ExL3AhdzVr6mSb0z+kahrn34lob76xcbGOUmqSnPX/rhy+ jY3KsxJ3vQmPuaLZ+uyK6nW+1eueFJ36tPhk5UKj2ckWGkJPrwnv574VmWzyd+XvdUosxRmJ hlrMRcWJAChvb/awAgAA Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 09:52:13 -0000 Hi Cullen, Please note that the PR has been updated. Regards, Christer On 23/05/17 05:39, "Cullen Jennings" wrote: > >> On May 16, 2017, at 12:43 AM, Christer Holmberg >> wrote: >>=20 >> The pull request based on the WGLC comments from Roman S and Martin T, >> suggests text saying that if an offerer receives ClientHello it must not >> send ServerHello until it has received the answer (that carries the >> fingerprint associated with the DTLS association). > >I strongly disagree with adding this at this level. Consider for example >an endpoint that does not do ICE. Will you also wait until the identity >checks are complete to check that the fingerprint is valid and not >inserted by a MITM? That might make sense for WebRTC but it is something >specified at a much higher system level than here. This should just be a >building block that allows systems to use dtls-sdp as they see fit >instead of trying to mandate how it will be used at a higher level. > > From nobody Tue May 23 02:59:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F581129459 for ; Tue, 23 May 2017 02:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.821 X-Spam-Level: X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 dlFfFeaKaFcc for ; Tue, 23 May 2017 02:59:17 -0700 (PDT) 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 6E124124C27 for ; Tue, 23 May 2017 02:59:16 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-42-592407f297aa Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 07.E3.03383.2F704295; Tue, 23 May 2017 11:59:14 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0339.000; Tue, 23 May 2017 11:59:12 +0200 From: Christer Holmberg To: Martin Thomson CC: Eric Rescorla , Roman Shpount , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHSzg+3LES5P8e96kuYQ2NFd1Iy/aH22hkAgAAInQCAAAaQgIAASbSwgAjtDoD//+kCgIABw7QA Date: Tue, 23 May 2017 09:59:12 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7ou4ndpVIg2ePlS1WvD7HbnHtzD9G i6nLH7NYzLgwldmBxWPnrLvsHkuW/GTymPy4jdnj1pSCAJYoLpuU1JzMstQifbsEroxTB0+x FLwQqrj6cDF7A2MbfxcjJ4eEgInEjJZXrCC2kMARRomW25JdjFxA9mJGicWT3wAlODjYBCwk uv9pg9SICOhKLDr7gB3EZhbIktjwYSUjSImwQJXEyWd1ECXVEpuPX2SDsKMkug9NYAEpYRFQ lXh+WBwkzCtgLTF731NGiE1nmSVunP3KApLgFAiUWHW/gQnEZhQQk/h+ag0TxCpxiVtP5jNB nCwgsWTPeWYIW1Ti5eN/YOeLCuhJ7Pv3lQ1kl4SAosTyfjmIVj2JG1OnsEHY1hLvDxxmhbC1 JZYtfM0McY+gxMmZT1gmMIrPQrJtFpL2WUjaZyFpn4WkfQEj6ypG0eLU4uLcdCNjvdSizOTi 4vw8vbzUkk2MwHg8uOW37g7G1a8dDzEKcDAq8fC+/KscKcSaWFZcmXuIUYKDWUmEdyKrSqQQ b0piZVVqUX58UWlOavEhRmkOFiVxXod9FyKEBNITS1KzU1MLUotgskwcnFINjMni3pPkXx1J /dkTYMEWXq9efCzOKO3b2fUMfJs/a297/UNoc9DnwriOeU2/X3tJbrimeUZ4XX3MhQ8WG1yY rb42rrvH38rIbXcl831J67oooXWtm5l6uXh9Mx2tnzo/Ezx1P3zT99bJhrurpGdMLz4mfsV8 uvwxmwndLvrm3dVPHgRPsVt5WYmlOCPRUIu5qDgRAGvgvMXDAgAA Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 09:59:19 -0000 Hi, >>I have updated the PR. The text now allows the offerer to establish the >>DTLS >> association before it has received the SDP answer, but that any media >> received before the answer shall be considered unauthenticated. >> >> https://github.com/cdh4u/draft-dtls-sdp/pull/31 >> >> I intend to submit a new version of the draft soon, so please indicate >>if >> you don=B9t agree with the text =AD together with text that you (and >>hopefully >> others) would agree too :) > >Roman is right here, this is going too far. As ekr points out, we >over-corrected by insisting that the handshake not proceed without the >answer, but doesn't mean that we should let the handshake complete >without knowing to whom we are completing the handshake with. > >There is a case for taking the data you receive and holding it until >you get an answer; it would be OK to allow that, though it would need >some careful writing. > >However, I believe that the reason we've been asked to do this is in >aid of actually playing out media from a completely unauthenticated >source. That's the point at which this goes pear-shaped. The whole >point of this is to provide integrity, and that doesn't happen if an >attacker gets to provide the first few bits of a stream. > >I realize that this makes Cullen's use case harder, but several >alternative solutions have been offered. > >My preference is to forbid handshake completion until the anchors by >which the handshake is assessed (a=3Dfingerprint, a=3Dtls-id) are >available. If I understand correctly, you seem to suggest that we allow the handshake to =B3proceed=B2 (see 1st paragraph of your reply), but not to =B3complete= =B2. If so, which endpoint is responsible to make sure that it doesn=B9t =B3complet= e=B2? >Second in preference to that is to allow received data to be saved, >but not used. In no circumstance should we allow data to be *sent*. I assume that also includes e.g., SCTP messages, i.e., in case of a WebRTC Data Channel it wouldn=B9t be allowed to establish the SCTP association. Regards, Christer >It's very hard to guarantee that an error that is detected on the peer >will actually result in the connection terminating in a reasonable >period of time. The current draft is vague on this point. > >p.s., Tim's comment about media vs. data needs to be addressed. From nobody Tue May 23 03:05:03 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEB2129A97 for ; Tue, 23 May 2017 03:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YKn3dhDTxmb5 for ; Tue, 23 May 2017 03:04:54 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (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 898C7124C27 for ; Tue, 23 May 2017 03:04:54 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id a5so31787435lfh.2 for ; Tue, 23 May 2017 03:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fgrn2q4TqzJXxbsraxMZwwCl1s0hmvSGinTXSJ5fjh4=; b=ntLCZ7hDvPtSzzFDpG8cHldcYcL8O7X4u2sGuEfbbZmS1ixzgqtYrGcvhicbqriVrs sp8pAnUf035hovX058xdUbMEL8RN6gB+SM6Par+7F3nlFuSl6TMgwXzy18KX5OV0rvbf ZnjNy9e5MrT3gCu+LAPJsp9AJ9ZgG9Pl/wFzY7p/mtYzfeHztBtbIJjafNmS3x3+Klak SDjCxX2NOLnSjme3kdiPPWSxDp5E7lzHQOVSUKthKYKT+DSkqCtNTFYHlNuIf36reXs4 /yqGpAkrlnCGRxvUSCpLmDEEhOOGNvM4Kcq7IYxD3qWtwz4CPNR77ct9QcCueBb/d+WG dhmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fgrn2q4TqzJXxbsraxMZwwCl1s0hmvSGinTXSJ5fjh4=; b=VbOLWnd7EvGrHcg06sUfzagaepH393YGfu2nELJ35HSlMzVUEBPXxxIO62QaSrkBOk pJ+YAKQ1g161fSypg70VPQqDTbxgL5u8WchRJkJ4J7kv359zqoGKWzOM33xo16o++nlU bCwf96lXmIwc+CI+AjHLlUl8dSo4KbUuEPLu6Sndhu6lktyK1slQjdSw7NwMp6hvzMhG jRH9cAKNPTYQDLppSRDv2mBMUoVUlTHS5UgPTYNmna7a7kHRfC88DH6LIExuWdZo/tIV Fe5nWG9M4OU4jUR4GIOWT0GNQuIYHNYq1RV1Sqhonv07Ytb7+brxzyUIdVou4E+N3i/A Bkyg== X-Gm-Message-State: AODbwcDI6vzMiMTzH46NKjNsJsxPxPYHH+LFvQcmXccgDtxmg+u2q8UR ggFKWR8gNo1MzMeWzqSAvY5dfGXbwQ== X-Received: by 10.25.215.198 with SMTP id q67mr6671827lfi.76.1495533892764; Tue, 23 May 2017 03:04:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.22.73 with HTTP; Tue, 23 May 2017 03:04:52 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> From: Martin Thomson Date: Tue, 23 May 2017 20:04:52 +1000 Message-ID: To: Christer Holmberg Cc: Eric Rescorla , Roman Shpount , "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 10:05:02 -0000 On 23 May 2017 at 19:59, Christer Holmberg wrote: > If I understand correctly, you seem to suggest that we allow the handshak= e > to =C2=B3proceed=C2=B2 (see 1st paragraph of your reply), but not to =C2= =B3complete=C2=B2. If > so, which endpoint is responsible to make sure that it doesn=C2=B9t =C2= =B3complete=C2=B2? Whichever endpoint is unable to acquire the information it needs in order to determine that the handshake is good. >>Second in preference to that is to allow received data to be saved, >>but not used. In no circumstance should we allow data to be *sent*. > > I assume that also includes e.g., SCTP messages, i.e., in case of a WebRT= C > Data Channel it wouldn=C2=B9t be allowed to establish the SCTP associatio= n. Yes, if you don't know to whom you are sending things, the only safe action is not to send. You can carve out exceptions for things like handshaking SCTP on the proviso that they are found to contain no actionable content, but that's tricky. From nobody Tue May 23 03:15:41 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA1D126CE8 for ; Tue, 23 May 2017 03:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 myEnxkSpnuzl for ; Tue, 23 May 2017 03:15:39 -0700 (PDT) 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 D05B0124C27 for ; Tue, 23 May 2017 03:15:38 -0700 (PDT) X-AuditID: c1b4fb25-73a9f9a0000055fe-cd-59240bc9918a Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 37.5F.22014.9CB04295; Tue, 23 May 2017 12:15:37 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0339.000; Tue, 23 May 2017 12:15:19 +0200 From: Christer Holmberg To: Martin Thomson CC: Eric Rescorla , Roman Shpount , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHSzg+3LES5P8e96kuYQ2NFd1Iy/aH22hkAgAAInQCAAAaQgIAASbSwgAjtDoD//+kCgIABw7QA///NpQCAADbcgA== Date: Tue, 23 May 2017 10:15:18 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrIIsWRmVeSWpSXmKPExsUyM2K7ou5JbpVIg0d/BS1WvD7HbnHtzD9G i6nLH7NYzLgwldmBxWPnrLvsHkuW/GTymPy4jdnj1pSCAJYoLpuU1JzMstQifbsErowbPw6x FxwRqNg2cS1zA2OPQBcjJ4eEgInEmYVHWLoYuTiEBI4wSlzeOYEVwlnMKDHv21bGLkYODjYB C4nuf9ogDSICuhKLzj5gB7GZBbIkNnxYCVYiLFAlcfJZHURJtcTm4xfZIOwsiaX/l4CVswio Sry9vooJxOYVsJZYMmsFI4gtJHCMRWLTNRMQm1MgUKLzw1pWEJtRQEzi+6k1TBCrxCVuPZnP BHGzgMSSPeeZIWxRiZeP/4HViwroSez795UN5BwJASWJaVvTIFq1JL782McGYVtLLNxyBspW lJjS/ZAd4hxBiZMzn7BMYBSfhWTbLCTts5C0z0LSPgtJ+wJG1lWMosWpxUm56UbGeqlFmcnF xfl5enmpJZsYgRF5cMtv1R2Ml984HmIU4GBU4uFd/1c5Uog1say4MvcQowQHs5II70RWlUgh 3pTEyqrUovz4otKc1OJDjNIcLErivI77LkQICaQnlqRmp6YWpBbBZJk4OKUaGN31Vp6tOnDd PT5UnWlNT+Lte7kxd9OOzpy26KGr6RSxlMUu9WkLwnTKO7s38f5S9nZur9BZ9llxRnJr7U9n LfvyrZ9PMdTtPqLP917U3DT1Trty56+uOM/e0oL4X50d/sLFn1+/vWx/R1Su1THrrucOad7F 0784GPlvM563pq106pIptXdeK7EUZyQaajEXFScCAK2Kt7vEAgAA Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 10:15:40 -0000 SGksDQoNCj4+SWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91IHNlZW0gdG8gc3VnZ2VzdCB0 aGF0IHdlIGFsbG93IHRoZQ0KPj5oYW5kc2hha2UNCj4+IHRvIKn4cHJvY2VlZKn3IChzZWUgMXN0 IHBhcmFncmFwaCBvZiB5b3VyIHJlcGx5KSwgYnV0IG5vdCB0byCp+GNvbXBsZXRlqfcuDQo+Pklm DQo+PiBzbywgd2hpY2ggZW5kcG9pbnQgaXMgcmVzcG9uc2libGUgdG8gbWFrZSBzdXJlIHRoYXQg aXQgZG9lc26p9nQNCj4+qfhjb21wbGV0Zan3Pw0KPg0KPldoaWNoZXZlciBlbmRwb2ludCBpcyB1 bmFibGUgdG8gYWNxdWlyZSB0aGUgaW5mb3JtYXRpb24gaXQgbmVlZHMgaW4NCj5vcmRlciB0byBk ZXRlcm1pbmUgdGhhdCB0aGUgaGFuZHNoYWtlIGlzIGdvb2QuDQoNCk9rLCBzbyBpbiB0aGUgdXNl LWNhc2Ugd2Whr3ZlIGJlZW4gZGlzY3Vzc2luZyBpdCB3b3VsZCBzdGlsbCBiZSB0aGUgb2ZmZXJl ci4NCg0KQnV0LCB3aGF0IGFib3V0IGRhdGEgcmVjZWl2ZWQgYmVmb3JlIHRoZSBjb21wbGV0aW9u IGlzIHJlY2VpdmVkPyBZb3Ugc2FpZA0KdGhhdCB5b3Ugd291bGQgYmUgb2sgdG8gYWxsb3cgcmVj ZWl2ZWQgZGF0YSB0byBiZSBzYXZlZCwgYnV0IG5vdCB1c2VkLg0KSG93ZXZlciwgSSBhc3N1bWUg Q3VsbGVuIHdvdWxkIG5vdCBhZ3JlZSB0byB0aGF0Lg0KDQpBbHNvLCBpZiBJIHVuZGVyc3RhbmQg dGhlIEZFREVYIHVzZS1jYXNlLCBub3Qgb25seSB3b3VsZCB5b3UgaGF2ZSB0byBiZQ0KYWJsZSB0 byByZWNlaXZlIG1lZGlhIC0gaWYgeW91IGFyZSBlLmcuLCBnb2luZyB0byBwcm92aWRlIERUTUZz IHlvdSBjb3VsZA0KYWxzbyBoYXZlIHRvIFNFTkQgZGF0YT8gT3I/DQoNCj4+PlNlY29uZCBpbiBw cmVmZXJlbmNlIHRvIHRoYXQgaXMgdG8gYWxsb3cgcmVjZWl2ZWQgZGF0YSB0byBiZSBzYXZlZCwN Cj4+PmJ1dCBub3QgdXNlZC4gIEluIG5vIGNpcmN1bXN0YW5jZSBzaG91bGQgd2UgYWxsb3cgZGF0 YSB0byBiZSAqc2VudCouDQo+Pg0KPj4gSSBhc3N1bWUgdGhhdCBhbHNvIGluY2x1ZGVzIGUuZy4s IFNDVFAgbWVzc2FnZXMsIGkuZS4sIGluIGNhc2Ugb2YgYQ0KPj5XZWJSVEMNCj4+IERhdGEgQ2hh bm5lbCBpdCB3b3VsZG6p9nQgYmUgYWxsb3dlZCB0byBlc3RhYmxpc2ggdGhlIFNDVFAgYXNzb2Np YXRpb24uDQo+DQo+WWVzLCBpZiB5b3UgZG9uJ3Qga25vdyB0byB3aG9tIHlvdSBhcmUgc2VuZGlu ZyB0aGluZ3MsIHRoZSBvbmx5IHNhZmUNCj5hY3Rpb24gaXMgbm90IHRvIHNlbmQuICBZb3UgY2Fu IGNhcnZlIG91dCBleGNlcHRpb25zIGZvciB0aGluZ3MgbGlrZQ0KPmhhbmRzaGFraW5nIFNDVFAg b24gdGhlIHByb3Zpc28gdGhhdCB0aGV5IGFyZSBmb3VuZCB0byBjb250YWluIG5vDQo+YWN0aW9u YWJsZSBjb250ZW50LCBidXQgdGhhdCdzIHRyaWNreS4NCg0KSSBhZ3JlZS4gV2Ugc2hvdWxkIGF2 b2lkIHNwZWNpZnlpbmcgcGVyLXByb3RvY29sIGV4Y2VwdGlvbnMsIGJlY2F1c2UNCnNvb25lciBv ciBsYXRlciBpdCB3aWxsIGVuZCB1cCBpbiBhIG1lc3MuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVy DQoNCg== From nobody Tue May 23 03:26:03 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A42C126E64 for ; Tue, 23 May 2017 03:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 E_TP8VKS5_qx for ; Tue, 23 May 2017 03:26:00 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 A3B64124C27 for ; Tue, 23 May 2017 03:25:59 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id a5so32067929lfh.2 for ; Tue, 23 May 2017 03:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gRQIBtEsN6WnVEWP6eHS0zvntXyHVGf9k7ugEtRjw5g=; b=bTkEPXM4NFEQv+0tY0mZ4qHdgaDyrwaAIzi8EQkOCVLVzbHMyqGlnC0pqzGPoCzwSx iyWpArDnZswE4NWRTfRlKlI/3povLNXn+R+uOGYmH1oz/A94qkr/irNt+pTlBz+WkZeL 0qXwCFCACdmrCKFUo5wA1uv+x1Z/hAeRe8YQ69cR6RrxTLeO18YULq63H4Usbh6WpHVH mytHZDml3gWIWiOOgWpD+wC//IfRObsbsvXjMqocfgzDhQrk5B/jNuElX1TcCopWNVH5 FMDhhTZTKu4o4NFuV9RwlVE0c0fguc/A7ZuhMy6y6Y/fJR0O3LPS3NmEtTQm0ItrCayk bmHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gRQIBtEsN6WnVEWP6eHS0zvntXyHVGf9k7ugEtRjw5g=; b=ma37jQ5oH+ScAmAWae1ugdBdLqnyeB7IaOk9goB89F5YeVZ1mpaEfF49k5AjSv9V8B 9ccHvrvPi9Q91xCr8RCjm2TkSMk+uLsAiWYUXZp3AOjdvBN/wv0VBM3kP/xl53GnHVzW jcj9A/LWE0FVVX8zmSdyk7YRgCmgSWqxAEy9MeeTxbSnk4Qv1vf7KbCSv1mXumAIXpm4 Mmx+H9tHFuJurEJRP5eLsX9ivyI2YJkPEJWay6UwlYRySnCsooeooH8mDut5GZQs0uTJ NPMSYjvK4BhmAKDx+2q9hiHRMC9W1gpI1Z5xG//zA/qefZSC7ZVPZGFASqQA8/f4CAcG X0iQ== X-Gm-Message-State: AODbwcBezMPQJYpIFOwiMMzxEq0UFRW+f8OlSdFdwGx3gLWlYTDhLiDi HXa2OX6CrxM9qbEKdXV4XW6SubAlNpE3M7I= X-Received: by 10.46.69.130 with SMTP id s124mr7458255lja.44.1495535157865; Tue, 23 May 2017 03:25:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.22.73 with HTTP; Tue, 23 May 2017 03:25:57 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> From: Martin Thomson Date: Tue, 23 May 2017 20:25:57 +1000 Message-ID: To: Christer Holmberg Cc: "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 May 2017 10:26:01 -0000 On 23 May 2017 at 20:15, Christer Holmberg wrote: > But, what about data received before the completion is received? Well, I'd prefer to drop that, because buffering is tricky, but as I said, holding it without even decrypting it could work. Note that many DTLS-SRTP implementations won't even allow you to call the exporter until the handshake is complete. In order to even get the data to arrive you have to do some inadvisable things to the stack, such as accepting the peer's certificate, then you have to kill the connection when the a=fingerprint arrives and doesn't match. It's much easier to validate inline. > Also, if I understand the FEDEX use-case, not only would you have to be > able to receive media - if you are e.g., going to provide DTMFs you could > also have to SEND data? Or? Yeah, sending DTMF to who-knows isn't a good idea. I'm not clear on whether sending DTMF is part of the arrangement. Sounds like a great way to avoid tarriffs altogether; I'm surprised that service providers would even allow that. This is why I think that this "unverified media" is the wrong solution here. It's not impossible to have an authenticated session and accomplish these goals. From nobody Wed May 24 09:17:27 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB81812EB47 for ; Wed, 24 May 2017 09:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zaPNoBaFXQYb for ; Wed, 24 May 2017 09:17:24 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 DCFEE12EB3E for ; Wed, 24 May 2017 09:17:23 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id l50so57963430wrc.3 for ; Wed, 24 May 2017 09:17:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=COAT3s0FQoNLvi7NjFIPEWaKHYEcw8BxmT3fbgmQzf8=; b=BL9Tl6CEdnGsbv6TghFrg0HWa4L9UU5gP//4JuXN4ilAHK+EDXa1V9gQVzQ1REvDVB GyDm4cv613zCK+a59FoFeSDcJfuNCIG0YHrIwO3fMvpxK35Cj/G/YMbFhZ+lyg4vlYQR /UKEOIPBMaUWUJ6MneUlhDcaj1BVo6bQVGxKWlqdwpUh0OSk4rPEhlYGgxlH8cThTYpr PnuOVqGj1+7MMfVSLp/CY7Q/HBHieoGETzshEWKoy5C8rKJvBNH9VYc/62kAavrxCXEf FJffbzGSiH3N8f2xy3ZMZnf7RLFVWM9daFJQA7CZiE3KMWgLEQO3VGzLXR9Rm+Bi5YPd qSNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=COAT3s0FQoNLvi7NjFIPEWaKHYEcw8BxmT3fbgmQzf8=; b=S8IdLGBEKwROvQ0Jzjlh2yuTJNGqewVhq7MwgRntSzsN6C2AEf0EjE6vlGsMLeUo/l 6aYlMfzpG8D4IzPWPSNqFl8rcrn4VQbT0OFyqxNnmF9L1LyK2ZLVItBv78rekqOQttdV GAFWuaRDinaWhcEq5SGMKIyf1W28C2Fo4Ve/jwgfWvgvjTvZ+Kh1xGndufhsxDZ/fH6m Dj1I2/k76xzbe/Fv4PaEH2spMD+/rYXiYhkwYZTK7QhCLl8MOteow7w1iuN6gC3g5Nu+ +NVEIXYS8jJjFeQz/YjB6YzIC6no+3uU0d5I+bUPm6PQSNJZgX25K4FVCcC2fBbTo8wz cIcw== X-Gm-Message-State: AODbwcDNKgUbOYFbsgiATssNp73MaL8nHv7KRbIIQIdn8z+z52Lp92YM hSdj72clTo4QGgdBRZ16KFiyfuRKvw== X-Received: by 10.223.172.149 with SMTP id o21mr19586319wrc.181.1495642642361; Wed, 24 May 2017 09:17:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.156 with HTTP; Wed, 24 May 2017 09:17:21 -0700 (PDT) In-Reply-To: References: <149432306204.23888.7508271969686658364.idtracker@ietfa.amsl.com> <66434d8c-1e4f-c401-c5ba-83eada18d372@comcast.net> From: Andy Hutton Date: Wed, 24 May 2017 17:17:21 +0100 Message-ID: To: Paul Kyzivat Cc: Flemming Andreasen , "Gonzalo Salgueiro (gsalguei)" , "mmusic (E-mail)" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MMUSIC] The MMUSIC WG has placed draft-hutton-mmusic-opportunistic-negotiation in state "Call For Adoption By WG Issued" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 16:17:26 -0000 Are we good to go and submit the mmusic draft then? I don't disagree with Paul it is just an artifact of the organisational structure but this is what SIPBrandy WG, AD's, and Chairs decided and it has taken far to long already. Lets press ahead and get it done. Andy On Fri, May 19, 2017 at 3:10 PM, Paul Kyzivat wrote: > On 5/19/17 9:19 AM, Flemming Andreasen wrote: >> >> Hi Paul >> >> Does this satisfy any concerns you may have had with taking on this work >> and adopting the draft as a WG item ? > > > I still think this is just a silly artifact of the organizational structure. > But it doesn't matter much so I have no objection to moving forward as-is. > > Thanks, > Paul > > >> Thanks >> >> -- Flemming (as MMUSIC co-chair) >> >> On 5/15/17 8:48 AM, Andy Hutton wrote: >>> >>> On Tue, May 9, 2017 at 6:35 PM, Gonzalo Salgueiro (gsalguei) >>> wrote: >>>>> >>>>> On May 9, 2017, at 1:28 PM, Paul Kyzivat >>>>> wrote: >>>>> >>>>> On 5/9/17 1:13 PM, Gonzalo Salgueiro (gsalguei) wrote: >>>>>> >>>>>> SIPBRANDY WG is not chartered to produce PS specs, which the >>>>>> original draft (draft-ietf-sipbrandy-osrtp) would have been since >>>>>> it was updating a current PS. The WG made the decision (vetted by >>>>>> AD and IESG) to not re-charter and instead decided split off the >>>>>> piece that updates a PS into a new PS >>>>>> (draft-hutton-mmusic-opportunistic-negotiation). >>>>> >>>>> OK. But then couldn't everything be put into the MMUSIC document? >>>>> ISTM that given the limited content in these documents that >>>>> splitting it into two, with a lot of overlap, is confusing. >>>> >>>> I see your point but Currently SIPBRANDY is chartered to produce >>>> Opportunistic SRTP as a BCP. There is also a milestone to inform >>>> MMUSIC or other appropriate WGs of any changes needed to support >>>> Opportunistic SRTP (Not expected to be published as an RFC). I think >>>> SIPBRANDY is just carrying out what they are chartered to do. >>>> >>> Agree this is largely procedural we started the work in SIPBrandy and >>> then realised we needed to update RFC 4568 so were forced to go to >>> MMUSIC to do that. The tidy thing to do now is just finish what we >>> started in both MMUSIC and SIPBrandy. >>> >>> Andy >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> . >>> >> >> > From nobody Fri May 26 00:30:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B541242F7 for ; Fri, 26 May 2017 00:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 J-IgjL-n7QgH for ; Fri, 26 May 2017 00:30:20 -0700 (PDT) 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 C1E701242EA for ; Fri, 26 May 2017 00:30:18 -0700 (PDT) X-AuditID: c1b4fb3a-307ff70000004a6a-4f-5927d9888b92 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 44.1D.19050.889D7295; Fri, 26 May 2017 09:30:17 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0339.000; Fri, 26 May 2017 09:30:16 +0200 From: Christer Holmberg To: Martin Thomson CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHSzg+3LES5P8e96kuYQ2NFd1Iy/aH22hkAgAAInQCAAAaQgIAASbSwgAjtDoD//+kCgIABw7QA///NpQCAADbcgP//zwiAAJc8RoA= Date: Fri, 26 May 2017 07:30:15 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7q27nTfVIg/ldvBbXzvxjtJi6/DGL A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx+kBKwQP2ijsX1rI1MLaxdTFyckgImEj8 WvEByObiEBI4wijxafdPKGcxo8TpC4eYuxg5ONgELCS6/2mDNIgI6EosOvuAHSTMLKAucXVx EIgpLFAlcfJZHURFtcTm4xfZIOwyiVuPtjOD2CwCqhLLjy1kB7F5BawlTtw8BBYXEtjPKjF5 qz6IzSkQKLH28zomEJtRQEzi+6k1YDazgLjErSfzmSBOFpBYsuc8M4QtKvHy8T9WkBNEBfQk 3u33hAgrSlydvhyq1UDi/bn5zBC2tcSW6XNZIWxtiWULXzNDnCMocXLmE5YJjOKzkGybhaR9 FpL2WUjaZyFpX8DIuopRtDi1uDg33chIL7UoM7m4OD9PLy+1ZBMjMM4ObvlttYPx4HPHQ4wC HIxKPLzfDqlHCrEmlhVX5h5ilOBgVhLhjTsPFOJNSaysSi3Kjy8qzUktPsQozcGiJM7rsO9C hJBAemJJanZqakFqEUyWiYNTqoHR0tjWvn/v3oT+yLPLeBqlHrRnurOXrD3iH3Y3zb3gU0Sf GSOX+dp9fpm+Xk8cWYvmL2S1Yo0O32jGmr21L42Te/aHwuSd4S9+bHc8ciek/It+JeNhpx0T bv98xt3dNm+ri97RQOUU5RNLSu85C31Z06r5S9qt8+brw1mJtyw/nZzWKd0gsUCJpTgj0VCL uag4EQDaMVWOrwIAAA== Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 07:30:24 -0000 Hi, I have updated the PR. The text now says that the offer must not *finalise* the DTLS handshake until it has received the answer. The text still allows to process media that is received before the answer is received. I know Martin doesn=B9t like that, and I have no idea what the sec people will think about it, but I am trying to find some common ground. I want to move the draft forward. Is this something everyone can live with? =8A >> Also, if I understand the FEDEX use-case, not only would you have to be >> able to receive media - if you are e.g., going to provide DTMFs you >>could >> also have to SEND data? Or? > >Yeah, sending DTMF to who-knows isn't a good idea. I'm not clear on >whether sending DTMF is part of the arrangement. Sounds like a great >way to avoid tarriffs altogether; I'm surprised that service providers >would even allow that. Actually, before you get the SDP answer you can=B9t send any DTMFs=8A Regards, Christer From nobody Fri May 26 03:38:32 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F50129417 for ; Fri, 26 May 2017 03:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 PUEia63RGOdt for ; Fri, 26 May 2017 03:38:28 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (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 5086512896F for ; Fri, 26 May 2017 03:38:28 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id p143so1414117yba.2 for ; Fri, 26 May 2017 03:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sONnotrUftoJVp5FMJpLaRssVW3SFEYlYRmiAw6OlUo=; b=rNG4hdZFhKb42+YofMWj7V2jJJhLRDFf91EVZUQWBTjYznggUGmxKge1KA+eCWikmc dKkM14lLjBdYAmhFkfgwUnyB3dL8HnT7/w0pSxgvQlHghSX5ptJ97+5DouCvF5gQhr2u KbfHdqLa/mxAXoBWyxSbHe3VbEoBuX81qjCbHQ/IlrvCp3/tOjmCGVnfC5SMAQ2ixpLr e0Q4tcz85cpB3qk3Z10vXfaWvgYuWeJgCt/jRV0FiPkcLTBoiHoPCH+0z6h/TP7XYkym PTrkqc6jMDHJi5z1VyOQptS7fZAM3Jizt/sjNHukZZi3tg/q3ToeNXkT9MwmNfdEVnwb oItw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sONnotrUftoJVp5FMJpLaRssVW3SFEYlYRmiAw6OlUo=; b=Yt1pqpK2hLdOoOUMPnPR+qbzaAfGKGnft1fG2TM8rvYwEj5mDcTptM5yruljN4gGv2 dMlpgmUtUoEXVEuCtX2KQBhCcogYDJE2piLEoYMzwzHSh1HOWGqlkRhy0GokHJVwlQ2r P8fydFlx3g/UEugMgmtXACnPyJNG+4T3LOZ/vv1i9G4zb7Bc8hJgmXjsRHlqQRBMax2e Q3fY8vY/w4NJmKxMsSgQ4TLK2rvlRm/BUiI6EfrkMS0JlAWoT3oAgmduZ8O/7iIlQXmh CBu0nlUwGsSnNEGSOJm1dUmL4CKWpMTJbE/ISXCsGplswr0+ytjPMuHzrFHFB71lxNYE 9pxA== X-Gm-Message-State: AODbwcDIEIwE75hqCmM3dC44VkaEjAr++c2WcdcpF3UqIScqikw787M7 aI8WJm3vo5C4Iq0G0AOdkaYUsCXN0fDO X-Received: by 10.37.174.32 with SMTP id a32mr20076960ybj.50.1495795107540; Fri, 26 May 2017 03:38:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.131.150 with HTTP; Fri, 26 May 2017 03:37:47 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> From: Eric Rescorla Date: Fri, 26 May 2017 18:37:47 +0800 Message-ID: To: Christer Holmberg Cc: Martin Thomson , "mmusic@ietf.org" Content-Type: multipart/alternative; boundary="f403045dbf820b15eb05506af079" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 10:38:30 -0000 --f403045dbf820b15eb05506af079 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 26, 2017 at 3:30 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > > Hi, > > I have updated the PR. The text now says that the offer must not > *finalise* the DTLS handshake until it has received the answer. > What does that mean? Finalize isn't a DTLS concept. Also, you say that if you initiate the handshake before the answer is received you are vulnerable to attacks. What attacks are those? -Ekr > > The text still allows to process media that is received before the answer > is received. I know Martin doesn=C2=B9t like that, and I have no idea wha= t the > sec people will think about it, but I am trying to find some common > ground. I want to move the draft forward. > > Is this something everyone can live with? > > =C5=A0 > > > >> Also, if I understand the FEDEX use-case, not only would you have to b= e > >> able to receive media - if you are e.g., going to provide DTMFs you > >>could > >> also have to SEND data? Or? > > > >Yeah, sending DTMF to who-knows isn't a good idea. I'm not clear on > >whether sending DTMF is part of the arrangement. Sounds like a great > >way to avoid tarriffs altogether; I'm surprised that service providers > >would even allow that. > > Actually, before you get the SDP answer you can=C2=B9t send any DTMFs=C5= =A0 > > Regards, > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --f403045dbf820b15eb05506af079 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, May 26, 2017 at 3:30 PM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Hi,

I have updated the PR. The text now says that the offer must not
*finalise* the DTLS handshake until it has received the answer.

What does that mean? Finalize isn't a DTLS con= cept.

Also, you say that if you initiate the hands= hake before the answer
is received you are vulnerable to attacks.= What attacks are those?

-Ekr
=C2=A0

The text still allows to process media that is received before the answer is received. I know Martin doesn=C2=B9t like that, and I have no idea what = the
sec people will think about it, but I am trying to find some common
ground. I want to move the draft forward.

Is this something everyone can live with?

=C5=A0


>> Also, if I understand the FEDEX use-case, not only would you have = to be
>> able to receive media - if you are e.g., going to provide DTMFs yo= u
>>could
>> also have to SEND data? Or?
>
>Yeah, sending DTMF to who-knows isn't a good idea.=C2=A0 I'm no= t clear on
>whether sending DTMF is part of the arrangement.=C2=A0 Sounds like a gr= eat
>way to avoid tarriffs altogether; I'm surprised that service provid= ers
>would even allow that.

Actually, before you get the SDP answer you can=C2=B9t send any DTMF= s=C5=A0

Regards,

Christer

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

--f403045dbf820b15eb05506af079-- From nobody Fri May 26 04:02:04 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D363E129C53 for ; Fri, 26 May 2017 04:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 54ORFM6DnjHQ for ; Fri, 26 May 2017 04:02:01 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 29963126B71 for ; Fri, 26 May 2017 04:02:01 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id h4so4188542lfj.3 for ; Fri, 26 May 2017 04:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bOmTRPAy/8ycsB9lYabz7hmj5xr2nYfIsi7nLAh5D1w=; b=lxnErCxSep/wd4YzW4Fws8+Kpy/AMMhHQbhubz+f2mL4YQIC3l2UgWByClyFsRhG9Q QHipNE2jolltk2Z6EdsRc07cKzOxNGTdWeGVvMCCj4T+h7uV5dKrVrKHPX+soBVxH2iG kzeou/gd+ojzaw7Fkx+vDdp3TsYy66jPDg9oO3eWUBD0c5+YWyfgnoTxnFguVS70WFXZ NDaTfFF571jDUT0L438GWiThBhcxPiDHnDW92M26REhRehiT3o/AD1i0QY6osfvEDuzm gsdlYduhdigCZocj2l3RPOTIRunUG4/nSuDLBWR6JgjqiRW5qA/+VCAYH9WS98sipri5 WYsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bOmTRPAy/8ycsB9lYabz7hmj5xr2nYfIsi7nLAh5D1w=; b=XznHBCSyUr8dKkG3cs5BfBAU0w0nTDqDn6anK0Jbdo/krJ1PlOa35nrq7b6O12uDHH PNULY834AF04t+ST+pHRIaJJpkHiJXX8ll/QvfIaWJUAtH/zpDx/rWX3p66jSWv7YP82 qOHSDnmqsEeuOItGl6G7HozDe6SzOPSzeQultClBgc+tbDxOaUqor7gjSwOV2mlJmFSm 7MrHBDqw4H8+1087wOukBPx5SjJhi+OZ7MUOnk5XnZRSlwIP1eMcX5n1hvTLadob9ziB 5QBw+SzCLJ3lPEOpD2JLa4yXHtnICoc0JfuDdE/zCEdLyYfSLGXGmLLUopBCOH9+/crf VhSg== X-Gm-Message-State: AODbwcBuGJYeovHLjwbjrTO75HPwRhvzDu0XaEKo3QRu60MkJSTsI3Iv 5fGFwJ4LPMpLfmu5gGjvf5lxCcmiLw== X-Received: by 10.25.201.145 with SMTP id z139mr507236lff.172.1495796519218; Fri, 26 May 2017 04:01:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.22.73 with HTTP; Fri, 26 May 2017 04:01:58 -0700 (PDT) In-Reply-To: References: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> From: Martin Thomson Date: Fri, 26 May 2017 21:01:58 +1000 Message-ID: To: Eric Rescorla Cc: Christer Holmberg , "mmusic@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 11:02:03 -0000 On 26 May 2017 at 20:37, Eric Rescorla wrote: > Also, you say that if you initiate the handshake before the answer > is received you are vulnerable to attacks. What attacks are those? It should be "complete" - on the assumption that a completed handshake leads immediately to using the connection. Really, it's using the connection (sending or receiving data or using exporters) that puts you at risk, but I don't think that it's worth putting that fine a distinction on it. From nobody Fri May 26 04:32:23 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9410B129C67 for ; Fri, 26 May 2017 04:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 tRO5R2ytpnGw for ; Fri, 26 May 2017 04:32:20 -0700 (PDT) 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 83BAB129C62 for ; Fri, 26 May 2017 04:32:20 -0700 (PDT) X-AuditID: c1b4fb2d-5a49e9a000000d37-93-592812426d54 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 67.72.03383.24218295; Fri, 26 May 2017 13:32:18 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Fri, 26 May 2017 13:32:17 +0200 From: Christer Holmberg To: Martin Thomson , Eric Rescorla CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHSzg+3LES5P8e96kuYQ2NFd1Iy/aH22hkAgAAInQCAAAaQgIAASbSwgAjtDoD//+kCgIABw7QA///NpQCAADbcgP//zwiAAJc8RoAAAA1pgAAA2DgAAAeOUYA= Date: Fri, 26 May 2017 11:32:16 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-ID: <739029AC68C9DC45B05DEAED5FF067E6@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBIsWRmVeSWpSXmKPExsUyM2K7rq6TkEakwZorlhYrXp9jt7h25h+j xdTlj1kcmD12zrrL7rFkyU8mj8mP25gDmKO4bFJSczLLUov07RK4MqZteMhY8Iy1Ys+36ewN jJdZuhg5OCQETCTOrzfsYuTiEBI4wiix7chDVghnMaPEnSdr2UCK2AQsJLr/aXcxcnKICHhL 7Ds4gRUkzCygLnF1cRCIKSxQJXHyWR1ERbXE5uMX2UCmiAh0MUo0X13GBJJgEVCVWPYbZDwn B6+AtcTHqauYIFb9Z5OYNmUBWBGnQKDEp7crmEFsRgExie+n1oDFmQXEJW49mQ9mSwgISCzZ c54ZwhaVePn4H9g9ogJ6Eu/2e0KEFSWuTl8O1aojsWD3JzYI21ri4sM2RghbW2LZwtfMEPcI Spyc+YRlAqP4LCTbZiFpn4WkfRaS9llI2hcwsq5iFC1OLS7OTTcy1kstykwuLs7P08tLLdnE CIy/g1t+6+5gXP3a8RCjAAejEg+vlYBGpBBrYllxZe4hRgkOZiURXhlBoBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXFeh30XIoQE0hNLUrNTUwtSi2CyTBycUg2M4ZfVS5d6uvbmz7u7Q/f9Vb6/ HBMVgrr7rr5l3h2lp34iOai0coqt+nHtd1M/hIRlO2cv7WE87jArR8b2q237yk4NgfXuz7cs /sH9naci9OlSxQ9f+C37Yp9OW54aO8Mh//0Lrvqo6b28Go4nDr2XU5n0Yn3kVr2C1vv+m4/c 6Q+aJ9AZ0OugxFKckWioxVxUnAgAUzeJ07sCAAA= Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2017 11:32:21 -0000 Hi, You are the DTLS gurus - please suggest changes that makes the text correct - and still hopefully keeps Cullen happy :) Regards, Christer On 26/05/17 14:01, "Martin Thomson" wrote: >On 26 May 2017 at 20:37, Eric Rescorla wrote: >> Also, you say that if you initiate the handshake before the answer >> is received you are vulnerable to attacks. What attacks are those? > >It should be "complete" - on the assumption that a completed handshake >leads immediately to using the connection. Really, it's using the >connection (sending or receiving data or using exporters) that puts >you at risk, but I don't think that it's worth putting that fine a >distinction on it. From nobody Mon May 29 03:41:25 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04EA7126E64 for ; Mon, 29 May 2017 03:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cL_cP9VnBefd for ; Mon, 29 May 2017 03:41:22 -0700 (PDT) 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 62E7F1242F7 for ; Mon, 29 May 2017 03:41:22 -0700 (PDT) X-AuditID: c1b4fb2d-1c9ff70000000d37-f7-592bfacfe89c Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 04.B9.03383.FCAFB295; Mon, 29 May 2017 12:41:20 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.30]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0339.000; Mon, 29 May 2017 12:41:20 +0200 From: Christer Holmberg To: Martin Thomson , Eric Rescorla CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? Thread-Index: AQHSzg+3LES5P8e96kuYQ2NFd1Iy/aH22hkAgAAInQCAAAaQgIAASbSwgAjtDoD//+kCgIABw7QA///NpQCAADbcgP//zwiAAJc8RoAAAA1pgAAA2DgAAAeOUYAAlRl6AA== Date: Mon, 29 May 2017 10:41:19 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4CBA529B@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.4.170508 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <30D833F9116D634C8CB3EFE6568E530D@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM2J7lO6FX9qRBlOvC1iseH2O3eLamX+M FlOXP2ZxYPbYOesuu8eSJT+ZPCY/bmMOYI7isklJzcksSy3St0vgytg8eR5TQQN3xauTk1ka GP9wdDFyckgImEj8fnuTuYuRi0NI4AijxL4v/UwQzmJGiY97n7N0MXJwsAlYSHT/0wZpEBHw lth3cAIrSJhZQF3i6uIgEFNYoEri5LM6iIpqic3HL7KBTBERmMQo0bT/LitIgkVAVaJv6VVm EJtXwFpi+r9HUHs3sku0dTUxgiQ4BWwk7m54wwJiMwqISXw/tYYJxGYWEJe49WQ+E8TRAhJL 9pxnhrBFJV4+/gd2j6iAnsS7/Z4QYUWJq9OXQ7XqSdyYOoUNwraWmP/oHjuErS2xbOFrqHsE JU7OfMIygVF8FpJts5C0z0LSPgtJ+ywk7QsYWVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxi BEbgwS2/dXcwrn7teIhRgINRiYd3+3PtSCHWxLLiytxDjBIczEoivLcfA4V4UxIrq1KL8uOL SnNSiw8xSnOwKInzOuy7ECEkkJ5YkpqdmlqQWgSTZeLglGpgtLjFeHH9ulhJ64Uq++YKOt67 6eN3a/KDY/FrW14tfn/lq8vZGwo2OdtLPkS1Xv3WeerdibTiWBG2BjVLg64DUYy90cdU7r2Q dnaYodVfV79ANvOaSZ1V/9HUX2I8xv1WggklyzNne04WKXohz+khssBrS+yJTwGubgUGxy4f fqjDJr599REVJZbijERDLeai4kQADaPA0LwCAAA= Archived-At: Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 May 2017 10:41:24 -0000 Hi, I have updated the PR. The text now says =B3complete=B2 instead of =B3finalise=B2. In addition, I = removed the text about attacks, and only kept the text saying that media received before the answer must be considered unauthenticated. If people are still not happy with the text, I=B9d really appreciate some text. Regards, Christer On 26/05/17 14:32, "mmusic on behalf of Christer Holmberg" wrote: >Hi, > >You are the DTLS gurus - please suggest changes that makes the text >correct - and still hopefully keeps Cullen happy :) > >Regards, > >Christer > > >On 26/05/17 14:01, "Martin Thomson" wrote: > >>On 26 May 2017 at 20:37, Eric Rescorla wrote: >>> Also, you say that if you initiate the handshake before the answer >>> is received you are vulnerable to attacks. What attacks are those? >> >>It should be "complete" - on the assumption that a completed handshake >>leads immediately to using the connection. Really, it's using the >>connection (sending or receiving data or using exporters) that puts >>you at risk, but I don't think that it's worth putting that fine a >>distinction on it. > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed May 31 13:22:57 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1646129AE7 for ; Wed, 31 May 2017 13:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 w4ECKzfyDKx0 for ; Wed, 31 May 2017 13:22:54 -0700 (PDT) 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 DB98D12922E for ; Wed, 31 May 2017 13:22:53 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v4VKMqUQ016774 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 31 May 2017 15:22:53 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_B685000C-4EAC-4526-8D30-5F84578A1E1F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 31 May 2017 15:22:52 -0500 References: Cc: mmusic-chairs@ietf.org, mmusic To: Cullen Jennings , Eric Rescorla , Roman Shpount , Martin Thomson , Christer Holmberg Message-Id: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [MMUSIC] Fwd: draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 20:22:56 -0000 --Apple-Mail=_B685000C-4EAC-4526-8D30-5F84578A1E1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Can people live with the PR as it currently stands, even if it=E2=80=99s = not =E2=80=9Cperfect=E2=80=9D? If not, what would it take to be able to = live with it? It=E2=80=99s been almost 2 months since the IETF LC = completed. It would be nice to progress this soon. Thanks! Ben. > Begin forwarded message: >=20 > From: Christer Holmberg > Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS = association before it has received the SDP answer? > Date: May 29, 2017 at 5:41:19 AM CDT > To: Martin Thomson , Eric Rescorla = > Cc: "mmusic@ietf.org" >=20 > Hi, >=20 > I have updated the PR. >=20 > The text now says =C2=B3complete=C2=B2 instead of =C2=B3finalise=C2=B2. = In addition, I removed > the text about attacks, and only kept the text saying that media = received > before the answer must be considered unauthenticated. >=20 > If people are still not happy with the text, I=C2=B9d really = appreciate some > text. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > On 26/05/17 14:32, "mmusic on behalf of Christer Holmberg" > > wrote: >=20 >> Hi, >>=20 >> You are the DTLS gurus - please suggest changes that makes the text >> correct - and still hopefully keeps Cullen happy :) >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> On 26/05/17 14:01, "Martin Thomson" wrote: >>=20 >>> On 26 May 2017 at 20:37, Eric Rescorla wrote: >>>> Also, you say that if you initiate the handshake before the answer >>>> is received you are vulnerable to attacks. What attacks are those? >>>=20 >>> It should be "complete" - on the assumption that a completed = handshake >>> leads immediately to using the connection. Really, it's using the >>> connection (sending or receiving data or using exporters) that puts >>> you at risk, but I don't think that it's worth putting that fine a >>> distinction on it. >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --Apple-Mail=_B685000C-4EAC-4526-8D30-5F84578A1E1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Can = people live with the PR as it currently stands, even if it=E2=80=99s not = =E2=80=9Cperfect=E2=80=9D? If not, what would it take to be able to live = with it? It=E2=80=99s been almost 2 months since the IETF LC completed. = It would be nice to progress this soon.

Thanks!

Ben.

Begin = forwarded message:

From: = Christer Holmberg <christer.holmberg@ericsson.com>
Subject: = Re: [MMUSIC] = draft-dtls-sdp: Allow offerer to establish DTLS association before it = has received the SDP answer?
Date: = May 29, 2017 at 5:41:19 AM = CDT
To: = Martin Thomson <martin.thomson@gmail.com>, Eric Rescorla <ekr@rtfm.com>
Cc: = "mmusic@ietf.org" <mmusic@ietf.org>

Hi,

I have updated the PR.

The text now says =C2=B3complete=C2=B2 instead = of =C2=B3finalise=C2=B2. In addition, I removed
the text = about attacks, and only kept the text saying that media received
before the answer must be considered unauthenticated.

If people are still not happy with the text, = I=C2=B9d really appreciate some
text.

Regards,

Christer



On 26/05/17 = 14:32, "mmusic on behalf of Christer Holmberg"
<mmusic-bounces@ietf.org on behalf of christer.holmberg@ericsson.com>
wrote:

Hi,

You are the DTLS gurus - please suggest = changes that makes the text
correct - and still hopefully = keeps Cullen happy :)

Regards,

Christer


On 26/05/17 14:01, "Martin Thomson" <martin.thomson@gmail.com> wrote:

On 26 May 2017 at 20:37, = Eric Rescorla <ekr@rtfm.com> wrote:
Also, you say that if you initiate the = handshake before the answer
is received you are vulnerable = to attacks. What attacks are those?

It should be "complete" - on the assumption that a completed = handshake
leads immediately to using the connection. =  Really, it's using the
connection (sending or = receiving data or using exporters) that puts
you at risk, = but I don't think that it's worth putting that fine a
distinction on it.

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

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

= --Apple-Mail=_B685000C-4EAC-4526-8D30-5F84578A1E1F-- From nobody Wed May 31 14:45:52 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A513512EA24 for ; Wed, 31 May 2017 14:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable 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 IEEzQlGswxjS for ; Wed, 31 May 2017 14:45:48 -0700 (PDT) Received: from smtp82.ord1c.emailsrvr.com (smtp82.ord1c.emailsrvr.com [108.166.43.82]) (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 B0E481293F4 for ; Wed, 31 May 2017 14:45:48 -0700 (PDT) Received: from smtp19.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 9FCFEA043E; Wed, 31 May 2017 17:45:45 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id A58B8A03AA; Wed, 31 May 2017 17:45:44 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.67] (S01065475d0f7dcd1.cg.shawcable.net [70.75.17.123]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 31 May 2017 17:45:45 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> Date: Wed, 31 May 2017 15:45:43 -0600 Cc: Eric Rescorla , Roman Shpount , Martin Thomson , Christer Holmberg , mmusic-chairs@ietf.org, mmusic Content-Transfer-Encoding: quoted-printable Message-Id: <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [MMUSIC] Fwd: draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 21:45:52 -0000 No ... the draft (with the PR) does not work. The key issue is the line=20= However, the offerer MUST NOT complete the DTLS handshake before it has received the SDP answer. This breaks the usage of DTLS-SRTP with SIP and is not needed. The = argument that you should not send media before you know who it is going = to is not the problem. The key issue is that some times an SIP UA needs = to be able to receive media before it knows who it is from. Of course = the UA should indicate in the caller ID etc that it is does not know who = it is from. It might be really reasonable for the UA not to send any = human generated media before it get the the dtls-id in the offer/answer, = and validate any identity assertions, and validates in the certificates = are not revoked, and whatever else the UA wants to to but the spec = should not forbid receiving information while that is all happening. And = to receive media, it needs to complete the DTLS handshake.=20 Let me ask, for your average call flow that uses PRACK, do we think that = call flow would work if we said there could not be any media before the = Answer was received ?=20 I'm sure the next issue is just my confusion but I was under the = impression this would help solve the unauthenticated keying problem fro = DTLS-SRTP. But the dtls-id in this draft never get tied to anything in = the TLS session. Is that specified elsewhere? Do we need a ref to it ? One other issues ... It seems that this removes from RFC5763 the line=20 The SIP message containing the offer SHOULD be sent to the offerer's SIP proxy over an integrity protected channel. from RFC 5763. Any reason for that? Seems like the fingerprint should = still be integrity protected.=20 > On May 31, 2017, at 2:22 PM, Ben Campbell wrote: >=20 >=20 > Can people live with the PR as it currently stands, even if it=E2=80=99s= not =E2=80=9Cperfect=E2=80=9D? If not, what would it take to be able to = live with it? It=E2=80=99s been almost 2 months since the IETF LC = completed. It would be nice to progress this soon. >=20 > Thanks! >=20 > Ben. >=20 >> Begin forwarded message: >>=20 >> From: Christer Holmberg >> Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS = association before it has received the SDP answer? >> Date: May 29, 2017 at 5:41:19 AM CDT >> To: Martin Thomson , Eric Rescorla = >> Cc: "mmusic@ietf.org" >>=20 >> Hi, >>=20 >> I have updated the PR. >>=20 >> The text now says =C2=B3complete=C2=B2 instead of =C2=B3finalise=C2=B2.= In addition, I removed >> the text about attacks, and only kept the text saying that media = received >> before the answer must be considered unauthenticated. >>=20 >> If people are still not happy with the text, I=C2=B9d really = appreciate some >> text. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >> On 26/05/17 14:32, "mmusic on behalf of Christer Holmberg" >> >> wrote: >>=20 >>> Hi, >>>=20 >>> You are the DTLS gurus - please suggest changes that makes the text >>> correct - and still hopefully keeps Cullen happy :) >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>> On 26/05/17 14:01, "Martin Thomson" = wrote: >>>=20 >>>> On 26 May 2017 at 20:37, Eric Rescorla wrote: >>>>> Also, you say that if you initiate the handshake before the answer >>>>> is received you are vulnerable to attacks. What attacks are those? >>>>=20 >>>> It should be "complete" - on the assumption that a completed = handshake >>>> leads immediately to using the connection. Really, it's using the >>>> connection (sending or receiving data or using exporters) that puts >>>> you at risk, but I don't think that it's worth putting that fine a >>>> distinction on it. >>>=20 >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>=20 >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed May 31 15:52:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF2C127F0E for ; Wed, 31 May 2017 15:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 tASc5nlR3vK5 for ; Wed, 31 May 2017 15:51:59 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 D83C0124D37 for ; Wed, 31 May 2017 15:51:58 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id e193so19856138pfh.0 for ; Wed, 31 May 2017 15:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uE/wgbNbcUAw/IZYGPE5XZn+Yt/tC8N5acTJA7qyGsE=; b=TxGN6KI85dKOIHC8SLS/TpueP4UU2krU6zdiAFYT1X4soCE/+5uBFIGbHde9fETZq4 c/t5MGStR9x66rLVgzE3dQ224bn+z1OJWiHPw+owQ84XP3Xxv0xb/c7A4cXWP4CzksN7 1id4JHSYQcgPbeFOZr0NKIv2vFgxbGAff1zJbB3Mtq6rtKSFG/H7ZXQbyZbePP+9eerY 58qnKrdYUqPTIvmR9d8PGc6YJy7PNr/SwcfKmH3VRCzBHJlj/h0QysDElgRsTw6cGPzQ uTREHRZFi9VgKoWMhV/caAxiFoq9X4+d/qiVIBxFe9Do20hISOya697osFse80U3JjTk vvUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uE/wgbNbcUAw/IZYGPE5XZn+Yt/tC8N5acTJA7qyGsE=; b=KzB/nOLobRCH6wJ5LMkLwzqxJJc7KPBraONU42x1DdvxwD+aOfoVbomY0zLqxcc1CV nCiQbPme2vG6M8S68Ecyoej7PXPM00Xj+evRgQSVQbA25BH+NjqUs3tA2pftoKWyvkBN 7CJSeiVG8qG+tLYxWub1Og4oCnVK+veiRlnR5DEPMY4TRe/ribjx3bV/cwz/PvrBsLvK rjx1aQ0kjAh1XbV/W4YNKlw3quPVaVMq5xnmKkkcFXtJN2ktVwMvQmNlhKB0n3hlodMa vn7KrUl2j6J9AZleDvXTrF5z4BXBcVp17iJo/5kiToonbUwNW8JOBTKrta+DpA9G98OL CiAg== X-Gm-Message-State: AODbwcDcpWiEp0TOT0PhfirgflCniyCid3c4/TxXFRDOyjwKM/eRUbI/ kKCwzPAM8UPGAY48FnA= X-Received: by 10.98.61.207 with SMTP id x76mr32477930pfj.170.1496271118372; Wed, 31 May 2017 15:51:58 -0700 (PDT) Received: from mail-pf0-f170.google.com (mail-pf0-f170.google.com. [209.85.192.170]) by smtp.gmail.com with ESMTPSA id s68sm32601492pfj.5.2017.05.31.15.51.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 May 2017 15:51:57 -0700 (PDT) Received: by mail-pf0-f170.google.com with SMTP id 9so19809388pfj.1; Wed, 31 May 2017 15:51:57 -0700 (PDT) X-Received: by 10.84.248.4 with SMTP id p4mr77232626pll.155.1496271117488; Wed, 31 May 2017 15:51:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.169.66 with HTTP; Wed, 31 May 2017 15:51:56 -0700 (PDT) In-Reply-To: <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> References: <22C94242-218F-4724-AE92-E0B1E8DC2C82@nostrum.com> <21E8BA9D-E442-4DBC-8A7D-CEDFD5F54F8B@iii.ca> From: Roman Shpount Date: Wed, 31 May 2017 18:51:56 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Cullen Jennings Cc: Ben Campbell , Eric Rescorla , Martin Thomson , Christer Holmberg , mmusic-chairs@ietf.org, mmusic Content-Type: multipart/alternative; boundary="f403045fff667221120550d9c49d" Archived-At: Subject: Re: [MMUSIC] Fwd: draft-dtls-sdp: Allow offerer to establish DTLS association before it has received the SDP answer? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 22:52:01 -0000 --f403045fff667221120550d9c49d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, I will try to put together a new pull request that will address Cullen's concerns. What I want to propose is: 1. Starting DTLS handshake until the corresponded answer is received is NOT RECOMMENDED since it can result in unauthenticated media. If unauthenticated media is played to the end user, in cases such as early media in SIP calls, this should be indicated to the end user. 2. If DTLS associations are established before the corresponding answers are received, these associations MUST be torn down when no more answers are expected and no matching fingerprints are found. So, as a result, unauthenticated media is NOT RECOMMENDED, but still allowed. End user SHOULD be properly warned when unauthenticated media is played. SIP is saved. Finally, to provide secure solution for 1-800-GOFEDEX scenario with full ICE end points, trickle ICE should be extended to provide tls-id and fingerprint. This way DTLS association can be established before codecs are negotiated, which should allow full featured bridging with SIP. Regards, _____________ Roman Shpount On Wed, May 31, 2017 at 5:45 PM, Cullen Jennings wrote: > > No ... the draft (with the PR) does not work. The key issue is the line > > However, the offerer MUST NOT > complete the DTLS handshake before it has received the SDP answer. > > This breaks the usage of DTLS-SRTP with SIP and is not needed. The > argument that you should not send media before you know who it is going t= o > is not the problem. The key issue is that some times an SIP UA needs to = be > able to receive media before it knows who it is from. Of course the UA > should indicate in the caller ID etc that it is does not know who it is > from. It might be really reasonable for the UA not to send any human > generated media before it get the the dtls-id in the offer/answer, and > validate any identity assertions, and validates in the certificates are n= ot > revoked, and whatever else the UA wants to to but the spec should not > forbid receiving information while that is all happening. And to receive > media, it needs to complete the DTLS handshake. > > Let me ask, for your average call flow that uses PRACK, do we think that > call flow would work if we said there could not be any media before the > Answer was received ? > > > I'm sure the next issue is just my confusion but I was under the > impression this would help solve the unauthenticated keying problem fro > DTLS-SRTP. But the dtls-id in this draft never get tied to anything in th= e > TLS session. Is that specified elsewhere? Do we need a ref to it ? > > One other issues ... It seems that this removes from RFC5763 the line > > The SIP message containing the offer SHOULD be sent to > the offerer's SIP proxy over an integrity protected channel. > > from RFC 5763. Any reason for that? Seems like the fingerprint should > still be integrity protected. > > > > > > > > On May 31, 2017, at 2:22 PM, Ben Campbell wrote: > > > > > > Can people live with the PR as it currently stands, even if it=E2=80=99= s not > =E2=80=9Cperfect=E2=80=9D? If not, what would it take to be able to live = with it? It=E2=80=99s been > almost 2 months since the IETF LC completed. It would be nice to progress > this soon. > > > > Thanks! > > > > Ben. > > > >> Begin forwarded message: > >> > >> From: Christer Holmberg > >> Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish DTLS > association before it has received the SDP answer? > >> Date: May 29, 2017 at 5:41:19 AM CDT > >> To: Martin Thomson , Eric Rescorla < > ekr@rtfm.com> > >> Cc: "mmusic@ietf.org" > >> > >> Hi, > >> > >> I have updated the PR. > >> > >> The text now says =C2=B3complete=C2=B2 instead of =C2=B3finalise=C2=B2= . In addition, I > removed > >> the text about attacks, and only kept the text saying that media > received > >> before the answer must be considered unauthenticated. > >> > >> If people are still not happy with the text, I=C2=B9d really appreciat= e some > >> text. > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> On 26/05/17 14:32, "mmusic on behalf of Christer Holmberg" > >> > >> wrote: > >> > >>> Hi, > >>> > >>> You are the DTLS gurus - please suggest changes that makes the text > >>> correct - and still hopefully keeps Cullen happy :) > >>> > >>> Regards, > >>> > >>> Christer > >>> > >>> > >>> On 26/05/17 14:01, "Martin Thomson" wrote: > >>> > >>>> On 26 May 2017 at 20:37, Eric Rescorla wrote: > >>>>> Also, you say that if you initiate the handshake before the answer > >>>>> is received you are vulnerable to attacks. What attacks are those? > >>>> > >>>> It should be "complete" - on the assumption that a completed handsha= ke > >>>> leads immediately to using the connection. Really, it's using the > >>>> connection (sending or receiving data or using exporters) that puts > >>>> you at risk, but I don't think that it's worth putting that fine a > >>>> distinction on it. > >>> > >>> _______________________________________________ > >>> mmusic mailing list > >>> mmusic@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mmusic > >> > >> _______________________________________________ > >> mmusic mailing list > >> mmusic@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www.ietf.org/mailman/listinfo/mmusic > > --f403045fff667221120550d9c49d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I will try to put together a ne= w pull request that will address Cullen's concerns.

What I want to propose is:

1. Starting DTLS = handshake until the corresponded answer is received is NOT RECOMMENDED sinc= e it can result in unauthenticated media. If unauthenticated media is playe= d to the end user, in cases such as early media in SIP calls, this should b= e indicated to the end user.

2. If DTLS associatio= ns are established before the corresponding answers are received, these ass= ociations MUST be torn down when no more answers are expected and no matchi= ng fingerprints are found.

So, as a result, unauth= enticated media is NOT RECOMMENDED, but still allowed. End user SHOULD be p= roperly warned when unauthenticated media is played. SIP is saved.

Finally, to provide secure solution for 1-800-GOFEDEX scen= ario with full ICE end points, trickle ICE should be extended to provide tl= s-id and fingerprint. This way DTLS association can be established before c= odecs are negotiated, which should allow full featured bridging with SIP.

Regards,

_____________
Roman Shpount

On Wed, May 31, 2017 at 5:45 PM, Cullen Jenn= ings <fluffy@iii.ca> wrote:
No ... the draft (with the PR) does not work. The key issue is the line

=C2=A0 =C2=A0However, the offerer MUST NOT
=C2=A0 =C2=A0complete the DTLS handshake before it has received the SDP ans= wer.

This breaks the usage of DTLS-SRTP with SIP and is not needed. The argument= that you should not send media before you know who it is going to is not t= he problem. The key issue is that some times an SIP UA=C2=A0 needs to be ab= le to receive media before it knows who it is from. Of course the UA should= indicate in the caller ID etc that it is does not know who it is from. It = might be really reasonable for the UA not to send any human generated media= before it get the the dtls-id in the offer/answer, and validate any identi= ty assertions, and validates in the certificates are not revoked, and whate= ver else the UA wants to to but the spec should not forbid receiving inform= ation while that is all happening. And to receive media, it needs to comple= te the DTLS handshake.

Let me ask, for your average call flow that uses PRACK, do we think that ca= ll flow would work if we said there could not be any media before the Answe= r was received ?


I'm sure the next issue is just my confusion but I was under the impres= sion this would help solve the unauthenticated keying problem fro DTLS-SRTP= . But the dtls-id in this draft never get tied to anything in the TLS sessi= on. Is that specified elsewhere? Do we need a ref to it ?

One other issues ... It seems that this removes from RFC5763 the line

=C2=A0 The SIP message containing the offer SHOULD be sent to
=C2=A0 =C2=A0the offerer's SIP proxy over an integrity protected channe= l.

from RFC 5763. Any reason for that? Seems like the fingerprint should still= be integrity protected.






> On May 31, 2017, at 2:22 PM, Ben Campbell <ben@nostrum.com> wrote:
>
>
> Can people live with the PR as it currently stands, even if it=E2=80= =99s not =E2=80=9Cperfect=E2=80=9D? If not, what would it take to be able t= o live with it? It=E2=80=99s been almost 2 months since the IETF LC complet= ed. It would be nice to progress this soon.
>
> Thanks!
>
> Ben.
>
>> Begin forwarded message:
>>
>> From: Christer Holmberg <christer.holmberg@ericsson.com>
>> Subject: Re: [MMUSIC] draft-dtls-sdp: Allow offerer to establish D= TLS association before it has received the SDP answer?
>> Date: May 29, 2017 at 5:41:19 AM CDT
>> To: Martin Thomson <martin.thomson@gmail.com>, Eric Rescorla <ekr@rtfm.com>
>> Cc: "mmusic@ietf.org&q= uot; <mmusic@ietf.org>
>>
>> Hi,
>>
>> I have updated the PR.
>>
>> The text now says =C2=B3complete=C2=B2 instead of =C2=B3finalise= =C2=B2. In addition, I removed
>> the text about attacks, and only kept the text saying that media r= eceived
>> before the answer must be considered unauthenticated.
>>
>> If people are still not happy with the text, I=C2=B9d really appre= ciate some
>> text.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> On 26/05/17 14:32, "mmusic on behalf of Christer Holmberg&quo= t;
>> <mmusic-bounces@ietf= .org on behalf of chr= ister.holmberg@ericsson.com>
>> wrote:
>>
>>> Hi,
>>>
>>> You are the DTLS gurus - please suggest changes that makes the= text
>>> correct - and still hopefully keeps Cullen happy :)
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>>
>>> On 26/05/17 14:01, "Martin Thomson" <martin.thomson@gmail.com> wrote:
>>>
>>>> On 26 May 2017 at 20:37, Eric Rescorla <ekr@rtfm.com> wrote:
>>>>> Also, you say that if you initiate the handshake befor= e the answer
>>>>> is received you are vulnerable to attacks. What attack= s are those?
>>>>
>>>> It should be "complete" - on the assumption that= a completed handshake
>>>> leads immediately to using the connection.=C2=A0 Really, i= t's using the
>>>> connection (sending or receiving data or using exporters) = that puts
>>>> you at risk, but I don't think that it's worth put= ting that fine a
>>>> distinction on it.
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinf= o/mmusic
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmus= ic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic


--f403045fff667221120550d9c49d--