From simon.perreault@viagenie.ca Mon Feb 3 07:53:12 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6707B1A0035 for ; Mon, 3 Feb 2014 07:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham 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 4rCDw-dj5WkN for ; Mon, 3 Feb 2014 07:53:11 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 379481A002B for ; Mon, 3 Feb 2014 07:53:11 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id ECA0B40379 for ; Mon, 3 Feb 2014 10:53:10 -0500 (EST) Message-ID: <52EFBB66.90401@viagenie.ca> Date: Mon, 03 Feb 2014 10:53:10 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:53:12 -0000 Le 2014-01-31 17:48, Oleg Moskalenko a écrit : > Also, this draft talks exclusively about TURN over DTLS. What about > STUN over DTLS? I was thinking about DTLS for STUN for gathering > reflexive candidates for setting up a data channel-only Peer > Connection. Having DTLS between the STUN client and server could > provide confidentiality for STUN attributes. Does this make sense? > if not, are we sure there are no other STUN use cases? > > > I am not sure that STUN over DTLS makes sense. While we do support it in > our project, I do not see what information to be protected in STUN > requests. It can be mentioned, done and implemented, but I fail to see > the point. There is no secure non-public information in the STUN Binding > request and response. It may not make operational sense, but it makes total protocol design sense. UDP, TCP, and TLS transports are defined for STUN, in RFC 5389. TURN is just a set of new opcodes, and it inherits STUN's transports. So this draft should apply exclusively to STUN. TURN could be mentioned in passing, e.g. "by the way, TURN can make use of this new transport too." (One caveat being TURN *channels*, about which this draft should be very explicit.) Now, whether clients or servers use DTLS for Binding requests, that's a completely orthogonal question. A few words could be said about that in an "Operational Considerations" section. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From alan.b.johnston@gmail.com Mon Feb 3 09:23:59 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA6F1A0158 for ; Mon, 3 Feb 2014 09:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 BFyGsN8Rrx_M for ; Mon, 3 Feb 2014 09:23:56 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCDE1A0122 for ; Mon, 3 Feb 2014 09:23:56 -0800 (PST) Received: by mail-pa0-f45.google.com with SMTP id lf10so7342834pab.32 for ; Mon, 03 Feb 2014 09:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IEcrSIclqPBxZZdRpLUDU6vHdNv1XozzrM51JXybJdE=; b=N9jZ7ukHUD18g11u8kFIWoJaGt03CxKkJv8XF80wPdTCT4d2lPqACj5BqlNApxhzCe ch6dvgkdVKtku+P8oXBOqzu0xsBXYgrdtSpZk0AYk5lfgPtavWT4GV44GHdSVUHtOwNK ncp4Vq2lr8csGLL6X2eTjN/07wOvScHg85NXt3/qktL7wJx8Fi/34/9tvoiHL1QwoeSY /TGv9Gv5qh+nY7Ngv51GraGKwMq1N5KP6WwQYPhWOx0efDyOk2qhLTyzhlILybT/hxGf zch3u3C/Nx8IQmsu9TW+2wkIDb03gNkW2nap1/pPE6zTESVENnECH4BFrk26GACUBlLj bgGA== MIME-Version: 1.0 X-Received: by 10.67.3.97 with SMTP id bv1mr38603472pad.54.1391448235994; Mon, 03 Feb 2014 09:23:55 -0800 (PST) Received: by 10.68.168.132 with HTTP; Mon, 3 Feb 2014 09:23:55 -0800 (PST) In-Reply-To: <52EFBB66.90401@viagenie.ca> References: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> <52EFBB66.90401@viagenie.ca> Date: Mon, 3 Feb 2014 11:23:55 -0600 Message-ID: From: Alan Johnston To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b15aeb1d4722a04f183c949 Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 17:23:59 -0000 --047d7b15aeb1d4722a04f183c949 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A few comments below to Oleg & Simon. - Alan - On Mon, Feb 3, 2014 at 9:53 AM, Simon Perreault wrote: > Le 2014-01-31 17:48, Oleg Moskalenko a =E9crit : > > Also, this draft talks exclusively about TURN over DTLS. What abou= t > > STUN over DTLS? I was thinking about DTLS for STUN for gathering > > reflexive candidates for setting up a data channel-only Peer > > Connection. Having DTLS between the STUN client and server could > > provide confidentiality for STUN attributes. Does this make sense= ? > > if not, are we sure there are no other STUN use cases? > > > > > > I am not sure that STUN over DTLS makes sense. While we do support it i= n > > our project, I do not see what information to be protected in STUN > > requests. It can be mentioned, done and implemented, but I fail to see > > the point. There is no secure non-public information in the STUN Bindin= g > > request and response. > > Well, in the post-Snowden era, we need think carefully about this. First of all, STUN binding requests can indicate that an Internet user is preparing to establish a real-time communications session. This could be useful information to an attacker or eavesdropper. Secondly, additional information in STUN attributes, such as ORIGIN could leak other information= . Also, remember that SRTP doesn't encrypt the RTP header, and thus leaks information about the type of session being established and the fact that a real-time session is taking place. One day we might want to run SRTP over DTLS to hide this information. Essentially, in this new world, STUN & TURN take the place of a signaling protocol, so providing the highest level of security for them can be useful. I would be very disinclined to rule out STUN over DTLS right now. It may not make operational sense, but it makes total protocol design sense= . > > UDP, TCP, and TLS transports are defined for STUN, in RFC 5389. TURN is > just a set of new opcodes, and it inherits STUN's transports. So this > draft should apply exclusively to STUN. TURN could be mentioned in > passing, e.g. "by the way, TURN can make use of this new transport too." > > I agree that we need to be very clear about this in drafts, and not just talk about TURN because that is where we see the most important use case. The name of this proposed working group is a little unfortunate in that sense, since we will really be doing STUN extensions most of the time. > (One caveat being TURN *channels*, about which this draft should be very > explicit.) > > Now, whether clients or servers use DTLS for Binding requests, that's a > completely orthogonal question. A few words could be said about that in > an "Operational Considerations" section. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b15aeb1d4722a04f183c949 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A few comments below to Oleg & Simon.

- Alan -


On Mon, Feb 3, 2014 at 9:53 AM, Simon Perreault <simon.perreau= lt@viagenie.ca> wrote:
Le 2014-01-31 17:48, Oleg Moskalenko a =E9cr= it :
> =A0 =A0 Also, this draft talks exclusively about TURN over DTLS. =A0Wh= at about
> =A0 =A0 STUN over DTLS? =A0I was thinking about DTLS for STUN for gath= ering
> =A0 =A0 reflexive candidates for setting up a data channel-only Peer > =A0 =A0 Connection. =A0Having DTLS between the STUN client and server = could
> =A0 =A0 =A0provide confidentiality for STUN attributes. =A0Does this m= ake sense?
> =A0 =A0 =A0if not, are we sure there are no other STUN use cases?
>
>
> I am not sure that STUN over DTLS makes sense. While we do support it = in
> our project, I do not see what information to be protected in STUN
> requests. It can be mentioned, done and implemented, but I fail to see=
> the point. There is no secure non-public information in the STUN Bindi= ng
> request and response.


Well, in the post-Snowden era, we need= think carefully about this. =A0First of all, STUN binding requests can ind= icate that an Internet user is preparing to establish a real-time communica= tions session. =A0This could be useful information to an attacker or eavesd= ropper. =A0Secondly, additional information in STUN attributes, such as ORI= GIN could leak other information.

Also, remember that SRTP doesn't encrypt the RTP he= ader, and thus leaks information about the type of session being establishe= d and the fact that a real-time session is taking place. =A0One day we migh= t want to run SRTP over DTLS to hide this information.

Essentially, in this new world, STUN & TURN take th= e place of a signaling protocol, so providing the highest level of security= for them can be useful. I would be very disinclined to rule out STUN over = DTLS right now.

It may not make operational sense, but it makes total protocol design sense= .

UDP, TCP, and TLS transports are defined for STUN, in RFC 5389. TURN is
just a set of new opcodes, and it inherits STUN's transports. So this draft should apply exclusively to STUN. TURN could be mentioned in
passing, e.g. "by the way, TURN can make use of this new transport too= ."


I agree that we need to be very clear = about this in drafts, and not just talk about TURN because that is where we= see the most important use case. =A0The name of this proposed working grou= p is a little unfortunate in that sense, since we will really be doing STUN= extensions most of the time.
=A0
(One caveat being TURN *channels*, about which this draft should be very explicit.)

Now, whether clients or servers use DTLS for Binding requests, that's a=
completely orthogonal question. A few words could be said about that in
an "Operational Considerations" section.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b15aeb1d4722a04f183c949-- From mom040267@gmail.com Mon Feb 3 09:33:52 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EC11A01CF for ; Mon, 3 Feb 2014 09:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 CpPf_4VG9Iux for ; Mon, 3 Feb 2014 09:33:50 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5C11A1A01CC for ; Mon, 3 Feb 2014 09:33:50 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so7059355pde.6 for ; Mon, 03 Feb 2014 09:33:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kn4gucNPKYUlthMJjaRRZh3D0VrVFqosau4beVP8Ais=; b=q1XFhMbHmvBY8PH3nfeJvrOKH2KpsLiACkeJZpm38pIeqfy8U08RzneDG851CDdcx4 NASMudi+RxrcStUKlt/rwZrZoMB1XJ8sj9VWvzgZjC7zrUYZ8n9Oe8Df13OQRNVakNWE egmhCPZ68VsKEdJRBDneGXo99TihkThwLUaguKyKAOPdz4UwosqnkMxTGj8X/0SbPahF iARX/0mCDb7eMFAbFVQ4SNaoSqAYkw6Pk788Gsp1+1SEPewyNWZuG0zPWtfk5VdTkOzN rQFkd0R3EoaWrUOk5//PqJcj1tjHfRwzNHXVlGdUFHUFqsifZXOa9vtgodS2UqVMiV0/ ow+A== MIME-Version: 1.0 X-Received: by 10.67.14.231 with SMTP id fj7mr37813092pad.115.1391448830382; Mon, 03 Feb 2014 09:33:50 -0800 (PST) Received: by 10.68.147.131 with HTTP; Mon, 3 Feb 2014 09:33:50 -0800 (PST) In-Reply-To: References: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> <52EFBB66.90401@viagenie.ca> Date: Mon, 3 Feb 2014 09:33:50 -0800 Message-ID: From: Oleg Moskalenko To: Alan Johnston Content-Type: multipart/alternative; boundary=001a113453ec42159304f183ed86 Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 17:33:52 -0000 --001a113453ec42159304f183ed86 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alan and Simon, I have no objections. If we are talking about STUN as a protocol (not just Binding request) then that's totally fine. Thanks Oleg On Mon, Feb 3, 2014 at 9:23 AM, Alan Johnston wr= ote: > A few comments below to Oleg & Simon. > > - Alan - > > > On Mon, Feb 3, 2014 at 9:53 AM, Simon Perreault < > simon.perreault@viagenie.ca> wrote: > >> Le 2014-01-31 17:48, Oleg Moskalenko a =E9crit : >> > Also, this draft talks exclusively about TURN over DTLS. What abo= ut >> > STUN over DTLS? I was thinking about DTLS for STUN for gathering >> > reflexive candidates for setting up a data channel-only Peer >> > Connection. Having DTLS between the STUN client and server could >> > provide confidentiality for STUN attributes. Does this make sens= e? >> > if not, are we sure there are no other STUN use cases? >> > >> > >> > I am not sure that STUN over DTLS makes sense. While we do support it = in >> > our project, I do not see what information to be protected in STUN >> > requests. It can be mentioned, done and implemented, but I fail to see >> > the point. There is no secure non-public information in the STUN Bindi= ng >> > request and response. >> >> > Well, in the post-Snowden era, we need think carefully about this. First > of all, STUN binding requests can indicate that an Internet user is > preparing to establish a real-time communications session. This could be > useful information to an attacker or eavesdropper. Secondly, additional > information in STUN attributes, such as ORIGIN could leak other informati= on. > > Also, remember that SRTP doesn't encrypt the RTP header, and thus leaks > information about the type of session being established and the fact that= a > real-time session is taking place. One day we might want to run SRTP ove= r > DTLS to hide this information. > > Essentially, in this new world, STUN & TURN take the place of a signaling > protocol, so providing the highest level of security for them can be > useful. I would be very disinclined to rule out STUN over DTLS right now. > > It may not make operational sense, but it makes total protocol design >> sense. >> >> UDP, TCP, and TLS transports are defined for STUN, in RFC 5389. TURN is >> just a set of new opcodes, and it inherits STUN's transports. So this >> draft should apply exclusively to STUN. TURN could be mentioned in >> passing, e.g. "by the way, TURN can make use of this new transport too." >> >> > I agree that we need to be very clear about this in drafts, and not just > talk about TURN because that is where we see the most important use case. > The name of this proposed working group is a little unfortunate in that > sense, since we will really be doing STUN extensions most of the time. > > >> (One caveat being TURN *channels*, about which this draft should be very >> explicit.) >> >> Now, whether clients or servers use DTLS for Binding requests, that's a >> completely orthogonal question. A few words could be said about that in >> an "Operational Considerations" section. >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --001a113453ec42159304f183ed86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Alan and Simon, I have no objections. If we are talki= ng about STUN as a protocol (not just Binding request) then that's tota= lly fine.


Thanks
Oleg


On Mon, Feb 3, 2014 at 9:23 AM, Alan Joh= nston <alan.b.johnston@gmail.com> wrote:
A few comments below to Oleg & Simon.

- Alan -


On Mon, Feb 3, 2014 at 9:53 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
Le 2014-01-31 17:48, Oleg Moskalenko a =E9cr= it :
> =A0 =A0 Also, this draft talks exclusively about TURN over DTLS. =A0Wh= at about
> =A0 =A0 STUN over DTLS? =A0I was thinking about DTLS for STUN for gath= ering
> =A0 =A0 reflexive candidates for setting up a data channel-only Peer > =A0 =A0 Connection. =A0Having DTLS between the STUN client and server = could
> =A0 =A0 =A0provide confidentiality for STUN attributes. =A0Does this m= ake sense?
> =A0 =A0 =A0if not, are we sure there are no other STUN use cases?
>
>
> I am not sure that STUN over DTLS makes sense. While we do support it = in
> our project, I do not see what information to be protected in STUN
> requests. It can be mentioned, done and implemented, but I fail to see=
> the point. There is no secure non-public information in the STUN Bindi= ng
> request and response.


Well, in the post-Snowden era, w= e need think carefully about this. =A0First of all, STUN binding requests c= an indicate that an Internet user is preparing to establish a real-time com= munications session. =A0This could be useful information to an attacker or = eavesdropper. =A0Secondly, additional information in STUN attributes, such = as ORIGIN could leak other information.

Also, remember that SRTP doesn't encrypt the RTP he= ader, and thus leaks information about the type of session being establishe= d and the fact that a real-time session is taking place. =A0One day we migh= t want to run SRTP over DTLS to hide this information.

Essentially, in this new world, STUN & TURN take th= e place of a signaling protocol, so providing the highest level of security= for them can be useful. I would be very disinclined to rule out STUN over = DTLS right now.

It may not make operational sense, but it makes total protocol design sense= .

UDP, TCP, and TLS transports are defined for STUN, in RFC 5389. TURN is
just a set of new opcodes, and it inherits STUN's transports. So this draft should apply exclusively to STUN. TURN could be mentioned in
passing, e.g. "by the way, TURN can make use of this new transport too= ."


I agree that we need to be very = clear about this in drafts, and not just talk about TURN because that is wh= ere we see the most important use case. =A0The name of this proposed workin= g group is a little unfortunate in that sense, since we will really be doin= g STUN extensions most of the time.
=A0
(One caveat being TURN *channels*, about which this draft should be very explicit.)

Now, whether clients or servers use DTLS for Binding requests, that's a=
completely orthogonal question. A few words could be said about that in
an "Operational Considerations" section.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--001a113453ec42159304f183ed86-- From tireddy@cisco.com Tue Feb 4 01:53:58 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2065F1A03E7 for ; Tue, 4 Feb 2014 01:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 B1OzYy8plCCx for ; Tue, 4 Feb 2014 01:53:56 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBF71A0388 for ; Tue, 4 Feb 2014 01:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14432; q=dns/txt; s=iport; t=1391507636; x=1392717236; h=from:to:cc:subject:date:message-id:mime-version; bh=QhsyCET1mAZb6vz7GuksO7RKPiYyjhW3X5GupUqNChQ=; b=W1tdidnzj+3oNG6CdiANGa8H5nxls4U0EJMuVa+VbQLB23LvrSIpRvqb F1ederhupU4CbvlL8ANmHl150L8jPD0+Gk5C9a4UJihhomPJZymxlDl7A mA6+rap6zWY96r/COjVa0RitZ5nCmk2iP5C02bIiwlF2BKSi/mwleOMNn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowIAHS48FKtJV2c/2dsb2JhbABZgkhEOFerAopAiFaBCRZ0giUBAQEEAQEBJAZBCxIBCBEEAQELHS4LFAkJAQQBDQUIh30NzjcXjjMRLQQGCoMbgRQEiRGQS5Bvgy2BakA X-IronPort-AV: E=Sophos;i="4.95,778,1384300800"; d="scan'208,217";a="17762178" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 04 Feb 2014 09:53:54 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s149rsuS026522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Feb 2014 09:53:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 4 Feb 2014 03:53:54 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Alan Johnston , Simon Perreault Thread-Topic: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt Thread-Index: Ac8hjv+VvUmuJrPgQt2EUgCF1DuGLg== Date: Tue, 4 Feb 2014 09:53:53 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242A74CB@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.77.246] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242A74CBxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 09:53:58 -0000 --_000_913383AAA69FF945B8F946018B75898A242A74CBxmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Simon response, STUN over DTLS only makes sense from protocol = design aspect. The privacy problem mentioned below with STUN can be addressed by TURN itse= lf, TURN server could also be used to learn server-reflexive candidate and = there is no need wait for STUN servers to be upgraded. ICE connectivity che= cks use STUN which is a good indicator for an attacker to find that the 5-t= uple could be used for media streams. So if privacy is a concern then only = relayed candidates should be advertised in offer/answer. -Tiru. From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Monday, February 03, 2014 10:54 PM To: Simon Perreault Cc: tram@ietf.org Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt A few comments below to Oleg & Simon. - Alan - On Mon, Feb 3, 2014 at 9:53 AM, Simon Perreault > wrote: Le 2014-01-31 17:48, Oleg Moskalenko a =E9crit : > Also, this draft talks exclusively about TURN over DTLS. What about > STUN over DTLS? I was thinking about DTLS for STUN for gathering > reflexive candidates for setting up a data channel-only Peer > Connection. Having DTLS between the STUN client and server could > provide confidentiality for STUN attributes. Does this make sense? > if not, are we sure there are no other STUN use cases? > > > I am not sure that STUN over DTLS makes sense. While we do support it in > our project, I do not see what information to be protected in STUN > requests. It can be mentioned, done and implemented, but I fail to see > the point. There is no secure non-public information in the STUN Binding > request and response. Well, in the post-Snowden era, we need think carefully about this. First o= f all, STUN binding requests can indicate that an Internet user is preparin= g to establish a real-time communications session. This could be useful in= formation to an attacker or eavesdropper. Secondly, additional information= in STUN attributes, such as ORIGIN could leak other information. Also, remember that SRTP doesn't encrypt the RTP header, and thus leaks inf= ormation about the type of session being established and the fact that a re= al-time session is taking place. One day we might want to run SRTP over DT= LS to hide this information. Essentially, in this new world, STUN & TURN take the place of a signaling p= rotocol, so providing the highest level of security for them can be useful.= I would be very disinclined to rule out STUN over DTLS right now. It may not make operational sense, but it makes total protocol design sense= . UDP, TCP, and TLS transports are defined for STUN, in RFC 5389. TURN is just a set of new opcodes, and it inherits STUN's transports. So this draft should apply exclusively to STUN. TURN could be mentioned in passing, e.g. "by the way, TURN can make use of this new transport too." I agree that we need to be very clear about this in drafts, and not just ta= lk about TURN because that is where we see the most important use case. Th= e name of this proposed working group is a little unfortunate in that sense= , since we will really be doing STUN extensions most of the time. (One caveat being TURN *channels*, about which this draft should be very explicit.) Now, whether clients or servers use DTLS for Binding requests, that's a completely orthogonal question. A few words could be said about that in an "Operational Considerations" section. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_913383AAA69FF945B8F946018B75898A242A74CBxmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I agree with Simon respon= se, STUN over DTLS only makes sense from protocol design aspect.=

 <= /p>

The privacy problem menti= oned below with STUN can be addressed by TURN itself, TURN server could als= o be used to learn server-reflexive candidate and there is no need wait for STUN servers to be upgraded. ICE connectivity checks u= se STUN which is a good indicator for an attacker to find that the 5-tuple = could be used for media streams. So if privacy is a concern then only relay= ed candidates should be advertised in offer/answer.  

 <= /p>

-Tiru.

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Alan Johnston
Sent: Monday, February 03, 2014 10:54 PM
To: Simon Perreault
Cc: tram@ietf.org
Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-0= 0.txt

 

A few comments below to Oleg & Simon.=

 

- Alan -

 

On Mon, Feb 3, 2014 at 9:53 AM, Simon Perreault <= simon.perr= eault@viagenie.ca> wrote:

Le 2014-01-31 17:48, = Oleg Moskalenko a =E9crit :
>     Also, this draft talks exclusively about TURN over DTLS.=  What about
>     STUN over DTLS?  I was thinking about DTLS for STUN= for gathering
>     reflexive candidates for setting up a data channel-only = Peer
>     Connection.  Having DTLS between the STUN client an= d server could
>      provide confidentiality for STUN attributes.  = ;Does this make sense?
>      if not, are we sure there are no other STUN use ca= ses?
>
>
> I am not sure that STUN over DTLS makes sense. While we do support it = in
> our project, I do not see what information to be protected in STUN
> requests. It can be mentioned, done and implemented, but I fail to see=
> the point. There is no secure non-public information in the STUN Bindi= ng
> request and response.

 

Well, in the post-Snowden era, we need think careful= ly about this.  First of all, STUN binding requests can indicate that = an Internet user is preparing to establish a real-time communications sessi= on.  This could be useful information to an attacker or eavesdropper.  Secondly, additional information in STU= N attributes, such as ORIGIN could leak other information.

 

Also, remember that SRTP doesn't encrypt the RTP hea= der, and thus leaks information about the type of session being established= and the fact that a real-time session is taking place.  One day we mi= ght want to run SRTP over DTLS to hide this information.

 

Essentially, in this new world, STUN & TURN take= the place of a signaling protocol, so providing the highest level of secur= ity for them can be useful. I would be very disinclined to rule out STUN ov= er DTLS right now.

 

It may not make opera= tional sense, but it makes total protocol design sense.

UDP, TCP, and TLS transports are defined for STUN, in RFC 5389. TURN is
just a set of new opcodes, and it inherits STUN's transports. So this
draft should apply exclusively to STUN. TURN could be mentioned in
passing, e.g. "by the way, TURN can make use of this new transport too= ."

 

I agree that we need to be very clear about this in = drafts, and not just talk about TURN because that is where we see the most = important use case.  The name of this proposed working group is a litt= le unfortunate in that sense, since we will really be doing STUN extensions most of the time.

 

(One caveat being TURN *channels*, about which this = draft should be very
explicit.)

Now, whether clients or servers use DTLS for Binding requests, that's a
completely orthogonal question. A few words could be said about that in
an "Operational Considerations" section.

Simon
--
DTN made easy, lean, and smart --> = http://postel= lation.viagenie.ca
NAT64/DNS64 open-source        -= -> http://ecdysis.viagenie.ca
STUN/TURN server           =     --> http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

--_000_913383AAA69FF945B8F946018B75898A242A74CBxmbrcdx10ciscoc_-- From petithug@acm.org Tue Feb 4 10:13:46 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D07C1A00EC for ; Tue, 4 Feb 2014 10:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=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 C8HbZjuMlk7Y for ; Tue, 4 Feb 2014 10:13:44 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id E37971A0035 for ; Tue, 4 Feb 2014 10:13:43 -0800 (PST) Received: from [IPv6:2001:5c0:1101:2d00:f1be:a53c:f936:ef3f] (unknown [IPv6:2001:5c0:1101:2d00:f1be:a53c:f936:ef3f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4E60320EF0; Tue, 4 Feb 2014 19:13:41 +0100 (CET) Message-ID: <52F12DD2.1060604@acm.org> Date: Tue, 04 Feb 2014 11:13:38 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Alan Johnston References: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Gonzalo Salgueiro \(gsalguei\)" , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 18:13:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Alan, We will releasing a new version before the end of this week that adds STUN over DTLS and all your and other participants suggestions. Thanks. On 01/31/2014 03:22 PM, Alan Johnston wrote: > Marc & Gonzalo, > > This draft looks good - no major issues. Here's a few comments for things > to consider. > > Section 1 explains why we don't want to use TURN over TLS. Might be good > to say why we want to use TURN over DTLS. Such as: confidentiality between > TURN client and server which can protect against the limitations of the > long term auth method, and privacy for TURN attributes. > > Also, this draft talks exclusively about TURN over DTLS. What about STUN > over DTLS? I was thinking about DTLS for STUN for gathering reflexive > candidates for setting up a data channel-only Peer Connection. Having DTLS > between the STUN client and server could provide confidentiality for STUN > attributes. Does this make sense? if not, are we sure there are no other > STUN use cases? > > In the last paragraph of Section 3 mentions the application name of "udp". > I think this correct as it refers to the SRV RR syntax, but I wanted to be > sure this was correct and not a typo. > > Section 7 could use some text describing the security benefits of TURN over > DTLS to help motivate why we all want this extension. > > - Alan - > > > On Fri, Jan 31, 2014 at 9:32 AM, Gonzalo Salgueiro (gsalguei) > > wrote: > > Folks - > > As mentioned during the authoring of the charter, we have published a > draft to satisfy the milestone for "DTLS transport for TURN". > > Feedback/comments much appreciated. If time permits we will try and > publish an -01 prior to the draft deadline. > > Thanks, > > Gonzalo > > > > > On Jan 31, 2014, at 10:00 AM, internet-drafts@ietf.org > wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >> >> >> Title : Datagram Transport Layer Security (DTLS) as > Transport for Traversal Using Relays around NAT (TURN) >> Authors : Marc Petit-Huguenin Gonzalo Salgueiro Filename : >> draft-petithuguenin-tram-turn-dtls-00.txt Pages : 9 Date >> : 2014-01-31 >> >> Abstract: This document specifies the usage of Datagram Transport Layer >> Security (DTLS) [RFC6347] as a transport protocol between a Traversal >> Using Relays around NAT (TURN) [RFC5766] client and a TURN server. It >> also specifies modifications to the TURN URIs [RFC7065] and to the TURN >> resolution mechanism [RFC5928] to facilitate the resolution of TURN URIs >> into the IP address and port of TURN servers supporting DTLS as a >> transport protocol. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-petithuguenin-tram-turn-dtls/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-petithuguenin-tram-turn-dtls-00 >> >> >> 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/ >> >> _______________________________________________ I-D-Announce mailing >> list I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft >> directories: http://www.ietf.org/shadow.html or >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > _______________________________________________ tram mailing list > tram@ietf.org https://www.ietf.org/mailman/listinfo/tram > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJS8S3QAAoJECnERZXWan7E77kQALVgYnDi2N6iw6Cyji0pEK40 Mk80+8sgOamfJIcI39tiFuc0f+5ytNZ9coc4WhQ/NExtOu9O9cuk2ttka5pz0asr axxfrCLg6o6VEoRSiF3L0lBGr4uPewiu6Q1bD2a2MEvvI4OVVQIhVcipYpa0Fei5 Ns+mXm+QVx6U+281oFVmi2zZgWjZX1zJIA2k6TmFAaPGnrtZFgMCzlWKm0lFauYq TglwwwkbUREnvXCG+M4OLqB3LSin2gdnpWsFEkBrMcQ7DEdtynwWvGxsofM4QnJ5 eYDHPsX5O1xSaie1xU0m5kaozO0G0FTqrZgaRmCR95LnnCalgVto+izfdr//efLB eC3NHPB19QuIeHxlJapy62bwPykNKxZ6WJDfa3/kugSxbQsNpmBS6sOrjY0gBYbC y2c2pmbWHR07xzKRbNymWxxMcqag0IburLECSRxqZYHlulG0mSb3e8yq2ALyMPnl PE37TiH0o7UYoverGgLVw/U02uklDOmXt18j8Dq68CNleH/rPotdhOSBzXTlxD2j 9ufIK+jGTaGQNALCMDKmWVkAuqT0OnO06YsQT8ZmZCnob/cn7G0dWuy+46ra76/f 1WCTj+ibKH1Wn+AezJ2N8XJIGDRmBBUfXDzmNYAdWcVDsdwXyVcqRRRtrJE73KAo sdqSpG3rBFZLg+rLtUnk =caou -----END PGP SIGNATURE----- From alan.b.johnston@gmail.com Tue Feb 4 10:25:45 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF921A01BA for ; Tue, 4 Feb 2014 10:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 BiwuKlswyMVC for ; Tue, 4 Feb 2014 10:25:41 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 088FA1A01C5 for ; Tue, 4 Feb 2014 10:25:41 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id p10so8489437pdj.17 for ; Tue, 04 Feb 2014 10:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JCxlfWjfEv6LVL1/7fGSKScVmNC2Cel1Xvyk34WYb3E=; b=MTMsqcp6PDLNCSPk6oNFUnQtjQC6tIju3H6CdrRJEerwkCyFb1bRTsPt/WDjIbMgeQ xVbRPcrEC9X4VlV604sHAg8fXXQ559vhZjN+e3Rcx8W/upDFICs8dX/GjRrJTMgpiq8c qe1VZ5mlITXw3PrjHCQQOyVRxJr8y3NTeVeqDu2aw9oLZgz/LJfM30mnFQRFdsjMzt8l 67ea8cr88wLrD6Fm/kqMwrSPX572qgXAN5qjij7ogYUeYPwvPrtwPw1Pfr5pa/iHr3/D StC1JI5+5lbwdgIozDwfhq9GEgf2xrxPME+608pC/MBfx9O4xBM7OH3k05cI5acOa2gC muhQ== MIME-Version: 1.0 X-Received: by 10.66.141.231 with SMTP id rr7mr44516894pab.41.1391538340328; Tue, 04 Feb 2014 10:25:40 -0800 (PST) Received: by 10.68.168.132 with HTTP; Tue, 4 Feb 2014 10:25:40 -0800 (PST) In-Reply-To: <52F12DD2.1060604@acm.org> References: <20140131150054.2907.33844.idtracker@ietfa.amsl.com> <3610CA6C-3EAB-4418-AA3C-53BB0F80ABD6@cisco.com> <52F12DD2.1060604@acm.org> Date: Tue, 4 Feb 2014 12:25:40 -0600 Message-ID: From: Alan Johnston To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=001a11331298777b6a04f198c40d Cc: "Gonzalo Salgueiro \(gsalguei\)" , "tram@ietf.org" Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-turn-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 18:25:45 -0000 --001a11331298777b6a04f198c40d Content-Type: text/plain; charset=ISO-8859-1 Great! Looking forward to it. We are getting ready to revise the STUN Origin draft as well, so if anyone has any additional comments, now would be a good time to send them to the list. - Alan - On Tue, Feb 4, 2014 at 12:13 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Alan, > > We will releasing a new version before the end of this week that adds STUN > over DTLS and all your and other participants suggestions. > > Thanks. > > On 01/31/2014 03:22 PM, Alan Johnston wrote: > > Marc & Gonzalo, > > > > This draft looks good - no major issues. Here's a few comments for > things > > to consider. > > > > Section 1 explains why we don't want to use TURN over TLS. Might be good > > to say why we want to use TURN over DTLS. Such as: confidentiality > between > > TURN client and server which can protect against the limitations of the > > long term auth method, and privacy for TURN attributes. > > > > Also, this draft talks exclusively about TURN over DTLS. What about STUN > > over DTLS? I was thinking about DTLS for STUN for gathering reflexive > > candidates for setting up a data channel-only Peer Connection. Having > DTLS > > between the STUN client and server could provide confidentiality for > STUN > > attributes. Does this make sense? if not, are we sure there are no > other > > STUN use cases? > > > > In the last paragraph of Section 3 mentions the application name of > "udp". > > I think this correct as it refers to the SRV RR syntax, but I wanted to > be > > sure this was correct and not a typo. > > > > Section 7 could use some text describing the security benefits of TURN > over > > DTLS to help motivate why we all want this extension. > > > > - Alan - > > > > > > On Fri, Jan 31, 2014 at 9:32 AM, Gonzalo Salgueiro (gsalguei) > > > wrote: > > > > Folks - > > > > As mentioned during the authoring of the charter, we have published a > > draft to satisfy the milestone for "DTLS transport for TURN". > > > > Feedback/comments much appreciated. If time permits we will try and > > publish an -01 prior to the draft deadline. > > > > Thanks, > > > > Gonzalo > > > > > > > > > > On Jan 31, 2014, at 10:00 AM, internet-drafts@ietf.org > > wrote: > > > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > >> > >> > >> Title : Datagram Transport Layer Security (DTLS) as > > Transport for Traversal Using Relays around NAT (TURN) > >> Authors : Marc Petit-Huguenin Gonzalo Salgueiro Filename > : > >> draft-petithuguenin-tram-turn-dtls-00.txt Pages : 9 Date > >> : 2014-01-31 > >> > >> Abstract: This document specifies the usage of Datagram Transport Layer > >> Security (DTLS) [RFC6347] as a transport protocol between a Traversal > >> Using Relays around NAT (TURN) [RFC5766] client and a TURN server. It > >> also specifies modifications to the TURN URIs [RFC7065] and to the TURN > >> resolution mechanism [RFC5928] to facilitate the resolution of TURN URIs > >> into the IP address and port of TURN servers supporting DTLS as a > >> transport protocol. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-petithuguenin-tram-turn-dtls/ > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-petithuguenin-tram-turn-dtls-00 > >> > >> > >> 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/ > >> > >> _______________________________________________ I-D-Announce mailing > >> list I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft > >> directories: http://www.ietf.org/shadow.html or > >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > > _______________________________________________ tram mailing list > > tram@ietf.org https://www.ietf.org/mailman/listinfo/tram > > > > > - -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAEBCAAGBQJS8S3QAAoJECnERZXWan7E77kQALVgYnDi2N6iw6Cyji0pEK40 > Mk80+8sgOamfJIcI39tiFuc0f+5ytNZ9coc4WhQ/NExtOu9O9cuk2ttka5pz0asr > axxfrCLg6o6VEoRSiF3L0lBGr4uPewiu6Q1bD2a2MEvvI4OVVQIhVcipYpa0Fei5 > Ns+mXm+QVx6U+281oFVmi2zZgWjZX1zJIA2k6TmFAaPGnrtZFgMCzlWKm0lFauYq > TglwwwkbUREnvXCG+M4OLqB3LSin2gdnpWsFEkBrMcQ7DEdtynwWvGxsofM4QnJ5 > eYDHPsX5O1xSaie1xU0m5kaozO0G0FTqrZgaRmCR95LnnCalgVto+izfdr//efLB > eC3NHPB19QuIeHxlJapy62bwPykNKxZ6WJDfa3/kugSxbQsNpmBS6sOrjY0gBYbC > y2c2pmbWHR07xzKRbNymWxxMcqag0IburLECSRxqZYHlulG0mSb3e8yq2ALyMPnl > PE37TiH0o7UYoverGgLVw/U02uklDOmXt18j8Dq68CNleH/rPotdhOSBzXTlxD2j > 9ufIK+jGTaGQNALCMDKmWVkAuqT0OnO06YsQT8ZmZCnob/cn7G0dWuy+46ra76/f > 1WCTj+ibKH1Wn+AezJ2N8XJIGDRmBBUfXDzmNYAdWcVDsdwXyVcqRRRtrJE73KAo > sdqSpG3rBFZLg+rLtUnk > =caou > -----END PGP SIGNATURE----- > --001a11331298777b6a04f198c40d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Great! =A0Looking forward to it. =A0

We= are getting ready to revise the STUN Origin draft as well, so if anyone ha= s any additional comments, now would be a good time to send them to the lis= t.

- Alan -

On Tue, Feb 4, 2014 at 12:13 PM, Marc Petit-Hug= uenin <petithug@acm.org> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Alan,

We will releasing a new version before the end of this week that adds STUN<= br> over DTLS and all your and other participants suggestions.

Thanks.

On 01/31/2014 03:22 PM, Alan Johnston wrote:
> Marc & Gonzalo,
>
> This draft looks good - no major issues. =A0Here's a few comments = for things
> to consider.
>
> Section 1 explains why we don't want to use TURN over TLS. =A0Migh= t be good
> to say why we want to use TURN over DTLS. =A0Such as: confidentiality = between
> TURN client and server which can protect against the limitations of th= e
> long term auth method, and privacy for TURN attributes.
>
> Also, this draft talks exclusively about TURN over DTLS. =A0What about= STUN
> over DTLS? =A0I was thinking about DTLS for STUN for gathering reflexi= ve
> candidates for setting up a data channel-only Peer Connection. =A0Havi= ng DTLS
> between the STUN client and server could =A0provide confidentiality fo= r STUN
> attributes. =A0Does this make sense? =A0if not, are we sure there are = no other
> STUN use cases?
>
> In the last paragraph of Section 3 mentions the application name of &q= uot;udp".
> I think this correct as it refers to the SRV RR syntax, but I wanted t= o be
> sure this was correct and not a typo.
>
> Section 7 could use some text describing the security benefits of TURN= over
> DTLS to help motivate why we all want this extension.
>
> - Alan -
>
>
> On Fri, Jan 31, 2014 at 9:32 AM, Gonzalo Salgueiro (gsalguei)
> <gsalguei@cisco.com <m= ailto:gsalguei@cisco.com>> = wrote:
>
> Folks -
>
> As mentioned during the authoring of the charter, we have published a<= br> > draft to satisfy the milestone for "DTLS transport for TURN"= .
>
> Feedback/comments much appreciated. =A0If time permits we will try and=
> publish an -01 prior to the draft deadline.
>
> Thanks,
>
> Gonzalo
>
>
>
>
> On Jan 31, 2014, at 10:00 AM, internet-drafts@ietf.org
> <mailto:internet-drafts= @ietf.org> wrote:
>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts=
> directories.
>>
>>
>> Title =A0 =A0 =A0 =A0 =A0 : Datagram Transport Layer Security (DTL= S) as
> Transport for Traversal Using Relays around NAT (TURN)
>> Authors =A0 =A0 =A0 =A0 : Marc Petit-Huguenin Gonzalo Salgueiro Fi= lename =A0 =A0 =A0 =A0:
>> draft-petithuguenin-tram-turn-dtls-00.txt Pages =A0 =A0 =A0 =A0 = =A0 : 9 Date
>> : 2014-01-31
>>
>> Abstract: This document specifies the usage of Datagram Transport = Layer
>> Security (DTLS) [RFC6347] as a transport protocol between a Traver= sal
>> Using Relays around NAT (TURN) [RFC5766] client and a TURN server.= It
>> also specifies modifications to the TURN URIs [RFC7065] and to the= TURN
>> resolution mechanism [RFC5928] to facilitate the resolution of TUR= N URIs
>> into the IP address and port of TURN servers supporting DTLS as a<= br> >> transport protocol.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-pet= ithuguenin-tram-turn-dtls/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-petithuguenin= -tram-turn-dtls-00
>>
>>
>> Please note that it may take a couple of minutes from the time of<= br> >> submission until the htmlized version and diff are available at >> tools.ietf.org=
> <http://tools.i= etf.org>.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> = ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________ I-D-Announce maili= ng
>> list I-D-Announce@ietf.or= g <mailto:I-D-Announce@ietf= .org>
>> https://www.ietf.org/mailman/listinfo/i-d-announce Inter= net-Draft
>> directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________ tram mailing list
> tram@ietf.org <mailto:tram@ietf.org>
> https://www.ietf.org/mailman/listinfo/tram
>
>
>
>
> _______________________________________________ tram mailing list
> tram@ietf.org https://www.ietf.org/= mailman/listinfo/tram
>


- --
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: htt= p://blog.marc.petit-huguenin.org
Profile: = http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJS8S3QAAoJECnERZXWan7E77kQALVgYnDi2N6iw6Cyji0pEK40
Mk80+8sgOamfJIcI39tiFuc0f+5ytNZ9coc4WhQ/NExtOu9O9cuk2ttka5pz0asr
axxfrCLg6o6VEoRSiF3L0lBGr4uPewiu6Q1bD2a2MEvvI4OVVQIhVcipYpa0Fei5
Ns+mXm+QVx6U+281oFVmi2zZgWjZX1zJIA2k6TmFAaPGnrtZFgMCzlWKm0lFauYq
TglwwwkbUREnvXCG+M4OLqB3LSin2gdnpWsFEkBrMcQ7DEdtynwWvGxsofM4QnJ5
eYDHPsX5O1xSaie1xU0m5kaozO0G0FTqrZgaRmCR95LnnCalgVto+izfdr//efLB
eC3NHPB19QuIeHxlJapy62bwPykNKxZ6WJDfa3/kugSxbQsNpmBS6sOrjY0gBYbC
y2c2pmbWHR07xzKRbNymWxxMcqag0IburLECSRxqZYHlulG0mSb3e8yq2ALyMPnl
PE37TiH0o7UYoverGgLVw/U02uklDOmXt18j8Dq68CNleH/rPotdhOSBzXTlxD2j
9ufIK+jGTaGQNALCMDKmWVkAuqT0OnO06YsQT8ZmZCnob/cn7G0dWuy+46ra76/f
1WCTj+ibKH1Wn+AezJ2N8XJIGDRmBBUfXDzmNYAdWcVDsdwXyVcqRRRtrJE73KAo
sdqSpG3rBFZLg+rLtUnk
=3Dcaou
-----END PGP SIGNATURE-----

--001a11331298777b6a04f198c40d-- From tireddy@cisco.com Wed Feb 5 06:17:27 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881EE1A015B; Wed, 5 Feb 2014 06:17:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.036 X-Spam-Level: X-Spam-Status: No, score=-15.036 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 lgyZSYfDFy4S; Wed, 5 Feb 2014 06:17:25 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A386C1A0147; Wed, 5 Feb 2014 06:17:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2472; q=dns/txt; s=iport; t=1391609845; x=1392819445; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qKvb/D/yZz6WZRt1fkrmfPUq6YS5Ycs6oMr/TW5UQ9s=; b=ilNBFdEDaN6Dl1fUn5Axj5r62LLbZWb3146P8/LyssGQZbkjxK8b4DMw TowkRrNqn6iqaFj4dqClIUo/efjkzep8B3RNqEM6IciJ32PmjolZUN3kF 6sqQzHr5WSlghwf9wg5/Q8gRK/bR/20Hjk0pfgLotgPn1F9KbI/LTpJbK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFACFH8lKtJV2Z/2dsb2JhbABZgww4UQaDAbtCGHYWdIIlAQEBBCMRQw4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBAESCAGHfAgFrgqhNBeBKY0bOAaCaTWBFASZXZBvgy2CKg X-IronPort-AV: E=Sophos;i="4.95,786,1384300800"; d="scan'208";a="302106590" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 05 Feb 2014 14:17:24 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s15EHOw4017957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 14:17:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.36]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 08:17:24 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "mmusic@ietf.org" , "tram@ietf.org" Thread-Topic: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt Thread-Index: AQHPInx7P3A1nrdpgEm2Fo8Aj02afpqmtGsQ Date: Wed, 5 Feb 2014 14:17:23 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242A8397@xmb-rcd-x10.cisco.com> References: <20140205141338.9649.12791.idtracker@ietfa.amsl.com> In-Reply-To: <20140205141338.9649.12791.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.61.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [tram] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 14:17:27 -0000 UmV2aXNlZCBkcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDYgaGFzIGJlZW4gcHVibGlz aGVkLiBJdCBhZGRyZXNzZXMgdGhlIGNvbW1lbnRzIHJlY2VpdmVkIGZvciBNb2JpbGl0eSB1c2lu ZyBUVVJOIGFuZCBhIG5ldyBzZWN0aW9uIHdpdGggaW1wbGVtZW50YXRpb24gZGV0YWlscy4gRnVy dGhlciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUuDQoNClRoYW5rcyBhbmQg UmVnYXJkcywNCi1BdXRob3JzLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XSANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMDUsIDIwMTQgNzo0NCBQTQ0KVG86IFByYXNo YW50aCBQYXRpbCAocHJhc3BhdGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBQcmFz aGFudGggUGF0aWwgKHByYXNwYXRpKTsgRGFuIFdpbmcgKGR3aW5nKTsgVGlydW1hbGVzd2FyIFJl ZGR5ICh0aXJlZGR5KTsgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpOyBEYW4gV2luZyAoZHdpbmcp OyBQYWwgTWFydGluc2VuIChwYWxtYXJ0aSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5LTA2LnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDYudHh0DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRpcnVtYWxlc3dhciBSZWRkeSBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC13aW5nLW1tdXNp Yy1pY2UtbW9iaWxpdHkNClJldmlzaW9uOgkwNg0KVGl0bGU6CQlNb2JpbGl0eSB3aXRoIElDRSAo TUlDRSkNCkRvY3VtZW50IGRhdGU6CTIwMTQtMDItMDUNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczoJCTIxDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtd2luZy1tbXVzaWMtaWNlLW1vYmlsaXR5LTA2LnR4dA0KU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdpbmct bW11c2ljLWljZS1tb2JpbGl0eS8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC13aW5nLW1tdXNpYy1pY2UtbW9iaWxpdHktMDYNCkRpZmY6ICAgICAgICAg ICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC13aW5nLW1tdXNpYy1pY2Ut bW9iaWxpdHktMDYNCg0KQWJzdHJhY3Q6DQogICBUaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVz IGhvdyBlbmRwb2ludCBtb2JpbGl0eSBjYW4gYmUgYWNoaWV2ZWQNCiAgIHVzaW5nIElDRS4gIFR3 byBtZWNoYW5pc21zIGFyZSBzaG93biwgb25lIHdoZXJlIGJvdGggZW5kcG9pbnRzDQogICBzdXBw b3J0IE1JQ0UgYW5kIGFub3RoZXIgd2hlcmUgb25seSBvbmUgZW5kcG9pbnQgc3VwcG9ydHMgTUlD RS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From mom040267@gmail.com Thu Feb 6 09:13:24 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB4E1A01A8; Thu, 6 Feb 2014 09:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 5WSnxOtWrs52; Thu, 6 Feb 2014 09:13:22 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 16B531A01FD; Thu, 6 Feb 2014 09:13:22 -0800 (PST) Received: by mail-pa0-f41.google.com with SMTP id fa1so1949635pad.28 for ; Thu, 06 Feb 2014 09:13:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e2zBpe2dEaRPGHVYtmqLP67SVo1z7kx51irVUvJXKi4=; b=tkdlnsATRW2J7CZWMMSGlF4JhCqEV9dboE5XjCe1COSQaRUDAKEAGWX9+416sp6in9 pOHgmJwvo1qpFj4uPGW6FVm38mDglE+2ALIv7wQ2Z5qepaeKloCIL937SgOYbj2ADwdn ffTG0ODGVmGzbrMx+KSKDJ1//R5U/cIhY2NGsDx0OpZzY9CBKWyUu82YbnaOLAJCocWe c+ZancRl14aceAw/UmHeoS60Yqzp9fcSTdXgI+Nr/RXDvyHvkZSsC343mqNlNheOarm2 ad1PEIe/NLpulImAgMjQaL4mr7yJtQDUjOmjtHDB+ZRnNkDGHP4SGG3eBrCuXlHUVGbc tE7g== MIME-Version: 1.0 X-Received: by 10.67.14.231 with SMTP id fj7mr1821095pad.115.1391706800717; Thu, 06 Feb 2014 09:13:20 -0800 (PST) Received: by 10.68.147.131 with HTTP; Thu, 6 Feb 2014 09:13:20 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A242A8397@xmb-rcd-x10.cisco.com> References: <20140205141338.9649.12791.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A242A8397@xmb-rcd-x10.cisco.com> Date: Thu, 6 Feb 2014 09:13:20 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a113453ec7d03ca04f1bffd76 Cc: "mmusic@ietf.org" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 17:13:24 -0000 --001a113453ec7d03ca04f1bffd76 Content-Type: text/plain; charset=ISO-8859-1 I have comments regarding the new Error Code "Mobility Forbidden". 1) Section 5.1.4: Comment: remove two TBDs, if the error code has been already determined. 2) Section 7: and to add a new STUN error code "Mobility Forbidden" with the value 501 to the STUN Error Codes registry [iana-stun]. Comment: I am not sure that 501 is the right code to be used. In SIP and HTTP, 5xx errors are usually about a server code problem of some sort; 501 means "not implemented". That may be not exactly accurate. A mobility-aware TURN server may reject the request simply because the administrator does not allow it., and the server did not encounter an error. The reason why the server reject the request is rather "not allowed" (which is the error code 405). May be be, the right approach would be to introduce two separate error codes here: 405 "not allowed" (the server implements mobility but the administrator forbade it) or 501 "not implemented" (the server knows about mobility but it has no implementation for that). If the server truly is not aware about mobility at all, the server will send no MOBILITY-TICKET in the server response. Those are three distinct use cases: 405, 501 and an "ignorant" server. Thanks Oleg On Wed, Feb 5, 2014 at 6:17 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Revised draft-wing-mmusic-ice-mobility-06 has been published. It addresses > the comments received for Mobility using TURN and a new section with > implementation details. Further comments and suggestions are welcome. > > Thanks and Regards, > -Authors. > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, February 05, 2014 7:44 PM > To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth > Patil (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal > Martinsen (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti) > Subject: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt > > > A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF repository. > > Name: draft-wing-mmusic-ice-mobility > Revision: 06 > Title: Mobility with ICE (MICE) > Document date: 2014-02-05 > Group: Individual Submission > Pages: 21 > URL: > http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-06.txt > Status: > https://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility/ > Htmlized: > http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-06 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-wing-mmusic-ice-mobility-06 > > Abstract: > This specification describes how endpoint mobility can be achieved > using ICE. Two mechanisms are shown, one where both endpoints > support MICE and another where only one endpoint supports MICE. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a113453ec7d03ca04f1bffd76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have comments regarding the new Erro= r Code "Mobility Forbidden".

1) Section 5.1.4:
<= br>Comment: remove two TBDs, if the error code has been already determined.=

2) Section 7:

and to add a new STUN error code "=
Mobility Forbidden" with the value
501 to the STUN Error Codes registry [iana-stun].

Comment: I= am not sure that 501 is the right code to be used. In SIP and HTTP, 5xx er= rors are usually about a server code problem of some sort; 501 means "= not implemented". That may be not exactly accurate. A mobility-aware T= URN server may reject the request simply because the administrator does not= allow it., and the server did not encounter an error. The reason why the s= erver reject the request is rather "not allowed" (which is the er= ror code 405).

May be be, the right approach would be to introduce two separate = error codes here: 405 "not allowed" (the server implements mobili= ty but the administrator forbade it) or 501 "not implemented" (th= e server knows about mobility but it has no implementation for that). If th= e server truly is not aware about mobility at all, the server will send no = MOBILITY-TICKET in the server response. Those are three distinct use cases:= 405, 501 and an "ignorant" server.

Thanks
Oleg



On Wed, Feb 5, 2014 at 6:17 AM, Ti= rumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
Revised draft-wing-mmusic-ice-mobility-06 ha= s been published. It addresses the comments received for Mobility using TUR= N and a new section with implementation details. Further comments and sugge= stions are welcome.

Thanks and Regards,
-Authors.

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Wednesday, February 05, 2014 7:44 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth Pat= il (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal Martinse= n (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti)
Subject: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt=


A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-wing-mmusic-ice-mobility
Revision: =A0 =A0 =A0 06
Title: =A0 =A0 =A0 =A0 =A0Mobility with ICE (MICE)
Document date: =A02014-02-05
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A021
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.or= g/internet-drafts/draft-wing-mmusic-ice-mobility-06.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/do= c/draft-wing-mmusic-ice-mobility/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-wing= -mmusic-ice-mobility-06
Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdi= ff?url2=3Ddraft-wing-mmusic-ice-mobility-06

Abstract:
=A0 =A0This specification describes how endpoint mobility can be achieved =A0 =A0using ICE. =A0Two mechanisms are shown, one where both endpoints
=A0 =A0support MICE and another where only one endpoint supports MICE.




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

The IETF Secretariat

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--001a113453ec7d03ca04f1bffd76-- From mom040267@gmail.com Thu Feb 6 14:05:47 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773181A03C4; Thu, 6 Feb 2014 14:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 gNG9LrOGWw3h; Thu, 6 Feb 2014 14:05:45 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A266D1A0101; Thu, 6 Feb 2014 14:05:45 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so2269049pde.34 for ; Thu, 06 Feb 2014 14:05:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZzO2hJGLfS9xAXl/YczAxVYLpZxy7iTMLvRQ33sq6l8=; b=p0KneycM465hZH1mPrx1WxUxthOjulNIfyWKjLeWx6uwX/0uAiqxkm3Ml0UD69MN31 6gzHLpxNBe8qRkNbYkOJNt6DXqOkrTKzGfc8PogJM0xelztkaH+g/MRY4ZFNG/sCT87N 3J6KsGEgfZ/UQj00QTx3WPfFTbymBmcuSVk5aMb7ZzR3ZSkvFtb2MT00cMwpG2s6yI81 NO9WcOlaA7ZOZB2KA18u74lrQOS5k57d1+nJiTxnf5bS8octNfAwqFjEGh42olCSXd91 c3owJMLe2KJED2dWQP4l8pdoadnI/naKGl4BlZ3Yi03wI99vnZuh6QUjDoeax7cipefp 0EbQ== MIME-Version: 1.0 X-Received: by 10.67.14.231 with SMTP id fj7mr3241176pad.115.1391724344586; Thu, 06 Feb 2014 14:05:44 -0800 (PST) Received: by 10.68.147.131 with HTTP; Thu, 6 Feb 2014 14:05:44 -0800 (PST) In-Reply-To: References: <20140205141338.9649.12791.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A242A8397@xmb-rcd-x10.cisco.com> Date: Thu, 6 Feb 2014 14:05:44 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a113453ec2f366704f1c413e5 Cc: "mmusic@ietf.org" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 22:05:47 -0000 --001a113453ec2f366704f1c413e5 Content-Type: text/plain; charset=ISO-8859-1 ... and another reason why we may want two different error codes for "not allowed" or "not implemented" use cases is that we now have an "origin" TURN draft, and the TURN server may reject or allow Mobility using the "origin" field (according to a server policy). Then probably "not implemented" error would be an incorrect error code if the "mobile allocate" request was rejected because of the origin attribute. But at the same time I am not sure that the "origin" field was really designed as an input for "hard" security decisions (like allowing or disallowing a piece of functionality). This is a grey area between different drafts, and may be the authors or both "origin" draft and "mobility" draft would like to clarify that, for future implementations. Thanks Oleg On Thu, Feb 6, 2014 at 9:13 AM, Oleg Moskalenko wrote: > I have comments regarding the new Error Code "Mobility Forbidden". > > 1) Section 5.1.4: > > Comment: remove two TBDs, if the error code has been already determined. > > 2) Section 7: > > and to add a new STUN error code "Mobility Forbidden" with the value > 501 to the STUN Error Codes registry [iana-stun]. > > > Comment: I am not sure that 501 is the right code to be used. In SIP and > HTTP, 5xx errors are usually about a server code problem of some sort; 501 > means "not implemented". That may be not exactly accurate. A mobility-aware > TURN server may reject the request simply because the administrator does > not allow it., and the server did not encounter an error. The reason why > the server reject the request is rather "not allowed" (which is the error > code 405). > > May be be, the right approach would be to introduce two separate error > codes here: 405 "not allowed" (the server implements mobility but the > administrator forbade it) or 501 "not implemented" (the server knows about > mobility but it has no implementation for that). If the server truly is not > aware about mobility at all, the server will send no MOBILITY-TICKET in the > server response. Those are three distinct use cases: 405, 501 and an > "ignorant" server. > > Thanks > Oleg > > > > On Wed, Feb 5, 2014 at 6:17 AM, Tirumaleswar Reddy (tireddy) < > tireddy@cisco.com> wrote: > >> Revised draft-wing-mmusic-ice-mobility-06 has been published. It >> addresses the comments received for Mobility using TURN and a new section >> with implementation details. Further comments and suggestions are welcome. >> >> Thanks and Regards, >> -Authors. >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, February 05, 2014 7:44 PM >> To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth >> Patil (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal >> Martinsen (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti) >> Subject: New Version Notification for >> draft-wing-mmusic-ice-mobility-06.txt >> >> >> A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt >> has been successfully submitted by Tirumaleswar Reddy and posted to the >> IETF repository. >> >> Name: draft-wing-mmusic-ice-mobility >> Revision: 06 >> Title: Mobility with ICE (MICE) >> Document date: 2014-02-05 >> Group: Individual Submission >> Pages: 21 >> URL: >> http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-06.txt >> Status: >> https://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility/ >> Htmlized: >> http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-06 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-wing-mmusic-ice-mobility-06 >> >> Abstract: >> This specification describes how endpoint mobility can be achieved >> using ICE. Two mechanisms are shown, one where both endpoints >> support MICE and another where only one endpoint supports MICE. >> >> >> >> >> 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. >> >> The IETF Secretariat >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > > --001a113453ec2f366704f1c413e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
... and another reason why we may want two different = error codes for "not allowed" or "not implemented" use = cases is that we now have an "origin" TURN draft, and the TURN se= rver may reject or allow Mobility using the "origin" field (accor= ding to a server policy). Then probably "not implemented" error w= ould be an incorrect error code if the "mobile allocate" request = was rejected because of the origin attribute.

But at the same time I am not sure that the "origin&quo= t; field was really designed as an input for "hard" security deci= sions (like allowing or disallowing a piece of functionality). This is a gr= ey area between different drafts, and may be the authors or both "orig= in" draft and "mobility" draft would like to clarify that, f= or future implementations.

Thanks
Oleg



On Thu, Feb 6, 20= 14 at 9:13 AM, Oleg Moskalenko <mom040267@gmail.com> wrote= :
I have = comments regarding the new Error Code "Mobility Forbidden".
1) Section 5.1.4:

Comment: remove two TBDs, if the error code= has been already determined.

2) Section 7:

and to add a new STUN error code "=
Mobility Forbidden" with the value
501 to the STUN Error Codes registry [iana-stun].

Comment: I= am not sure that 501 is the right code to be used. In SIP and HTTP, 5xx er= rors are usually about a server code problem of some sort; 501 means "= not implemented". That may be not exactly accurate. A mobility-aware T= URN server may reject the request simply because the administrator does not= allow it., and the server did not encounter an error. The reason why the s= erver reject the request is rather "not allowed" (which is the er= ror code 405).

May be be, the right approach would be to introduce two separate = error codes here: 405 "not allowed" (the server implements mobili= ty but the administrator forbade it) or 501 "not implemented" (th= e server knows about mobility but it has no implementation for that). If th= e server truly is not aware about mobility at all, the server will send no = MOBILITY-TICKET in the server response. Those are three distinct use cases:= 405, 501 and an "ignorant" server.

Thanks
Oleg=



=
On Wed, Feb 5, 2014 at 6:17 AM= , Tirumaleswar Reddy (tireddy) <tireddy@cisco.com> wrote:
Revised draft-w= ing-mmusic-ice-mobility-06 has been published. It addresses the comments re= ceived for Mobility using TURN and a new section with implementation detail= s. Further comments and suggestions are welcome.

Thanks and Regards,
-Authors.

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Wednesday, February 05, 2014 7:44 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth Pat= il (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal Martinse= n (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti)
Subject: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt=


A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-wing-mmusic-ice-mobility
Revision: =A0 =A0 =A0 06
Title: =A0 =A0 =A0 =A0 =A0Mobility with ICE (MICE)
Document date: =A02014-02-05
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A021
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.or= g/internet-drafts/draft-wing-mmusic-ice-mobility-06.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/do= c/draft-wing-mmusic-ice-mobility/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-wing= -mmusic-ice-mobility-06
Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcdi= ff?url2=3Ddraft-wing-mmusic-ice-mobility-06

Abstract:
=A0 =A0This specification describes how endpoint mobility can be achieved =A0 =A0using ICE. =A0Two mechanisms are shown, one where both endpoints
=A0 =A0support MICE and another where only one endpoint supports MICE.




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

The IETF Secretariat

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--001a113453ec2f366704f1c413e5-- From spencerdawkins.ietf@gmail.com Thu Feb 6 14:24:01 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1E31A03C4 for ; Thu, 6 Feb 2014 14:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_uLiZwyMb5G for ; Thu, 6 Feb 2014 14:24:00 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id D35121A01CA for ; Thu, 6 Feb 2014 14:23:59 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so3047712obc.11 for ; Thu, 06 Feb 2014 14:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=JQ83dmO8mOZNK0d7Dcfhlz0PvJGZlMN2xVFTZzkQTfw=; b=sGCUcBegUTtY3LUmbT5j5ICQSiLQcvAGmH5GnbDEUo4V5Nk0RFq0ZOLUVTTyoldNZg frHHAQrEbw3v7Sf7Od/sMscCsnUpZ0DPlv0T41xJxCzzqO2iwbBJZPprntnk0JPS6Xz6 PX2NggQcNd5YmIiK542q1LkftUKJ0SUUcAYPIfaI8Ndpo5y33nmuh2KlvYwhDva2jl06 byQjApyik90NuWKhf3rwqYysiEO7nLsh3/PTM2i06fl/CiCFqFEzXB3+t5wTijS+eZ5o 4I8SsvMB+C1s2Fjdde2NRaKSI7qfPOJ9CmjHYom8gSlPDMT7TqmOT1bTFT0t7LEGnXMe jpbQ== X-Received: by 10.182.22.18 with SMTP id z18mr9340554obe.42.1391725438557; Thu, 06 Feb 2014 14:23:58 -0800 (PST) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id o6sm13915028oel.4.2014.02.06.14.23.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Feb 2014 14:23:57 -0800 (PST) Message-ID: <52F40B7B.4000809@gmail.com> Date: Thu, 06 Feb 2014 16:23:55 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tram@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling Subject: [tram] TRAM approved for IETF and external review/next steps X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 22:24:01 -0000 Dear TRAMsters, I wanted to share this with you, from the *draft* telechat narrative minutes today: 4 Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review . TURN Revised and Modernized (tram) Token: Spencer Dawkins Telechat:: Amy: Version -06 has no blocking comments, Hearing no objections, this is approved. Amy: We will send an announcement to new-work, and put this on the agenda. So, here's what this means: The IESG and IAB have looked over the proposed charter (current text is at https://datatracker.ietf.org/doc/charter-ietf-tram/), and they think it's plausible enough to ask the rest of the IETF for comments. We were able to work through concerns from Barry , (that you've seen) and from Sean (tightening up the language around DTLS). You can review the change history at https://datatracker.ietf.org/doc/charter-ietf-tram/history/. The proposed charter will also be shared with other SDOs that participate in the new-work mailing list, to collect their thoughts and identify any potential conflicts or gaps. If we get positive feedback, we'll put TRAM on an upcoming formal telechat agenda, for approval to create a working group. That could happen before London, but TRAM will meet in London, whether as a WG or as a BOF. What would be helpful to me, at this point, is for you folks to converge on the first two or three problem areas an approved working group should have as milestones. You can do that on the list, or you can spend the first meeting slot figuring that out. I'd prefer if you can figure that out on the list. So, if you could start a thread for each problem area you'd like to see as a priority, that would be AWESOME ... Thanks, and thanks for the work you've already done to get this far. Spencer From petithug@acm.org Thu Feb 6 16:34:25 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2A41A057B for ; Thu, 6 Feb 2014 16:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=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 hHelbKvr8bKp for ; Thu, 6 Feb 2014 16:34:23 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 62B0C1A0577 for ; Thu, 6 Feb 2014 16:34:23 -0800 (PST) Received: from [IPv6:2001:5c0:1101:2d00:5d0b:ff32:2dd6:e8c] (unknown [IPv6:2001:5c0:1101:2d00:5d0b:ff32:2dd6:e8c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id A1C7E2025C for ; Fri, 7 Feb 2014 01:34:19 +0100 (CET) Message-ID: <52F42A09.5060809@acm.org> Date: Thu, 06 Feb 2014 17:34:17 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: "tram@ietf.org" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [tram] STUN over DTLS X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 00:34:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 After discussion, we decided to more or less restart the draft from a STUN point of view. Please find below some thoughts about what we plan to do, so we can gather comments until the new version of the draft is published (probably tomorrow afternoon). First of all, I realized that what I need for my RELOAD draft was STUN over DTLS, not TURN over DTLS (the plan for the RELOAD draft is to have a STUN usage to find a unicast address from an anycast address, although now that I read RFC 7094, I am not so sure that using DTLS is the right choice - but that's orthogonal to TRAM's work). So we will rename the draft-petithuguenin-tram-stun-dtls, with probably the following sections: 2. DTLS as Transport for STUN 3. STUN Usages 3.1 NAT Discovery Usage 3.1.1 DTLS Support in STUN URIs 3.2 Connectivity Check Usage 3.3 Media Keep-Alive Usage 3.4 SIP Keep-Alive Usage 3.5 NAT Behavior Discovery Usage 3.6 TURN Usage 3.6.1 DTLS Support in TURN URIs 3.6.2 Resolution Mechanism for TURN over DTLS The idea is to go through each standardized STUN Usages and to provide some guidance when using DTLS. You'll find below some notes on each of them. - - NAT Discovery (RFC 5389) The only information that could be hidden is the XOR-MAPPED-ADDRESS in the response, but a listener on the path of the request already knows this value (this is the source IP/port of the request), so there is not much to hide here. Also RFC 5389 explicitly discourages authentication for this usage because of the cost and DTLS is probably more costly than a long-term authentication (although without having to maintain a password database). The only reason would be to be sure that this is the correct STUN server, in case someone tries to inject STUN responses with an incorrect XOR-MAPPED-ADDRESS. On the other hand TURN also offers NAT Discovery as part of an Allocation, which requires authentication, and for the cases that interest us (WebRTC), having a TURN allocation is pretty much mandatory, so I would say that the case for DTLS for pure NAT discovery is pretty weak. This is also one of the Usage that will use a STUN URI, so we may want to say something about it, similar to what is said about TURN URI. - - Connectivity check (ICE, RFC 5245) Using DTLS would permit to hide the USERNAME, PRIORITY, USE-CANDIDATE, ICE-CONTROLLED and ICE-CONTROLLING attributes. Because the MESSAGE-INTEGRITY protects the whole STUN response using a password that is known only by looking at the SDP exchanged, it is not possible for an attacker to inject incorrect XOR-MAPPED-ADDRESS (which would subsequently be used as peer reflexive candidate). The main issue would be that ICE is slow enough without adding a DTLS handshake on top of it for each connectivity check. Interestingly Martin Thomson proposed to use the DTLS handshake that is needed for DTLS-SRTP to do the connectivity check (draft-thomson-rtcweb-ice-dtls), but that just prove that, at least in the WebRTC case, we do not want yet another handshake. This usage has no need for a STUN URI. - - Media Keep-alive (ICE, RFC 5245) This keep-alive method uses Binding Indication, so there is really nothing to hide or protect here. This usage has no need for a STUN URI. - - SIP Keep-alive (RFC 5626) The keep-alive described in RFC 5626 is for SIP, so it is done in the same flow (using Binding Requests, not Binding Indications). If SIP is using DTLS (draft-jennings-sip-dtls, which seems to never have been standardized), then the STUN transactions are running inside DTLS, so no additional DTLS layer is needed. If SIP is using UDP, then the STUN transactions cannot use DTLS. This usage has no need for a STUN URI. - - NAT Behavior Discovery (RFC 5780) There is probably some value in using DTLS here, like for the NAT Discovery Usage, but this usage is experimental and AFAIK not deployed. The STUN URI can be used to access the NAT discovery feature of a NAT Behavior Discovery server, but accessing the full features would probably require to define a "stun-behaviors:" URI, which is out of scope for this draft. - - TURN (RFC 5766 - which is both a STUN Usage and because of the channel mechanism, a STUN extension) The reasons for doing this are already explained in the draft (HOL blocking, latency). - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJS9CoHAAoJECnERZXWan7EQfIQALbS2UhQ35zvd4RnvBWr0xvm 2fmNjPRbgMHoIjezUmY2C4qac9evPWqj4HiLhSRLhX0pnXHHK7uH671vCeUzmm1j bo+x+kS6ohg/UIWTCgevdo3moggYtWDzYro4qtGDyUPbo6f7ZTPg6hcffGsxHKhU xv/Dif9GwHVfHAfQitYYHeCgXS4rB7ejOhpvHksIU9vTnh+RcCMmkDB7puBNtuVs cAR7oGeuicg8BGsgiriXlIBxzgWAPB/uK08Vp4uq0x6xTVn+sjWU+ICFLtOMeKQi SluXJF656v08YweqpyrUB3FIH1qVm7r2vffP4Oiidgk660tKt6mNNvqf+4/E4pzx w0JE5k6K9dLIrAAUxuG0DlY2RMPBaSYmhRyeq3ci+LlQbeBXEzKjFFc0tTEzQQH3 Hk8xbzh+wm4YOm6oCzIsVilnr3CvfiQxccAjqlpOxLjOsrl05WKKvmxt5qbzt+CA otr+Zlm87dkp/FhVyyVRoqXcCfpVmiy2S9jVV/1DhLbMpFOWz6Z5hSo1IXGenKmH XkzXyP3bWhpTdeNSLY95jtYbDBXYY88TfBDAkKcDrzQ5qtgBamMY/xYmNmgmYxC7 2tqhGl0PUJ15mJ4cJUaERAXQD8MHOxUDL/FbqrKVth1co3niWk6doxbpTZM8TG6A BWiTZOq1/SUT63FdEwDS =fzTX -----END PGP SIGNATURE----- From mom040267@gmail.com Thu Feb 6 23:18:18 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3231A05BD for ; Thu, 6 Feb 2014 23:18:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 kew76OYuiW2A for ; Thu, 6 Feb 2014 23:18:17 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 15E9E1A05B7 for ; Thu, 6 Feb 2014 23:18:17 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id rr13so2876567pbb.21 for ; Thu, 06 Feb 2014 23:18:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kJl7vyZ51FZGMMCWaFIB8AlgSCc76xURFM9bwPIkWzg=; b=GZoj/AMXSqqsSznK1Jytnt2az3L1jpnRf0zK3mYYOUV4RMU7Aluk1MS/WXK195tTSJ iShAfpryEywIjq66mJ3GZwE+uEYT1jZAtZ4YbNnHXpoHIMzwKqaprXRSnGTkv309qa6N mzJFGUTZYZkYvLnrQcFepb5hbWN3rehCB2jdZmURQRay7UsfriLbIg2aWZ6bHS5T79Uf MlkErPYETZVD/OgEREc5ogcU9ANR1UYkHSRCfGt+w+iYsTIlaB2jOHCEoMwd19+IisQB h7bnpZzOvHlryf6QbpPSr2o6VlgNYOBWKu7PeacCWrkuqU7CPfToNqiPSTktOOkBeXBf NJtg== MIME-Version: 1.0 X-Received: by 10.68.195.4 with SMTP id ia4mr17807227pbc.142.1391757495909; Thu, 06 Feb 2014 23:18:15 -0800 (PST) Received: by 10.68.147.131 with HTTP; Thu, 6 Feb 2014 23:18:15 -0800 (PST) In-Reply-To: <52F40B7B.4000809@gmail.com> References: <52F40B7B.4000809@gmail.com> Date: Thu, 6 Feb 2014 23:18:15 -0800 Message-ID: From: Oleg Moskalenko To: Spencer Dawkins Content-Type: multipart/alternative; boundary=047d7b10cfbf2844ac04f1cbcb67 Cc: Martin Stiemerling , "tram@ietf.org" Subject: Re: [tram] TRAM approved for IETF and external review/next steps X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 07:18:19 -0000 --047d7b10cfbf2844ac04f1cbcb67 Content-Type: text/plain; charset=ISO-8859-1 The wording is somewhat not clean: "The work will include the addition of DTLS as an additional transport" I'd change it to a cleaner version: "The work will include the addition of DTLS as a new STUN transport" Thanks Oleg On Thu, Feb 6, 2014 at 2:23 PM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Dear TRAMsters, > > I wanted to share this with you, from the *draft* telechat narrative > minutes today: > > 4 Working Group Actions > > 4.1 WG Creation > 4.1.1 Proposed for IETF Review > . TURN Revised and Modernized (tram) > Token: Spencer Dawkins > Telechat:: > > Amy: Version -06 has no blocking comments, Hearing no objections, this > is approved. > Amy: We will send an announcement to new-work, and put this on the > agenda. > > So, here's what this means: > > The IESG and IAB have looked over the proposed charter (current text is at > https://datatracker.ietf.org/doc/charter-ietf-tram/), and they think it's > plausible enough to ask the rest of the IETF for comments. > > We were able to work through concerns from Barry , (that you've seen) and > from Sean (tightening up the language around DTLS). You can review the > change history at https://datatracker.ietf.org/ > doc/charter-ietf-tram/history/. > > The proposed charter will also be shared with other SDOs that participate > in the new-work mailing list, to collect their thoughts and identify any > potential conflicts or gaps. > > If we get positive feedback, we'll put TRAM on an upcoming formal telechat > agenda, for approval to create a working group. That could happen before > London, but TRAM will meet in London, whether as a WG or as a BOF. > > What would be helpful to me, at this point, is for you folks to converge > on the first two or three problem areas an approved working group should > have as milestones. > > You can do that on the list, or you can spend the first meeting slot > figuring that out. I'd prefer if you can figure that out on the list. > > So, if you could start a thread for each problem area you'd like to see as > a priority, that would be AWESOME ... > > Thanks, and thanks for the work you've already done to get this far. > > Spencer > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b10cfbf2844ac04f1cbcb67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The wording is somewhat not clean:

"= ;The work will include the addition of DTLS as an additional transport"= ;

<= td class=3D"" valign=3D"top">
I'd change it to a cleaner version:

"The wor= k will include the addition of DTLS as a new STUN transport"

Thanks



Oleg


On Thu, Feb 6, 2014 at 2:23 PM, Spencer Da= wkins <spencerdawkins.ietf@gmail.com> wrote:
Dear TRAMsters,

I wanted to share this with you, from the *draft* telechat narrative minute= s today:

=A0 =A0 4 Working Group Actions

4.1 WG Creation
4.1.1 Proposed for IETF Review
. TURN Revised and Modernized (tram)
=A0 =A0Token: Spencer Dawkins
=A0 Telechat::

=A0 =A0 Amy: Version -06 has no blocking comments, Hearing no objections, t= his is approved.
=A0 =A0 Amy: We will send an announcement to new-work, and put this on the = agenda.

So, here's what this means:

The IESG and IAB have looked over the proposed charter (current text is at = https://datatracker.ietf.org/doc/charter-ietf-tram/), and= they think it's plausible enough to ask the rest of the IETF for comme= nts.

We were able to work through concerns from Barry , (that you've seen) a= nd from Sean (tightening up the language around DTLS). You can review the c= hange history at https://datatracker.ietf.org/doc/cha= rter-ietf-tram/history/.

The proposed charter will also be shared with other SDOs that participate i= n the new-work mailing list, to collect their thoughts and identify any pot= ential conflicts or gaps.

If we get positive feedback, we'll put TRAM on an upcoming formal telec= hat agenda, for approval to create a working group. That could happen befor= e London, but TRAM will meet in London, whether as a WG or as a BOF.

What would be helpful to me, at this point, is for you folks to converge on= the first two or three problem areas an approved working group should have= as milestones.

You can do that on the list, or you can spend the first meeting slot figuri= ng that out. I'd prefer if you can figure that out on the list.

So, if you could start a thread for each problem area you'd like to see= as a priority, that would be AWESOME ...

Thanks, and thanks for the work you've already done to get this far.
Spencer
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b10cfbf2844ac04f1cbcb67-- From alan.b.johnston@gmail.com Fri Feb 7 05:10:51 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC86B1A03A8 for ; Fri, 7 Feb 2014 05:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 MJUg3Nnn7Q_M for ; Fri, 7 Feb 2014 05:10:49 -0800 (PST) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0A31A1DFA for ; Fri, 7 Feb 2014 05:10:49 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id y13so3148901pdi.9 for ; Fri, 07 Feb 2014 05:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=L4hENHvw0/XSUZ3qw6GBjbeP4ENbSKs0INVNpslDCqA=; b=ZjT/0oCQbJkBr3SDVHxFEGO2sA5jOjZYzvtb0i7Px0dTCRUScXMs1wj3BOSjcttWC7 CNvh/fPNBiBQKIjNnXT8nIZSP7KShhKramtJINEyvRdp4LDI51tSqlFipGnifgOR3vEX OJqVWW5TTDnVa7WcDKUSLKJQjNPMfA8FS1IaKDXGRFWXHrlLKZIEQbjTbWKFfn1QAnB1 NX/eASPpjY7JwacrmjFHulo/5K6U1mGvorBM7Zg0dmfZjObznWlfribllOuAbawVZTYe wqxnDpGrLouXbZKvx+J9DH0N5pj3W9ly5zFOsFg9pDidzY1rFmKPrwxVq6EozLko1R7P iV/A== MIME-Version: 1.0 X-Received: by 10.66.27.201 with SMTP id v9mr7806866pag.136.1391778649138; Fri, 07 Feb 2014 05:10:49 -0800 (PST) Received: by 10.68.168.132 with HTTP; Fri, 7 Feb 2014 05:10:49 -0800 (PST) In-Reply-To: <20140206202155.28963.48259.idtracker@ietfa.amsl.com> References: <20140206202155.28963.48259.idtracker@ietfa.amsl.com> Date: Fri, 7 Feb 2014 07:10:49 -0600 Message-ID: From: Alan Johnston To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=bcaec529987dfcea8104f1d0b7f9 Subject: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 13:10:51 -0000 --bcaec529987dfcea8104f1d0b7f9 Content-Type: text/plain; charset=ISO-8859-1 All, We have updated the STUN Origin draft. We have tried to incorporate all the feedback we have received to date. Comments most welcome. - Alan - ---------- Forwarded message ---------- From: Date: Thu, Feb 6, 2014 at 2:21 PM Subject: New Version Notification for draft-johnston-tram-stun-origin-01.txt To: Kundan Singh , Alan Johnston < alan.b.johnston@gmail.com>, John Yoakum , Justin Uberti < justin@uberti.name> A new version of I-D, draft-johnston-tram-stun-origin-01.txt has been successfully submitted by Alan Johnston and posted to the IETF repository. Name: draft-johnston-tram-stun-origin Revision: 01 Title: An Origin Attribute for the STUN Protocol Document date: 2014-02-04 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-johnston-tram-stun-origin-01.txt Status: https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/ Htmlized: http://tools.ietf.org/html/draft-johnston-tram-stun-origin-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-01 Abstract: STUN, or Session Traversal Utilities for NAT, is a protocol used to assist other protocols traverse Network Address Translators or NATs. STUN, and STUN extensions such as TURN, or Traversal Using Relays around NAT, and ICE, Interactive Communications Establishment, have been around for many years but with WebRTC, Web Real-Time Communications, STUN and related extensions are about to see major deployments and implementation due to these protocols being implemented in browsers. This specification defines an ORIGIN attribute for STUN that can be used in similar ways to the HTTP header field of the same name. WebRTC browsers utilizing STUN and TURN would include this attribute which would provide servers with additional information about the STUN and TURN requests they receive. This specification defines the usage of the STUN ORIGIN attribute for web and SIP contexts. 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. The IETF Secretariat --bcaec529987dfcea8104f1d0b7f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

We have updated the STUN Origin dr= aft. =A0We have tried to incorporate all the feedback we have received to d= ate.

Comments most welcome.

- Alan -

---------- Forwarded message ---= -------
From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Date: Thu, Feb 6, 2014 at 2:21 PM
Subject: New Version Notification for = draft-johnston-tram-stun-origin-01.txt
To: Kundan Singh <kundan10@gmail.com>, Alan Johnston <alan.b.johnston@gmail.com>= , John Yoakum <yoakum@avaya.com&= gt;, Justin Uberti <justin@uberti.= name>



A new version of I-D, draft-johnston-tram-stun-origin-01.txt
has been successfully submitted by Alan Johnston and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-johnston-tram-stun-origin
Revision: =A0 =A0 =A0 01
Title: =A0 =A0 =A0 =A0 =A0An Origin Attribute for the STUN Protocol
Document date: =A02014-02-04
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A09
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.o= rg/internet-drafts/draft-johnston-tram-stun-origin-01.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/d= oc/draft-johnston-tram-stun-origin/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-joh= nston-tram-stun-origin-01
Diff: =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/rfcd= iff?url2=3Ddraft-johnston-tram-stun-origin-01

Abstract:
=A0 =A0STUN, or Session Traversal Utilities for NAT, is a protocol used to<= br> =A0 =A0assist other protocols traverse Network Address Translators or NATs.=
=A0 =A0STUN, and STUN extensions such as TURN, or Traversal Using Relays =A0 =A0around NAT, and ICE, Interactive Communications Establishment, have<= br> =A0 =A0been around for many years but with WebRTC, Web Real-Time
=A0 =A0Communications, STUN and related extensions are about to see major =A0 =A0deployments and implementation due to these protocols being
=A0 =A0implemented in browsers. =A0This specification defines an ORIGIN
=A0 =A0attribute for STUN that can be used in similar ways to the HTTP
=A0 =A0header field of the same name. =A0WebRTC browsers utilizing STUN and=
=A0 =A0TURN would include this attribute which would provide servers with =A0 =A0additional information about the STUN and TURN requests they receive= .
=A0 =A0This specification defines the usage of the STUN ORIGIN attribute fo= r
=A0 =A0web and SIP contexts.




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

The IETF Secretariat


--bcaec529987dfcea8104f1d0b7f9-- From simon.perreault@viagenie.ca Fri Feb 7 06:04:44 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BBD1A1F48 for ; Fri, 7 Feb 2014 06:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham 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 zALD2BdXZnxB for ; Fri, 7 Feb 2014 06:04:42 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id B6F4B1A1EF8 for ; Fri, 7 Feb 2014 06:04:42 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8D644403B0 for ; Fri, 7 Feb 2014 09:04:42 -0500 (EST) Message-ID: <52F4E7FA.70600@viagenie.ca> Date: Fri, 07 Feb 2014 09:04:42 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140206202155.28963.48259.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:04:44 -0000 Le 2014-02-07 08:10, Alan Johnston a écrit : > We have updated the STUN Origin draft. We have tried to incorporate all > the feedback we have received to date. I'm a fan of the new text. Very well written. A nit: please s/URL/URI/g Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Feb 7 06:11:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D641A1F3D for ; Fri, 7 Feb 2014 06:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham 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 VRlB9qaonOSt for ; Fri, 7 Feb 2014 06:11:27 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id AB5B41A1F06 for ; Fri, 7 Feb 2014 06:11:27 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 40B9F412EE for ; Fri, 7 Feb 2014 09:11:27 -0500 (EST) Message-ID: <52F4E98E.6000104@viagenie.ca> Date: Fri, 07 Feb 2014 09:11:26 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tram] Milestone 1: DTLS transport X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:11:34 -0000 As requested by our benevolent AD, I'm starting a thread for each milestone. I guess the goal of each thread is to assert that we really think each milestone has support and people willing to work on it. And I suppose we would like to get a sense of prioritization between milestones. ================ Milestone 1: DTLS transport Candidate draft: draft-petithuguenin-tram-turn-dtls-00 STUN defines three transports: UDP, TCP, and TLS. A straightforward extension of this set is DTLS, enabling secure datagram-oriented transport. I think this is a top-priority milestone, and an easy one. I think we will be able to adopt a draft and send it to IESG before Toronto. I don't foresee any difficulty. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Feb 7 06:21:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505DC1A1F58 for ; Fri, 7 Feb 2014 06:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham 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 DpLhGsZhOiwU for ; Fri, 7 Feb 2014 06:21:10 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2B21A1F56 for ; Fri, 7 Feb 2014 06:21:10 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BEDEB403B0 for ; Fri, 7 Feb 2014 09:21:09 -0500 (EST) Message-ID: <52F4EBD5.8000703@viagenie.ca> Date: Fri, 07 Feb 2014 09:21:09 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tram] Milestone 2: New authentication mechanism X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:21:11 -0000 The current authentication mechanism for TURN, which is reused from STUN, has been designed with a SIP account database in mind. The new RTCWEB usages, which are mostly based on web applications, do not fit that model. A new authentication mechanism optimized for such web applications will be created. Milestone 2a: Problem analysis Candidate draft: draft-reddy-behave-turn-auth Milestone 2b: Solution(s) Candidate drafts: draft-uberti-behave-turn-rest, draft-johnston-tram-stun-origin, maybe a draft based on OAuth I would see this milestone fulfilled in two parts: problem analysis and then solution(s). One question the WG will have to answer is whether we need more than one solution. Are the proposed solutions solving different aspects of the problem, or can one solution solve all problems? Depending on the answer we will end up adopting one or more drafts to fully solve the problem. As far as I am concerned, as see this also as top priority. We should first get consensus on the problem analysis, which could be done quickly (before Toronto I would hope). Then work on solution(s) could take more time. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Feb 7 06:28:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521CB1A1F5B for ; Fri, 7 Feb 2014 06:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham 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 t8n4yr-yKq8k for ; Fri, 7 Feb 2014 06:28:10 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E05F11A1F06 for ; Fri, 7 Feb 2014 06:28:09 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B4A7A40446 for ; Fri, 7 Feb 2014 09:28:09 -0500 (EST) Message-ID: <52F4ED79.4070904@viagenie.ca> Date: Fri, 07 Feb 2014 09:28:09 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:28:11 -0000 Current TURN server discovery is based on the presence of SRV and/or NAPTR DNS records. These records are usually under the administrative control of the application or service provider, not the enterprise or the ISP on whose network the client is situated. Enterprises or ISPs wishing to provide their own TURN server, in an attempt to reduce so-called "triangle routing", need a new auto-discovery mechanism. Candidate draft: TBD (I know people have been working on this) IMHO this is also a top-priority milestone. We need to quickly have a mechanism that people can implement in WebRTC browsers now, while there is still frenetic development happening. I don't foresee actual server-side deployment happening quickly though. But as soon as clients are ready, any ISP or enterprise can deploy and immediately benefit. I imagine that the solution will be fairly simple, spec- and implementation-wise. So I think we can finish this very quickly once we have a candidate draft. We just need authors. So I would target not long after Toronto. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From tireddy@cisco.com Fri Feb 7 06:31:27 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 548171A1F06 for ; Fri, 7 Feb 2014 06:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 GU18NmzSFRVR for ; Fri, 7 Feb 2014 06:31:25 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 374B91A1F5B for ; Fri, 7 Feb 2014 06:31:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1818; q=dns/txt; s=iport; t=1391783485; x=1392993085; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ZrCmM+lvwLMc8hxciGo/Ir/uXRsoa49uJ/fBwSFvZTk=; b=Yj5lcMQs2jr8Dfwi2q6sueEKapZNtUI+hoQ/qt1Y4kOa7OaTtAipu/AQ PDYF7iH5erF75MNRRxVpBxcLGsxDkG/sspso50+zRoH/wjLp08lr4LYLL BdRwyrVJ6LiVIxvryYPgKnGQJKWsKefcSw4qFrsskLRkxcA9eV3i4Fsjn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAIDt9FKtJV2d/2dsb2JhbABZgww4V75ogQ4WdIIlAQEBBAEBASQTNBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIE4dqDcx7F45MOAaDHoEUAQOZXZBvgW+BPoIq X-IronPort-AV: E=Sophos;i="4.95,801,1384300800"; d="scan'208";a="18734126" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-6.cisco.com with ESMTP; 07 Feb 2014 14:31:25 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s17EVOpR023813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 14:31:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 08:31:24 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPJBDZCF47GjPWGkCiMSuIepmkIZqp2jJw Date: Fri, 7 Feb 2014 14:31:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242A9F81@xmb-rcd-x10.cisco.com> References: <52F4ED79.4070904@viagenie.ca> In-Reply-To: <52F4ED79.4070904@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.36.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:31:27 -0000 We are working on this draft, will publish it next week. -Tiru. > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Friday, February 07, 2014 7:58 PM > To: tram@ietf.org > Subject: [tram] Milestone 3: TURN server auto-discovery mechanism for > enterprise and ISPs >=20 > Current TURN server discovery is based on the presence of SRV and/or > NAPTR DNS records. These records are usually under the administrative > control of the application or service provider, not the enterprise or the= ISP on > whose network the client is situated. Enterprises or ISPs wishing to prov= ide > their own TURN server, in an attempt to reduce so-called "triangle routin= g", > need a new auto-discovery mechanism. >=20 > Candidate draft: TBD (I know people have been working on this) >=20 > IMHO this is also a top-priority milestone. We need to quickly have a > mechanism that people can implement in WebRTC browsers now, while > there is still frenetic development happening. I don't foresee actual ser= ver- > side deployment happening quickly though. But as soon as clients are read= y, > any ISP or enterprise can deploy and immediately benefit. >=20 > I imagine that the solution will be fairly simple, spec- and implementati= on- > wise. So I think we can finish this very quickly once we have a candidate > draft. We just need authors. So I would target not long after Toronto. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From simon.perreault@viagenie.ca Fri Feb 7 06:32:26 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3281A1F7B for ; Fri, 7 Feb 2014 06:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham 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 tvfagw-LfQ9k for ; Fri, 7 Feb 2014 06:32:25 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4697F1A1F5B for ; Fri, 7 Feb 2014 06:32:25 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2632640446 for ; Fri, 7 Feb 2014 09:32:25 -0500 (EST) Message-ID: <52F4EE78.2070009@viagenie.ca> Date: Fri, 07 Feb 2014 09:32:24 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tram] Milestone 4: STUN bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:32:26 -0000 A new revision of RFC 5389 will contain: - Various bug fixes - STUN hash algorithm agility (currently only SHA-1 is allowed) Candidate draft: TBD IMHO this is a lower-priority milestone. Completion of milestones 1,2,3 should be well in sight before we adopt a draft for this milestone. Nothing prevents individual people from starting work on this right now, but I would like the working group to delay adoption until higher-priority milestones are almost done. This is also a longer-term effort. I suppose many draft revisions will be necessary. Therefore the target would be maybe one year away. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Fri Feb 7 06:41:42 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10F11A1F64 for ; Fri, 7 Feb 2014 06:41:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham 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 a1xjCHSzxY_B for ; Fri, 7 Feb 2014 06:41:41 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 605F51A1F58 for ; Fri, 7 Feb 2014 06:41:41 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 24212403B0 for ; Fri, 7 Feb 2014 09:41:41 -0500 (EST) Message-ID: <52F4F0A4.9070104@viagenie.ca> Date: Fri, 07 Feb 2014 09:41:40 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tram] Milestone 5: TURN bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:41:42 -0000 A new revision of RFC 5766 will contain: - Various bug fixes - Support for multi-tenant servers Above is an extract from the charter we have been working on in Github. But I think "Support for multi-tenant servers" is no longer appropriate for this milestone. First, it's really about STUN, not TURN, as recent discussions have shown. Second, this can be done as an extension, as the ORIGIN draft has shown. (This does not preclude adding the extension to a STUN bis document, though.) So this leaves bug fixes. Anyway, IMHO, as for milestone 4, this is a lower-priority milestone. Completion of milestones 1,2,3 should be well in sight before we adopt a draft for this milestone. Nothing prevents individual people from starting work on this right now, but I would like the working group to delay adoption until higher-priority milestones are almost done. This is also a longer-term effort. I suppose many draft revisions will be necessary. Therefore the target would be maybe one year away. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From gsalguei@cisco.com Fri Feb 7 08:24:13 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E4F1A01F0 for ; Fri, 7 Feb 2014 08:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 9ZAv5PMFc3Gm for ; Fri, 7 Feb 2014 08:24:11 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 154691A01AF for ; Fri, 7 Feb 2014 08:24:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1566; q=dns/txt; s=iport; t=1391790251; x=1392999851; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+esh+/bOOo4dQnoOjsSnApzN1H30H2AI1JsrHawgHyo=; b=j1EQj0zfZv9m591ASsOvrbKqGUmJeBX3ZaSRtAgDIKeU1VUdl+vREavf tVmW0od70E4Npbh4N0EUEu3GSHUlnOBrQ1GR7Ep7J/UdFLAYFxm1tRsyq GvhsQm5epOPpAGJSbAiNQt/IOQKBCRt5LdCRuwTZWfzMNrMKDGGgzd+cY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FALgH9VKtJV2b/2dsb2JhbABZgww4V75ogQ4WdIIlAQEBAwEBAQEkEzQLBQsCAQg2ECcLJQIEDgWHfQgNzDsXjkozB4MkgRQEmCuBMpBvgy2CKg X-IronPort-AV: E=Sophos;i="4.95,801,1384300800"; d="scan'208";a="18767529" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 07 Feb 2014 16:24:10 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s17GOAYW011718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 16:24:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 10:24:10 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Simon Perreault Thread-Topic: [tram] Milestone 1: DTLS transport Thread-Index: AQHPJA6G6v9ZZP++pUCqWlUqOjj4hpqqXoUA Date: Fri, 7 Feb 2014 16:24:10 +0000 Message-ID: References: <52F4E98E.6000104@viagenie.ca> In-Reply-To: <52F4E98E.6000104@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.154.240] Content-Type: text/plain; charset="us-ascii" Content-ID: <5DEF665097945341A6D984BB83014BB1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] Milestone 1: DTLS transport X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:24:13 -0000 Agree on milestone and priority. As a result of recent discussion on the l= ist, the work will be a bit broader in scope that the original submission (= TURN->STUN). Thus, the candidate draft name will now be: draft-petithugueni= n-tram-stun-dtls-00 It is our hope to have this published today or Monday. Gonzalo On Feb 7, 2014, at 9:11 AM, Simon Perreault w= rote: > As requested by our benevolent AD, I'm starting a thread for each > milestone. I guess the goal of each thread is to assert that we really > think each milestone has support and people willing to work on it. And I > suppose we would like to get a sense of prioritization between milestones= . >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Milestone 1: DTLS transport > Candidate draft: draft-petithuguenin-tram-turn-dtls-00 >=20 > STUN defines three transports: UDP, TCP, and TLS. A straightforward > extension of this set is DTLS, enabling secure datagram-oriented transpor= t. >=20 > I think this is a top-priority milestone, and an easy one. I think we > will be able to adopt a draft and send it to IESG before Toronto. I > don't foresee any difficulty. >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From alan.b.johnston@gmail.com Fri Feb 7 08:36:30 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A701B1AC4A3 for ; Fri, 7 Feb 2014 08:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 9Fasklls0BKW for ; Fri, 7 Feb 2014 08:36:29 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 03E3D1A1F7B for ; Fri, 7 Feb 2014 08:36:28 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id p10so3351832pdj.15 for ; Fri, 07 Feb 2014 08:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Alhdt/ej/WBhfI6BdvvWbLJY+etbpdMmU1+5IrnS3Wk=; b=rKAYmpita0cNF4F9lWbigvKQu09gsKSc0tDlWEYV+QdhyzfK9jUjkeE/19iqrhuh5M XyJmn9zqjod2k3bZz+lrYf3PBXRVSHz8PM9IMw8wSO2drNr5AZomxQ03Ur60s9W8J078 aoWlSQ9/IdYQsV6lLBqzPUSyEdzrwideMwDloeFjyUswh34sBkPawBkyBFCnLEmvvcFg CBHYZyMR47DhlSLblQQjHZGJ40ajFA5KoLSCTKoVeK1/xFcrIuDj0fEmFaPlHX6mHUm+ WFKb3Z6EC1CFi9K6WcI/Uy3VoMYJ1xQDpBAexHMwiuo5pmhSk+Swe/kI4o+wEDuDUK7F 8RLg== MIME-Version: 1.0 X-Received: by 10.67.13.226 with SMTP id fb2mr8823428pad.146.1391790988945; Fri, 07 Feb 2014 08:36:28 -0800 (PST) Received: by 10.68.168.132 with HTTP; Fri, 7 Feb 2014 08:36:28 -0800 (PST) In-Reply-To: <52F4F0A4.9070104@viagenie.ca> References: <52F4F0A4.9070104@viagenie.ca> Date: Fri, 7 Feb 2014 10:36:28 -0600 Message-ID: From: Alan Johnston To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b07239a7f6ee504f1d39763 Cc: "tram@ietf.org" Subject: Re: [tram] Milestone 5: TURN bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:36:30 -0000 --047d7b07239a7f6ee504f1d39763 Content-Type: text/plain; charset=ISO-8859-1 Simon, I agree with this set of milestones and the prioritization. I agree that the multi-tenant work should be done in the 2nd milestone on new authentication since we need these extensions now for deployment. Milestones 4 and 5 should be the final work done in this group, which we should move forward with carefully on them to ensure that we haven't missed anything. - Alan - On Fri, Feb 7, 2014 at 8:41 AM, Simon Perreault wrote: > A new revision of RFC 5766 will contain: > > - Various bug fixes > - Support for multi-tenant servers > > Above is an extract from the charter we have been working on in Github. > But I think "Support for multi-tenant servers" is no longer appropriate > for this milestone. First, it's really about STUN, not TURN, as recent > discussions have shown. Second, this can be done as an extension, as the > ORIGIN draft has shown. (This does not preclude adding the extension to > a STUN bis document, though.) So this leaves bug fixes. > > Anyway, IMHO, as for milestone 4, this is a lower-priority milestone. > Completion of milestones 1,2,3 should be well in sight before we adopt a > draft for this milestone. Nothing prevents individual people from > starting work on this right now, but I would like the working group to > delay adoption until higher-priority milestones are almost done. > > This is also a longer-term effort. I suppose many draft revisions will > be necessary. Therefore the target would be maybe one year away. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b07239a7f6ee504f1d39763 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Simon,

I agree with this set of milesto= nes and the prioritization. =A0I agree that the multi-tenant work should be= done in the 2nd milestone on new authentication since we need these extens= ions now for deployment. =A0 Milestones 4 and 5 should be the final work do= ne in this group, which we should move forward with carefully on them to en= sure that we haven't missed anything.

- Alan -


On Fri, Feb 7, 2014 at 8:41 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
A new revision of RFC 5766 will contain:

- Various bug fixes
- Support for multi-tenant servers

Above is an extract from the charter we have been working on in Github.
But I think "Support for multi-tenant servers" is no longer appro= priate
for this milestone. First, it's really about STUN, not TURN, as recent<= br> discussions have shown. Second, this can be done as an extension, as the ORIGIN draft has shown. (This does not preclude adding the extension to
a STUN bis document, though.) So this leaves bug fixes.

Anyway, IMHO, as for milestone 4, this is a lower-priority milestone.
Completion of milestones 1,2,3 should be well in sight before we adopt a draft for this milestone. Nothing prevents individual people from
starting work on this right now, but I would like the working group to
delay adoption until higher-priority milestones are almost done.

This is also a longer-term effort. I suppose many draft revisions will
be necessary. Therefore the target would be maybe one year away.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b07239a7f6ee504f1d39763-- From gsalguei@cisco.com Fri Feb 7 09:02:45 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4D51ACCD8 for ; Fri, 7 Feb 2014 09:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 FIFaXszBP9As for ; Fri, 7 Feb 2014 09:02:43 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2451C1ACCDF for ; Fri, 7 Feb 2014 09:02:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2173; q=dns/txt; s=iport; t=1391792563; x=1393002163; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fysJh0IewMZwpbEuzH8RsC9ZnZQ99HoFmYrTVWLs/yw=; b=IU+G0p7fSdxDMjHd4E5rCYg9HEgeMyswHbVlPLkEY8yyIzlep2aXhmjR ZkeeM6BqLgwW+z2gXTHGihgfiXEvq7fy70buzbxA+DNb5KP5c5/I76Sg+ n1uyVgz/n4acjUEzkO1FGeqCzCwf/taj8elzZQ4U1se1sp/XMWVgZgnUx k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAB0R9VKtJV2Y/2dsb2JhbABZgww4V75ogQ4WdIIlAQEBAwEBAQEkRwsFCwIBCBguIQYLJQIEDgWHcQMJCA3DPQ2IaheMZoFkMweDJIEUBIkRjS6BbIEyiyyFQ4Mtgio X-IronPort-AV: E=Sophos;i="4.95,801,1384300800"; d="scan'208";a="18770574" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 07 Feb 2014 17:02:42 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s17H2gJb030487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 17:02:42 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 11:02:42 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Alan Johnston Thread-Topic: [tram] Milestone 5: TURN bis Thread-Index: AQHPJBK+U59w4yBPMkKQnD5kNw6u2JqqYe8AgAAHU4A= Date: Fri, 7 Feb 2014 17:02:41 +0000 Message-ID: <3D258814-8958-4E01-83F9-5B31844A6602@cisco.com> References: <52F4F0A4.9070104@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.154.240] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <22BBD4A0AB48814BB9ED94216DC69469@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Milestone 5: TURN bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:02:45 -0000 +1 -G On Feb 7, 2014, at 11:36 AM, Alan Johnston wrot= e: > Simon, >=20 > I agree with this set of milestones and the prioritization. I agree that= the multi-tenant work should be done in the 2nd milestone on new authentic= ation since we need these extensions now for deployment. Milestones 4 and= 5 should be the final work done in this group, which we should move forwar= d with carefully on them to ensure that we haven't missed anything. >=20 > - Alan - >=20 >=20 > On Fri, Feb 7, 2014 at 8:41 AM, Simon Perreault wrote: > A new revision of RFC 5766 will contain: >=20 > - Various bug fixes > - Support for multi-tenant servers >=20 > Above is an extract from the charter we have been working on in Github. > But I think "Support for multi-tenant servers" is no longer appropriate > for this milestone. First, it's really about STUN, not TURN, as recent > discussions have shown. Second, this can be done as an extension, as the > ORIGIN draft has shown. (This does not preclude adding the extension to > a STUN bis document, though.) So this leaves bug fixes. >=20 > Anyway, IMHO, as for milestone 4, this is a lower-priority milestone. > Completion of milestones 1,2,3 should be well in sight before we adopt a > draft for this milestone. Nothing prevents individual people from > starting work on this right now, but I would like the working group to > delay adoption until higher-priority milestones are almost done. >=20 > This is also a longer-term effort. I suppose many draft revisions will > be necessary. Therefore the target would be maybe one year away. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From john@selbie.com Fri Feb 7 09:08:21 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD6F1A0027 for ; Fri, 7 Feb 2014 09:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 tjaCfLAQUg0a for ; Fri, 7 Feb 2014 09:08:18 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id D9B2C1A0433 for ; Fri, 7 Feb 2014 09:08:17 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id n16so4504493oag.19 for ; Fri, 07 Feb 2014 09:08:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iK+jaTvi281YhJLu/qBLoImCO8sO/g5rcW0/JGg5KCM=; b=EKn327fKoG5FvAFRJrpBCmxUdoE8YZ9Z2hxxsJ6kt57pq5wrlPh5S8xWehZPXmQ/DD 2QeDCkJYZJDOSPqCjSDidos2NcSPbT/kGzqfOwRpcRPDwmy+dzmj0SodPbqIO21JzgSc yAJSIzzHjqcBGzh41gRjpt0cSruavqKGVPkRgEwBXvufwOwJQDl9uCIhmFI9YtWioUaI +38UZrou1t0+UiPDamhV26j3280E4o1m34ijGQcO12X/7cw+Mm6+rpq6XJ9vt10EV7y3 GiZdYBVmdPuvoy4UFex1O39gnG90G+sfYNYWW9uEyW+U1iYvzVFIdhxxFeGl7QlMG2cD jyrA== X-Gm-Message-State: ALoCoQl74+jB96d0iNPE2bqLjFP1YHCU3LwF7mfNf51WwnSPn+q8kdCy3f5aoMmvz/brsLUynM7Q MIME-Version: 1.0 X-Received: by 10.182.48.233 with SMTP id p9mr13685835obn.44.1391792897509; Fri, 07 Feb 2014 09:08:17 -0800 (PST) Received: by 10.76.34.131 with HTTP; Fri, 7 Feb 2014 09:08:17 -0800 (PST) In-Reply-To: <52F4E7FA.70600@viagenie.ca> References: <20140206202155.28963.48259.idtracker@ietfa.amsl.com> <52F4E7FA.70600@viagenie.ca> Date: Fri, 7 Feb 2014 09:08:17 -0800 Message-ID: From: John Selbie To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b66f0bd42727c04f1d40967 Cc: tram@ietf.org Subject: Re: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:08:21 -0000 --047d7b66f0bd42727c04f1d40967 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One minor nit to add. Be deliberate on distinguishing between "type" vs. "value" fields when explaining the new attribute. The text below references section 15 of RFC 5389. That section shows the STUN attribute format with specified fields labeled "type" and "value". The draft tends to use the words "type" and "value" interchangeably in the paragraph below. It can be inferred by context, but I suggest being more explicit and consistent with the other attribute definitions in section 15 of 5389. That is, make sure that "0x802F" is for the "type" field and that the "value" field is understood to be a string. Change this text: This specification defines a new Attribute to the STUN protocol [RFC5389]. The attribute is called ORIGIN and uses the syntax defined in Section 15 of [RFC5389]. A STUN Attribute type is a hex number in the range 0x0000 - 0xFFFF. The ORIGIN attribute value is 0x802F, chosen in the comprehension optional range. To this: This specification defines a new Attribute to the STUN protocol [RFC5389]. The attribute is called ORIGIN and uses the syntax defined in Section 15 of [RFC5389]. The number used for the this in the type field is 0x802F, chosen in the comprehension optional range. The value of ORIGIN is a variable-length value. It MUST contain a UTF-8 [RFC3629] encoded sequence of characters less than N bytes. Where "N" is some reasonable number between up 65535. jrs On Fri, Feb 7, 2014 at 6:04 AM, Simon Perreault wrote: > Le 2014-02-07 08:10, Alan Johnston a =E9crit : > > We have updated the STUN Origin draft. We have tried to incorporate al= l > > the feedback we have received to date. > > I'm a fan of the new text. Very well written. > > A nit: please s/URL/URI/g > > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b66f0bd42727c04f1d40967 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
One minor nit to add. =A0Be deliberate on distinguish= ing between "type" vs. "value" fields when explaining t= he new attribute. =A0The text below references section 15 of RFC 5389. That= section shows the STUN attribute format with specified fields labeled &quo= t;type" and "value". =A0The draft tends to use the words &qu= ot;type" and "value" interchangeably in the paragraph below.= =A0It can be inferred by context, but I suggest being more explicit and co= nsistent with the other attribute definitions in section 15 of 5389. That i= s, make sure that "0x802F" is for the "type" field and = that the "value" field is understood to be a string.

Change this text:

=A0 =A0This = specification defines a new Attribute to the STUN protocol
=A0 = =A0[RFC5389]. =A0The attribute is called ORIGIN and uses the syntax
=A0 =A0defined in Section 15 of [RFC5389]. =A0A STUN Attribute type is a= hex
=A0 =A0number in the range 0x0000 - 0xFFFF. =A0The ORIGIN attribute va= lue is
=A0 =A00x802F, chosen in the comprehension optional range.=


To this:
=A0 =A0This spe= cification defines a new Attribute to the STUN protocol
=A0 =A0[RFC5389]. =A0The attribute is called ORIGIN and uses the synta= x
=A0 =A0defined in Section 15 of [RFC5389]. =A0The number used f= or the this
=A0 =A0in the type field is 0x802F, chosen in the com= prehension optional range.
=A0 =A0The value of ORIGIN is a variable-length value. =A0It MUST cont= ain a
=A0 =A0UTF-8 [RFC3629] encoded sequence of characters less = than N bytes.

Where "N" is some reasonab= le number between up 65535.

jrs



On Fri, Feb 7, 2014 at 6:04 AM, Simon = Perreault <simon.perreault@viagenie.ca> wrote:
Le 2014-02-07 08:10, Alan Johnston a =E9crit= :
> We have updated the STUN Origin draft. =A0We have trie= d to incorporate all
> the feedback we have received to date.

I'm a fan of the new text. Very well written.

A nit: please s/URL/URI/g

Thanks,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b66f0bd42727c04f1d40967-- From iesg-secretary@ietf.org Fri Feb 7 09:20:19 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137791A0416; Fri, 7 Feb 2014 09:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 5lqEaFNrqU83; Fri, 7 Feb 2014 09:20:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6838B1A0203; Fri, 7 Feb 2014 09:20:17 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140207172017.10233.10064.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2014 09:20:17 -0800 Cc: tram WG Subject: [tram] WG Review: TURN Revised and Modernized (tram) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 17:20:19 -0000 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-02-17. TURN Revised and Modernized (tram) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Spencer Dawkins Mailing list Address: tram@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tram Archive: http://www.ietf.org/mail-archive/web/tram/current/maillist.html Charter: Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April 2010. Until recently the protocol had seen rather limited deployment. This is largely because its primary use case is as one of the NAT traversal methods of the Interactive Connectivity Establishment (ICE) framework (RFC 5245), and ICE itself was slow to achieve widespread adoption, as other mechanisms were already being used by the VoIP industry. This situation has changed drastically as ICE, and consequently TURN, are mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web. Together with the arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidenced by recent work updating the ICE framework (still in progress), and standardizing the URIs used to access a STUN (RFC 7064) or TURN (RFC 7065) server. The goal of the TRAM Working Group is to consolidate the various initiatives to update TURN and STUN to make them more suitable for the WebRTC environment. The work will include the addition of DTLS as an additional transport, authentication mechanisms, and extensions to TURN and STUN. The Working Group will closely coordinate with the appropriate Working Groups, including RTCWEB, MMUSIC, and HTTPBIS. Milestones: TBD From petithug@acm.org Fri Feb 7 11:12:40 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E4A1ACCEF for ; Fri, 7 Feb 2014 11:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=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 Pb4XaWJyxg6s for ; Fri, 7 Feb 2014 11:12:39 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 68E0B1ACCFE for ; Fri, 7 Feb 2014 11:12:39 -0800 (PST) Received: from [IPv6:2001:5c0:1101:2d00:edf1:1d57:e01c:caa6] (unknown [IPv6:2001:5c0:1101:2d00:edf1:1d57:e01c:caa6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 5D2292025C; Fri, 7 Feb 2014 20:12:37 +0100 (CET) Message-ID: <52F53023.1040709@acm.org> Date: Fri, 07 Feb 2014 12:12:35 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 MIME-Version: 1.0 To: Simon Perreault , "tram@ietf.org" References: <52F4F0A4.9070104@viagenie.ca> In-Reply-To: <52F4F0A4.9070104@viagenie.ca> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [tram] Milestone 5: TURN bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 19:12:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 TURN-bis is more of a placeholder for if and when we find bugs in it (there is only one editorial errata so far). This said I already found two in STUN, and I only did 1/3 of the analysis on it, so I expect to find some in RFC 5766. So I think that we should not have a milestone for this yet - we can always add one later. On 02/07/2014 07:41 AM, Simon Perreault wrote: > A new revision of RFC 5766 will contain: > > - Various bug fixes - Support for multi-tenant servers > > Above is an extract from the charter we have been working on in Github. But > I think "Support for multi-tenant servers" is no longer appropriate for > this milestone. First, it's really about STUN, not TURN, as recent > discussions have shown. Second, this can be done as an extension, as the > ORIGIN draft has shown. (This does not preclude adding the extension to a > STUN bis document, though.) So this leaves bug fixes. > > Anyway, IMHO, as for milestone 4, this is a lower-priority milestone. > Completion of milestones 1,2,3 should be well in sight before we adopt a > draft for this milestone. Nothing prevents individual people from starting > work on this right now, but I would like the working group to delay > adoption until higher-priority milestones are almost done. > > This is also a longer-term effort. I suppose many draft revisions will be > necessary. Therefore the target would be maybe one year away. > > Simon > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJS9TAUAAoJECnERZXWan7EHLIP/2t4Z37evbfWSRRnXj44kCdh Nt/4ljyjPvwO5iMxtYhszvTk8Q9hUx6gO4fEOKdfd371UwAUuth1J2bK5/SL5KwQ UiVLa/eWsz+PyMaLtxKhMJbdfU/BNg9TeQ0av2w+WtcHyF7dneUEaa5xA4kjZA79 18p/Jjh7SE4ekoCcmFu+Q0QbV7cS+xiGSJvJxH+ay0DRacXftXslwnKmjK8mWvJN gP9zPFF8EiMZ/2qJPpJ6/fCa4e8KmzS8G/wDVpYEUCVXvpplUYYqzhG18oyi35l5 bug/Htx1XcXhkUzI7AVsMKYAlUQNllFglbpG2CJkY0H35ZcA/Fu7eMJvootLOwaR ZjrI6hF379zg4RQuMP2SJcWauwmQKCPvsHw8kA1CMQW2Q7AbhwcJLcdljKpvVgJP G2M10MXXdlR3VSBjFepdoBwdD1groBxmqMHTXtS07Tv5J37dTSW5QWzdxPbZWUUH KWY6TBnB4MHlVSUixVk1VVXitIKyvZpeBN/zBG8nx5j6xbTm8FKMfW2BBjDXmb45 avke96xIByik2tmufRXTAiDcHBCVZ7tFA8MsY2ZqaOBdmJVub6cZuCSQS/mFLmCP MWQqyUEeZkf+esnLMmhDfFYRQa15mncH8fv6m0fY/Vu3jEoDLTMQS1R0KuldEA8R qnhtudDMts1Bd5I7Lroa =R1sn -----END PGP SIGNATURE----- From jonathan@vidyo.com Fri Feb 7 11:39:21 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02D51A0274 for ; Fri, 7 Feb 2014 11:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 ZtUZhCl7jlBW for ; Fri, 7 Feb 2014 11:39:20 -0800 (PST) Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA271A018C for ; Fri, 7 Feb 2014 11:39:20 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/7/2014 2:39:19 PM X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-76/SG:2 2/7/2014 2:38:39 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.83967 p=-0.968181 Source White X-Signature-Violations: 0-0-0-7136-c X-Note-419: 31.201 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/7/2014 2:39:10 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 96119944 for tram@ietf.org; Fri, 07 Feb 2014 14:39:18 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Fri, 7 Feb 2014 13:39:17 -0600 From: Jonathan Lennox To: "tram@ietf.org" Thread-Topic: Points that should be clarified in STUN-bis and TURN-bis Thread-Index: AQHPJDxJGQ3sy9nOWEKxY05M7kNz7A== Date: Fri, 7 Feb 2014 19:39:16 +0000 Message-ID: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <6777D8DC999A9949A5593E122BC83F1E@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 19:39:22 -0000 I'm in the middle of doing a TURN client implementation from scratch, which= gives me the opportunity to note several items that I think should be clar= ified as TRAM works on STUN-bis and TURN-bis. Some of these are statements, based on what I think are obvious conclusions= about how the protocols should behave; some are questions. Answers, or di= sagreement, are welcome for any or all of them. I haven't cleanly separated STUN and TURN issues here. Questions: 1. If a STUN (TURN) client receives a "300 Try Alternate" response to a STU= N request sent over TLS, it should then connect to a different STUN server = over TLS. What subjectAltName should it expect in the redirected-to server= 's certificate? 2. What behavior is expected if a TURN ALLOCATE request does not contain a = REQUESTED-ADDRESS-FAMILY (RFC 6156) attribute? Is the server expected to a= llocate an IPv4 address (since RFC 5766 explicitly says it only discusses I= Pv4 addresses), or is it at the server's discretion? 3. What should a TURN server's behavior be if it receives a CreatePermissio= n request with multiple XOR-PEER-ATTRIBUTE addresses, and some (but not all= ) of the addresses are administratively forbidden? Should it create or ref= resh permissions for the subset of the destinations that are allowed, despi= te sending a 403 Forbidden response, or should its operation be atomic (mea= ning if any are rejected, none are refreshed)? 3a. Relatedly: do we want to add an informational CreatePermission response= attribute listing which addresses were forbidden? 4. How should TURN channel de-framing be done if a TURN entity receives a m= essage with a channel ID in the reserved range (0x8000 - 0xffff) over TCP o= r TLS? The size of the frame differs depending on whether the message is a= TURN message (length+20) or a ChannelData message (length+4, rounded up to= a multiple of 4). There's no obvious reason to expect any particular leng= th formula for items in the reserved range, unless we specify one preemptiv= ely. However, the spec says that an implementation MUST NOT assume that a = TURN message always starts with a 0 bit. Statements: 1. Since all TURN requests must be authenticated, any TURN request can rece= ive a 401 or 438 response, which should be handled in the same manner as de= scribed in the TURN spec for the Allocate request. (401 would normally onl= y happen when the credentials provisioned for the user are changed.) 2. The REQUESTED-ADDRESS-FAMILY attribute (RFC 6156) may be used for TURN/T= CP allocations (RFC 6062), if a TURN server supports both mechanisms. (Neit= her of these documents normatively cites the other, though RFC 6156 notes t= hat TURN can be used to request address/port pairs for receiving TCP.) 3. Nonces are independent for different STUN servers. STUN clients using l= ong-term credentials should normally expect to receive a 438 Stale Nonce re= sponse to the request they send after a 300 Try Alternate redirection, unle= ss they've previously been redirected to that address and already know a no= nce to use. From simon.perreault@viagenie.ca Fri Feb 7 12:05:46 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E9E1AD190 for ; Fri, 7 Feb 2014 12:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham 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 bWuSnJfpr9q4 for ; Fri, 7 Feb 2014 12:05:44 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CD01B1AC7F0 for ; Fri, 7 Feb 2014 12:05:44 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 65C0140234 for ; Fri, 7 Feb 2014 15:05:44 -0500 (EST) Message-ID: <52F53C98.1070202@viagenie.ca> Date: Fri, 07 Feb 2014 15:05:44 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tram@ietf.org References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> In-Reply-To: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 20:05:46 -0000 Jonathan, This is great input, thanks! Let's see if we can file issues in our Trac project so that we don't forget... A quick remark about this item: Le 2014-02-07 14:39, Jonathan Lennox a écrit : > 2. What behavior is expected if a TURN ALLOCATE request does not > contain a REQUESTED-ADDRESS-FAMILY (RFC 6156) attribute? Is the > server expected to allocate an IPv4 address (since RFC 5766 > explicitly says it only discusses IPv4 addresses), or is it at the > server's discretion? Answer: It must create an IPv4 allocation. Remark: In TURN bis I would want clients to *always* send REQUESTED-ADDRESS-FAMILY. That does not necessarily imply merging TURN with TURN-IPv6, but it's an option I would consider. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From john@selbie.com Fri Feb 7 12:35:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39C31A04BE for ; Fri, 7 Feb 2014 12:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 PH2HxHrmPAab for ; Fri, 7 Feb 2014 12:35:08 -0800 (PST) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by ietfa.amsl.com (Postfix) with ESMTP id B2DF31A0478 for ; Fri, 7 Feb 2014 12:35:08 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id wn1so4586295obc.37 for ; Fri, 07 Feb 2014 12:35:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MKgvYMQsv34OUSIAHQx8xONjcOsfAHMSLFADvi7pjcI=; b=INGTp/u1xVN90nel4mHLW7eGNAXxXwMbM7Wm0I5b6YhG3TetoAxfZwZEVDVHb7ReN1 62C3q7HnsEn0PusLhlR9B8MWmmIjzzfSJs5gpVYo/L+oSFCpyu4yEJudYl8/GBoLvbKN ytmKrO+xH4s4/8Jvc1McRfd0F08inFAmkLQbY5X4+mv9sPsTWzsPGsePJ8nDH4i1DWmO t87OmjU1sV/BUSrS1KMGtmeFAMEA86ibj+II0EwS66G4VIYfd+pkXR7SWL4HyWlu16qV a6cLRUnKDxixpkODydNvMSpnjbgwckWXZqW+MViVidrKmEJzdbtiukfLJW9ja0novPsB us+A== X-Gm-Message-State: ALoCoQmQ0Xjxs8UXb/sT/66ATGkiKA1z2yQhcCPbQVatCV5mVFHufTZSjFU37jL0CwmgAD5IuqK9 MIME-Version: 1.0 X-Received: by 10.182.196.3 with SMTP id ii3mr14259028obc.11.1391805308331; Fri, 07 Feb 2014 12:35:08 -0800 (PST) Received: by 10.76.34.131 with HTTP; Fri, 7 Feb 2014 12:35:08 -0800 (PST) In-Reply-To: References: <20140206202155.28963.48259.idtracker@ietfa.amsl.com> <52F4E7FA.70600@viagenie.ca> Date: Fri, 7 Feb 2014 12:35:08 -0800 Message-ID: From: John Selbie To: Simon Perreault Content-Type: multipart/alternative; boundary=089e015383e4fffb0a04f1d6ecbe Cc: tram@ietf.org Subject: Re: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 20:35:12 -0000 --089e015383e4fffb0a04f1d6ecbe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Additionally, one other thing as an implementation note. STUN attributes are expected to align on 4-byte boundaries. The way padding applies to the LENGTH field of each STUN attribute differs between RFC 3489 and RFC 5389. Explicit attribute padding in RFC 3489 vs implicit padding between attributes in RFC 5389. If the length of the ORIGIN value is not a multiple of 4, this may break compatibility with RFC 3489. STUN servers written for RFC 3489 may encounter a parsing error when servicing a binding request from such a client that includes an ORIGIN attribute with a length not divisible by 4. (Can't recall what Vovida stund.097 does, but I remember hitting this issue during the development of stuntman). This is not a new issue for STUN. Implementers should take note of this legacy requirement if the server responding to binding requests can not be assumed to be RFC 5389 compliant. The workaround is to explicitly pad the string attribute with zero's and have it's length field adjusted accordingly. There's a presumption with this workaround that the server treats the attribute bytes as a "C" string and ignores the extra zero bytes when processing it. jrs On Fri, Feb 7, 2014 at 9:08 AM, John Selbie wrote: > One minor nit to add. Be deliberate on distinguishing between "type" vs. > "value" fields when explaining the new attribute. The text below > references section 15 of RFC 5389. That section shows the STUN attribute > format with specified fields labeled "type" and "value". The draft tends > to use the words "type" and "value" interchangeably in the paragraph belo= w. > It can be inferred by context, but I suggest being more explicit and > consistent with the other attribute definitions in section 15 of 5389. Th= at > is, make sure that "0x802F" is for the "type" field and that the "value" > field is understood to be a string. > > Change this text: > > This specification defines a new Attribute to the STUN protocol > [RFC5389]. The attribute is called ORIGIN and uses the syntax > defined in Section 15 of [RFC5389]. A STUN Attribute type is a hex > number in the range 0x0000 - 0xFFFF. The ORIGIN attribute value is > 0x802F, chosen in the comprehension optional range. > > > To this: > This specification defines a new Attribute to the STUN protocol > [RFC5389]. The attribute is called ORIGIN and uses the syntax > defined in Section 15 of [RFC5389]. The number used for the this > in the type field is 0x802F, chosen in the comprehension optional rang= e. > The value of ORIGIN is a variable-length value. It MUST contain a > UTF-8 [RFC3629] encoded sequence of characters less than N bytes. > > Where "N" is some reasonable number between up 65535. > > jrs > > > > On Fri, Feb 7, 2014 at 6:04 AM, Simon Perreault < > simon.perreault@viagenie.ca> wrote: > >> Le 2014-02-07 08:10, Alan Johnston a =E9crit : >> > We have updated the STUN Origin draft. We have tried to incorporate a= ll >> > the feedback we have received to date. >> >> I'm a fan of the new text. Very well written. >> >> A nit: please s/URL/URI/g >> >> Thanks, >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > > --089e015383e4fffb0a04f1d6ecbe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Additionally,=A0one other thing=A0as an implementatio= n note.

STUN attributes are expected to align on 4= -byte boundaries.=A0 The way padding applies to the LENGTH field of each ST= UN attribute differs between RFC 3489 and RFC 5389.=A0Explicit attribute pa= dding in RFC 3489 vs implicit padding between attributes in RFC 5389.

If the length of the ORIGIN value is not a multiple of = 4, this may break compatibility with RFC 3489.=A0 STUN servers written for = RFC 3489 may encounter a parsing error when servicing a binding request fro= m such a client that includes an ORIGIN attribute with a length not divisib= le by 4.=A0 (Can't recall what Vovida stund.097 does, but I remember hi= tting=A0this=A0issue during the development of stuntman).

This is not a new issue for STUN. Implementers should t= ake note of this legacy requirement if the server responding to binding req= uests=A0can not be assumed to be RFC 5389 compliant. The workaround is to e= xplicitly pad the string attribute with zero's and have it's length= field adjusted accordingly. There's a presumption with this workaround= that the server treats the attribute bytes as a "C" string and i= gnores the extra zero bytes when processing it.

jrs




On Fri, Feb 7, 2014 at = 9:08 AM, John Selbie <john@selbie.com> wrote:
One minor nit to add. = =A0Be deliberate on distinguishing between "type" vs. "value= " fields when explaining the new attribute. =A0The text below referenc= es section 15 of RFC 5389. That section shows the STUN attribute format wit= h specified fields labeled "type" and "value". =A0The d= raft tends to use the words "type" and "value" intercha= ngeably in the paragraph below. =A0It can be inferred by context, but I sug= gest being more explicit and consistent with the other attribute definition= s in section 15 of 5389. That is, make sure that "0x802F" is for = the "type" field and that the "value" field is understo= od to be a string.

Change this text:

=A0 =A0This = specification defines a new Attribute to the STUN protocol
=A0 = =A0[RFC5389]. =A0The attribute is called ORIGIN and uses the syntax
=A0 =A0defined in Section 15 of [RFC5389]. =A0A STUN Attribute type is a= hex
=A0 =A0number in the range 0x0000 - 0xFFFF. =A0The ORIGIN attribute va= lue is
=A0 =A00x802F, chosen in the comprehension optional range.=


To this:
=A0 =A0This spe= cification defines a new Attribute to the STUN protocol
=A0 =A0[RFC5389]. =A0The attribute is called ORIGIN and uses the synta= x
=A0 =A0defined in Section 15 of [RFC5389]. =A0The number used f= or the this
=A0 =A0in the type field is 0x802F, chosen in the com= prehension optional range.
=A0 =A0The value of ORIGIN is a variable-length value. =A0It MUST cont= ain a
=A0 =A0UTF-8 [RFC3629] encoded sequence of characters less = than N bytes.

Where "N" is some reasonab= le number between up 65535.

jrs



On Fri, Feb 7, 2014 at 6:04 AM, Simon Perreault <simon.perreau= lt@viagenie.ca> wrote:
Le 2014-02-07 08:10, Alan Johnston a =E9crit :
> We have updated the STUN Origin draft. =A0We have tried to incorp= orate all
> the feedback we have received to date.

I'm a fan of the new text. Very well written.

A nit: please s/URL/URI/g

Thanks,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--089e015383e4fffb0a04f1d6ecbe-- From alan.b.johnston@gmail.com Fri Feb 7 12:51:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624DD1AD34C for ; Fri, 7 Feb 2014 12:51:34 -0800 (PST) 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, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham 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 3gXFPRe-XnEQ for ; Fri, 7 Feb 2014 12:51:31 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4361A0459 for ; Fri, 7 Feb 2014 12:51:31 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id x13so1920592ief.23 for ; Fri, 07 Feb 2014 12:51:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lhZUD0Ar1fTQd6YPvcbzhi+52pftcMHgpqmFvnFxqoY=; b=i4cmxsvHw8pA62xjMc/ewxJtSmUc7eCMQmZrIa30SKz82Oi9MvGlYpy1JYuqB9OqWe vnVR8f7ZUuwsr6/gq8vWts7fyfNSSc94VN4ShyQghUVKYT5Zt0RCgTdsU7R/3ddK9z4d 9vcxNDY417xiqEWX3ginQX3IATwl5HSMpmQQ3IpyNx9FLKP4jxMX/I6UdcxpbSi9f6Zh helf0FKIeNUL45gAH+zL38/4gexnpsjrPomYV3ebgZIoTAdL/GOW66iqa5vpDPnkgie8 SSa4io837dPHiGRsYWiSsyvzk7MU9B2MiZKaNXpZlo4HcuwBHPSugU6eFyWT8W8aZlWu YwNQ== X-Received: by 10.50.154.102 with SMTP id vn6mr2034384igb.1.1391806291169; Fri, 07 Feb 2014 12:51:31 -0800 (PST) Received: from [10.147.9.141] ([166.170.23.4]) by mx.google.com with ESMTPSA id kz4sm13266576igb.4.2014.02.07.12.51.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Feb 2014 12:51:29 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-CF277EB6-309A-471E-AC4B-83E49342E844 Mime-Version: 1.0 (1.0) From: Alan Johnston X-Mailer: iPhone Mail (11B554a) In-Reply-To: Date: Fri, 7 Feb 2014 15:51:26 -0500 Content-Transfer-Encoding: 7bit Message-Id: <7DD62C46-F124-4116-80F5-84AE708E9BCE@gmail.com> References: <20140206202155.28963.48259.idtracker@ietfa.amsl.com> <52F4E7FA.70600@viagenie.ca> To: John Selbie Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-01.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 20:51:34 -0000 --Apple-Mail-CF277EB6-309A-471E-AC4B-83E49342E844 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John, Appreciate the detailed feedback. We will make sure to clarify and highlight= these issues in the next version.=20 - Alan - > On Feb 7, 2014, at 3:35 PM, John Selbie wrote: >=20 > Additionally, one other thing as an implementation note. >=20 > STUN attributes are expected to align on 4-byte boundaries. The way paddi= ng applies to the LENGTH field of each STUN attribute differs between RFC 34= 89 and RFC 5389. Explicit attribute padding in RFC 3489 vs implicit padding b= etween attributes in RFC 5389. >=20 > If the length of the ORIGIN value is not a multiple of 4, this may break c= ompatibility with RFC 3489. STUN servers written for RFC 3489 may encounter= a parsing error when servicing a binding request from such a client that in= cludes an ORIGIN attribute with a length not divisible by 4. (Can't recall w= hat Vovida stund.097 does, but I remember hitting this issue during the deve= lopment of stuntman). >=20 > This is not a new issue for STUN. Implementers should take note of this le= gacy requirement if the server responding to binding requests can not be ass= umed to be RFC 5389 compliant. The workaround is to explicitly pad the strin= g attribute with zero's and have it's length field adjusted accordingly. The= re's a presumption with this workaround that the server treats the attribute= bytes as a "C" string and ignores the extra zero bytes when processing it. >=20 > jrs >=20 >=20 >=20 >=20 >> On Fri, Feb 7, 2014 at 9:08 AM, John Selbie wrote: >> One minor nit to add. Be deliberate on distinguishing between "type" vs.= "value" fields when explaining the new attribute. The text below reference= s section 15 of RFC 5389. That section shows the STUN attribute format with s= pecified fields labeled "type" and "value". The draft tends to use the word= s "type" and "value" interchangeably in the paragraph below. It can be infe= rred by context, but I suggest being more explicit and consistent with the o= ther attribute definitions in section 15 of 5389. That is, make sure that "0= x802F" is for the "type" field and that the "value" field is understood to b= e a string. >>=20 >> Change this text: >>=20 >> This specification defines a new Attribute to the STUN protocol >> [RFC5389]. The attribute is called ORIGIN and uses the syntax >> defined in Section 15 of [RFC5389]. A STUN Attribute type is a hex >> number in the range 0x0000 - 0xFFFF. The ORIGIN attribute value is >> 0x802F, chosen in the comprehension optional range. >>=20 >>=20 >> To this: >> This specification defines a new Attribute to the STUN protocol >> [RFC5389]. The attribute is called ORIGIN and uses the syntax >> defined in Section 15 of [RFC5389]. The number used for the this >> in the type field is 0x802F, chosen in the comprehension optional rang= e. >> The value of ORIGIN is a variable-length value. It MUST contain a >> UTF-8 [RFC3629] encoded sequence of characters less than N bytes. >>=20 >> Where "N" is some reasonable number between up 65535. >>=20 >> jrs >>=20 >>=20 >>=20 >>> On Fri, Feb 7, 2014 at 6:04 AM, Simon Perreault wrote: >>> Le 2014-02-07 08:10, Alan Johnston a =C3=A9crit : >>> > We have updated the STUN Origin draft. We have tried to incorporate a= ll >>> > the feedback we have received to date. >>>=20 >>> I'm a fan of the new text. Very well written. >>>=20 >>> A nit: please s/URL/URI/g >>>=20 >>> Thanks, >>> Simon >>> -- >>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >>> STUN/TURN server --> http://numb.viagenie.ca >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram --Apple-Mail-CF277EB6-309A-471E-AC4B-83E49342E844 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
John,

Appreci= ate the detailed feedback. We will make sure to clarify and highlight these i= ssues in the next version. 

- Alan -


On Feb 7, 2014, at 3:35 PM, John Selbie <john@selbie.com> wrote:

Additionally, one other thing = ;as an implementation note.

STUN attributes are exp= ected to align on 4-byte boundaries.  The way padding applies to the LE= NGTH field of each STUN attribute differs between RFC 3489 and RFC 5389.&nbs= p;Explicit attribute padding in RFC 3489 vs implicit padding between attribu= tes in RFC 5389.

If the length of the ORIGIN value is not a multiple of 4= , this may break compatibility with RFC 3489.  STUN servers written for= RFC 3489 may encounter a parsing error when servicing a binding request fro= m such a client that includes an ORIGIN attribute with a length not divisibl= e by 4.  (Can't recall what Vovida stund.097 does, but I remember hitti= ng this issue during the development of stuntman).

This is not a new issue for STUN. Implementers should ta= ke note of this legacy requirement if the server responding to binding reque= sts can not be assumed to be RFC 5389 compliant. The workaround is to e= xplicitly pad the string attribute with zero's and have it's length field ad= justed accordingly. There's a presumption with this workaround that the serv= er treats the attribute bytes as a "C" string and ignores the extra zero byt= es when processing it.

jrs




On Fri, Feb 7, 2014 at 9:08= AM, John Selbie <john@selbie.com> wrote:
One minor nit to add. &n= bsp;Be deliberate on distinguishing between "type" vs. "value" fields when e= xplaining the new attribute.  The text below references section 15 of R= FC 5389. That section shows the STUN attribute format with specified fields l= abeled "type" and "value".  The draft tends to use the words "type" and= "value" interchangeably in the paragraph below.  It can be inferred by= context, but I suggest being more explicit and consistent with the other at= tribute definitions in section 15 of 5389. That is, make sure that "0x802F" i= s for the "type" field and that the "value" field is understood to be a stri= ng.

Change this text:

   = This specification defines a new Attribute to the STUN protocol
&n= bsp;  [RFC5389].  The attribute is called ORIGIN and uses the synt= ax
   defined in Section 15 of [RFC5389].  A STUN A= ttribute type is a hex
   number in the range 0x0000 - 0xFFFF.  The ORIGIN attr= ibute value is
   0x802F, chosen in the comprehension op= tional range.


To this:
&nb= sp;  This specification defines a new Attribute to the STUN protocol
   [RFC5389].  The attribute is called ORIGIN and uses t= he syntax
   defined in Section 15 of [RFC5389].  T= he number used for the this
   in the type field is 0x80= 2F, chosen in the comprehension optional range.
   The value of ORIGIN is a variable-length value.  It M= UST contain a
   UTF-8 [RFC3629] encoded sequence of cha= racters less than N bytes.

Where "N" is some reason= able number between up 65535.

jrs



= On Fri, Feb 7, 2014 at 6:04 AM, Simon Perreault <simon.perreault@v= iagenie.ca> wrote:
Le 2014-02-07 08:10, Alan Johnston a =C3=A9crit :
> We have updated the STUN Origin draft.  We have tried to inco= rporate all
> the feedback we have received to date.

I'm a fan of the new text. Very well written.

A nit: please s/URL/URI/g

Thanks,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tram


____________________= ___________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman= /listinfo/tram
= --Apple-Mail-CF277EB6-309A-471E-AC4B-83E49342E844-- From mom040267@gmail.com Fri Feb 7 12:58:50 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1621ACD00 for ; Fri, 7 Feb 2014 12:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 MC50xPBr40Lp for ; Fri, 7 Feb 2014 12:58:48 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 748A91A0459 for ; Fri, 7 Feb 2014 12:58:48 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa1so3655191pad.41 for ; Fri, 07 Feb 2014 12:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qhd7atk9ghjWIkniqq6E6kBSoXswGYH7DMWNKVeJ/Gw=; b=uvZUJdLjwFkzOoWTril1weWTTNFjvlJLN+YBZAWZa3QaMjkv6ekxrx2FhE0qEB1Srl 3x1odk9FEW3GoLJnGKna2XPcu/B9XeESGoUwRT/O0b5g5vU7dzVPT8Gkv8eeSsIwYnDr nymEtcrCcwV7LGy/6ow/+mBZuQzMA/7G3OFIUOPaqTMmMmfFy2gao9oDsEVWD7P7OOtG QnEcRXZtXp1EbRsdmB8KEti9MAeyVxfXsZ7tAkWVqfhmffceqCEhpOEkS6nbBi8tIsaK /mytpFkY93YD0bnAAslIlEHyflMM2nzNifkC3yy5LOQVZRFpXyMuEm0Dc6r1dO+CclaN etTw== MIME-Version: 1.0 X-Received: by 10.67.14.231 with SMTP id fj7mr10151139pad.115.1391806728427; Fri, 07 Feb 2014 12:58:48 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 7 Feb 2014 12:58:48 -0800 (PST) In-Reply-To: <52F53C98.1070202@viagenie.ca> References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> Date: Fri, 7 Feb 2014 12:58:48 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=001a113453eca4dc6e04f1d74105 Cc: "tram@ietf.org" Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 20:58:50 -0000 --001a113453eca4dc6e04f1d74105 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Still we want a default behavior when a client (legacy ?) does not send REQUESTED-ADDRESS-FAMILY (which is IPv4). I do not see any good reason to introduce a backward incompatibility for the legacy clients unless there is a good really important security reasons. I do not see any security problem with the default behavior. On Fri, Feb 7, 2014 at 12:05 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Jonathan, > > This is great input, thanks! Let's see if we can file issues in our Trac > project so that we don't forget... > > A quick remark about this item: > > Le 2014-02-07 14:39, Jonathan Lennox a =E9crit : > > 2. What behavior is expected if a TURN ALLOCATE request does not > > contain a REQUESTED-ADDRESS-FAMILY (RFC 6156) attribute? Is the > > server expected to allocate an IPv4 address (since RFC 5766 > > explicitly says it only discusses IPv4 addresses), or is it at the > > server's discretion? > > Answer: It must create an IPv4 allocation. > > Remark: In TURN bis I would want clients to *always* send > REQUESTED-ADDRESS-FAMILY. That does not necessarily imply merging TURN > with TURN-IPv6, but it's an option I would consider. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a113453eca4dc6e04f1d74105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Still we want a default behavior when a client (legacy ?) = does not send=A0 REQUESTED-ADDRESS-FAMILY (which is IPv4). I do not see any= good reason to introduce a backward incompatibility for the legacy clients= unless there is a good really important security reasons. I do not see any= security problem with the default behavior.


On Fri,= Feb 7, 2014 at 12:05 PM, Simon Perreault <simon.perreault@viage= nie.ca> wrote:
Jonathan,

This is great input, thanks! Let's see if we can file issues in our Tra= c
project so that we don't forget...

A quick remark about this item:

Le 2014-02-07 14:39, Jonathan Lennox a =E9crit :
> 2. What behavior is expected if a TURN ALLOCATE requ= est does not
> contain a REQUESTED-ADDRESS-FAMILY (RFC 6156) attribute? =A0Is the
> server expected to allocate an IPv4 address (since RFC 5766
> explicitly says it only discusses IPv4 addresses), or is it at the
> server's discretion?

Answer: It must create an IPv4 allocation.

Remark: In TURN bis I would want clients to *always* send
REQUESTED-ADDRESS-FAMILY. That does not necessarily imply merging TURN
with TURN-IPv6, but it's an option I would consider.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_____________________= __________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--001a113453eca4dc6e04f1d74105-- From simon.perreault@viagenie.ca Fri Feb 7 13:15:10 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776041A04C5 for ; Fri, 7 Feb 2014 13:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham 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 bnX77LPhr_RJ for ; Fri, 7 Feb 2014 13:15:08 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id CE8D11A01E3 for ; Fri, 7 Feb 2014 13:15:08 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4F48940234 for ; Fri, 7 Feb 2014 16:15:08 -0500 (EST) Message-ID: <52F54CDC.1040502@viagenie.ca> Date: Fri, 07 Feb 2014 16:15:08 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tram@ietf.org References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 21:15:10 -0000 Le 2014-02-07 15:58, Oleg Moskalenko a écrit : > Still we want a default behavior when a client (legacy ?) does not send > REQUESTED-ADDRESS-FAMILY (which is IPv4). I do not see any good reason > to introduce a backward incompatibility for the legacy clients unless > there is a good really important security reasons. I do not see any > security problem with the default behavior. I phrased my wish very carefully: "In TURN bis I would want clients to *always* send REQUESTED-ADDRESS-FAMILY." Note that I did not say anything about server behaviour. Intentionally. :) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mom040267@gmail.com Fri Feb 7 13:19:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98031A0459 for ; Fri, 7 Feb 2014 13:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 mvOhbNBk1toi for ; Fri, 7 Feb 2014 13:19:33 -0800 (PST) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 928111A020C for ; Fri, 7 Feb 2014 13:19:33 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id y13so3667582pdi.9 for ; Fri, 07 Feb 2014 13:19:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qV7F0RUl9KTsIMoAt6iLQbU3hViUGabjJBbt8WP8eFo=; b=wVj1qI523zKpw6OFp5inJyLZBKV2uNshHzNHJnro5DMmc+lJXJcOwC5mB7VpdjF5z5 AWmhGHP6ghDp2lJHu1TOgxn+o1Sn0JHcV1/XckeETVqduEx+XOEPuaT4eirIzuuw0eQF eUcD6R78TkQIIU2jAhp212+0U8LLCCfkjgISlhJ2koSKUsh8HRphSNfDgOpkT9n5fKbN pLjzK/fNZz8u4bGAUylRAOK9iu2AGxCAvUCYBUWPkJO3fuTmQDgOZBHfV6T/O3aj0ISP 5GexgOjwsv6D9HYGeTTyfNqNjLi8oxz4gfOuz5GzuATn6zuASX07NH24eExPgjDdt/Xj Kb7A== MIME-Version: 1.0 X-Received: by 10.68.139.100 with SMTP id qx4mr22127131pbb.144.1391807973462; Fri, 07 Feb 2014 13:19:33 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 7 Feb 2014 13:19:33 -0800 (PST) In-Reply-To: <52F54CDC.1040502@viagenie.ca> References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <52F54CDC.1040502@viagenie.ca> Date: Fri, 7 Feb 2014 13:19:33 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c361d2da98f204f1d78b6d Cc: "tram@ietf.org" Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 21:19:35 -0000 --001a11c361d2da98f204f1d78b6d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well... OK. If we want the client always to send the address-family - but we do not enforce that on the receiving side... that sounds awkward, like a speed limit without cops. It is great - but does that strict requirement make sense without enforcement ? We can always say that TURN client SHOULD send the address-family, but MUST probably would be too strict... I guess. On Fri, Feb 7, 2014 at 1:15 PM, Simon Perreault wrote: > Le 2014-02-07 15:58, Oleg Moskalenko a =E9crit : > > Still we want a default behavior when a client (legacy ?) does not send > > REQUESTED-ADDRESS-FAMILY (which is IPv4). I do not see any good reason > > to introduce a backward incompatibility for the legacy clients unless > > there is a good really important security reasons. I do not see any > > security problem with the default behavior. > > I phrased my wish very carefully: > > "In TURN bis I would want clients to *always* send > REQUESTED-ADDRESS-FAMILY." > > Note that I did not say anything about server behaviour. Intentionally. := ) > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a11c361d2da98f204f1d78b6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Well... OK. If we want the client always to send the addre= ss-family - but we do not enforce that on the receiving side... that sounds= awkward,=A0 like a speed limit without cops. It is great - but does that s= trict requirement make sense without enforcement ? We can always say that T= URN client SHOULD send the address-family, but MUST probably would be too s= trict... I guess.


On Fri,= Feb 7, 2014 at 1:15 PM, Simon Perreault <simon.perreault@viagen= ie.ca> wrote:
Le 2014-02-07 15:58, Oleg Moskalenko a =E9cr= it :
> Still we want a default behavior when a client (lega= cy ?) does not send
> REQUESTED-ADDRESS-FAMILY (which is IPv4). I do not see any good reason=
> to introduce a backward incompatibility for the legacy clients unless<= br> > there is a good really important security reasons. I do not see any > security problem with the default behavior.

I phrased my wish very carefully:

"In TURN bis I would want clients to *always* send
REQUESTED-ADDRESS-FAMILY."

Note that I did not say anything about server behaviour. Intentionall= y. :)

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--001a11c361d2da98f204f1d78b6d-- From simon.perreault@viagenie.ca Fri Feb 7 13:50:09 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FC41A051E for ; Fri, 7 Feb 2014 13:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham 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 v9Vsx2LPYtDm for ; Fri, 7 Feb 2014 13:50:06 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E3E091A04CA for ; Fri, 7 Feb 2014 13:50:05 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9302E40234 for ; Fri, 7 Feb 2014 16:50:05 -0500 (EST) Message-ID: <52F5550D.3020203@viagenie.ca> Date: Fri, 07 Feb 2014 16:50:05 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: tram@ietf.org References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <52F54CDC.1040502@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 21:50:10 -0000 Le 2014-02-07 16:19, Oleg Moskalenko a écrit : > Well... OK. If we want the client always to send the address-family - > but we do not enforce that on the receiving side... that sounds > awkward, like a speed limit without cops. It is great - but does that > strict requirement make sense without enforcement ? We can always say > that TURN client SHOULD send the address-family, but MUST probably would > be too strict... I guess. The idea is: first, we specify that TURN bis clients MUST send REQUESTED-ADDRESS-FAMILY. Then we specify TURN bis server behaviour depending on the value of REQUESTED-ADDRESS-FAMILY. We do *not* specify TURN bis server behaviour when that parameter is absent. If the parameter is absent, the client is not following the TURN bis spec, and the server is free to behave however it wants. That includes *wink wink* being backward-compatible with TURN. This is exactly like the STUNv2 magic cookie: STUNv2 clients MUST send the magic cookie, and STUNv2 server behaviour is defined when the cookie is present. But STUNv2 does not specify server behaviour when the cookie is absent. The cookie being absent means the client is not a STUNv2 client. The server is free to behave however it wishes. That includes *wink wink* being backward-compatible with STUNv1. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mom040267@gmail.com Fri Feb 7 14:08:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B001A04B2 for ; Fri, 7 Feb 2014 14:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 VhzYOEJRYvRo for ; Fri, 7 Feb 2014 14:08:32 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8D21A051E for ; Fri, 7 Feb 2014 14:08:31 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id v10so3701612pde.0 for ; Fri, 07 Feb 2014 14:08:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5xc4bKIKyNci1Wbg+o+XXdDkBui/HMT8X88cisq9NIE=; b=Vudd+gl9f/hWTpiaHyJfPzH8xRhdCU6h/tnYj2KaBk/OT2Qc5iAzTof78DePi4F+7R CJ9D9t3XM16QQk6rAq94fyCvwyA1XUqUZ6028Inbu86SVON6tAvLDkt5barQvnq4Jt94 ttxNGFHNBXDQpnIWA74qp1CAuw8+zEqYtBPyE4STdyy3lcPzic6Jc22Rkx922mm67Y5q ge5JM75Ujt6ZXDCAHB4r3pVRssbdgR6nQ9DqtjMdDUetIh6Xmshkhe2kXghY7OFhAP+J xpHUxIVGanNtfoDSM9FWu17GEFJIgQhmYVBvp/tVU9PSsYcpxNcDXoXbAEsqzdaUKWhW 5uBw== MIME-Version: 1.0 X-Received: by 10.67.14.231 with SMTP id fj7mr10454844pad.115.1391810911047; Fri, 07 Feb 2014 14:08:31 -0800 (PST) Received: by 10.68.147.131 with HTTP; Fri, 7 Feb 2014 14:08:30 -0800 (PST) In-Reply-To: <52F5550D.3020203@viagenie.ca> References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <52F54CDC.1040502@viagenie.ca> <52F5550D.3020203@viagenie.ca> Date: Fri, 7 Feb 2014 14:08:30 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=001a113453ecf2962304f1d83aac Cc: "tram@ietf.org" Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 22:08:34 -0000 --001a113453ecf2962304f1d83aac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable OK, that's fine. Oleg On Fri, Feb 7, 2014 at 1:50 PM, Simon Perreault wrote: > Le 2014-02-07 16:19, Oleg Moskalenko a =E9crit : > > Well... OK. If we want the client always to send the address-family - > > but we do not enforce that on the receiving side... that sounds > > awkward, like a speed limit without cops. It is great - but does that > > strict requirement make sense without enforcement ? We can always say > > that TURN client SHOULD send the address-family, but MUST probably woul= d > > be too strict... I guess. > > The idea is: first, we specify that TURN bis clients MUST send > REQUESTED-ADDRESS-FAMILY. Then we specify TURN bis server behaviour > depending on the value of REQUESTED-ADDRESS-FAMILY. We do *not* specify > TURN bis server behaviour when that parameter is absent. If the > parameter is absent, the client is not following the TURN bis spec, and > the server is free to behave however it wants. That includes *wink wink* > being backward-compatible with TURN. > > This is exactly like the STUNv2 magic cookie: STUNv2 clients MUST send > the magic cookie, and STUNv2 server behaviour is defined when the cookie > is present. But STUNv2 does not specify server behaviour when the cookie > is absent. The cookie being absent means the client is not a STUNv2 > client. The server is free to behave however it wishes. That includes > *wink wink* being backward-compatible with STUNv1. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a113453ecf2962304f1d83aac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
OK, that's fine.

Oleg


On Fri, Feb 7, 201= 4 at 1:50 PM, Simon Perreault <simon.perreault@viagenie.ca&g= t; wrote:
Le 2014-02-07 16:19, Oleg Moskalenko a =E9cr= it :
> Well... OK. If we want the client always to send the= address-family -
> but we do not enforce that on the receiving side... that sounds
> awkward, =A0like a speed limit without cops. It is great - but does th= at
> strict requirement make sense without enforcement ? We can always say<= br> > that TURN client SHOULD send the address-family, but MUST probably wou= ld
> be too strict... I guess.

The idea is: first, we specify that TURN bis clients MUST send
REQUESTED-ADDRESS-FAMILY. Then we specify TURN bis server behaviour
depending on the value of REQUESTED-ADDRESS-FAMILY. We do *not* specify
TURN bis server behaviour when that parameter is absent. If the
parameter is absent, the client is not following the TURN bis spec, and
the server is free to behave however it wants. That includes *wink wink* being backward-compatible with TURN.

This is exactly like the STUNv2 magic cookie: STUNv2 clients MUST send
the magic cookie, and STUNv2 server behaviour is defined when the cookie is present. But STUNv2 does not specify server behaviour when the cookie is absent. The cookie being absent means the client is not a STUNv2
client. The server is free to behave however it wishes. That includes
*wink wink* being backward-compatible with STUNv1.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--001a113453ecf2962304f1d83aac-- From karl.stahl@intertex.se Sat Feb 8 05:11:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE451A02E0 for ; Sat, 8 Feb 2014 05:11:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.002 X-Spam-Level: * X-Spam-Status: No, score=1.002 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, NORMAL_HTTP_TO_IP=0.001] autolearn=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 2pLG4HWmasUr for ; Sat, 8 Feb 2014 05:11:26 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 61C801A02C3 for ; Sat, 8 Feb 2014 05:11:23 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402081411214695; Sat, 08 Feb 2014 14:11:21 +0100 From: "Karl Stahl" To: , , "'Simon Perreault'" References: <082c01cf17d4$393d7bb0$abb87310$@stahl@intertex.se> <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> Date: Sat, 8 Feb 2014 14:11:21 +0100 Message-ID: <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CE_01CF24D7.A4C3D5E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPF9Q95qa+X4Py7EuWLxLNWJ8IOJqSIuXQgBgX6oA= Content-Language: sv Subject: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 13:11:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02CE_01CF24D7.A4C3D5E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Karl from Ingate and Intertex just added himself to this list for = exactly the purpose of the subject of Milestone 3 above=20 =20 I welcome this initiative that I saw yesterday after being reminded by = China Mobile Research Institute who had seen the previous October = discussion on the WebRTC-list, parts of which are inserted below. Large = carriers have also expressed the importance of this milestone. -------------------- We are working on this draft, will publish it next week. -Tiru. =20 Great, please consider the input and suggestions below: =20 > -----Original Message----- > From: tram [ mailto:tram-bounces at ietf.org] On = Behalf Of Simon Perreault > Sent: Friday, February 07, 2014 7:58 PM > To: tram at ietf.org > Subject: [tram] Milestone 3: TURN server auto-discovery mechanism for > enterprise and ISPs >=20 =E2=80=A6 > Enterprises or ISPs wishing to provide > their own TURN server, in an attempt to reduce so-called "triangle = routing", > need a new auto-discovery mechanism. --- There are more reasons heard for auto-discovery of a network = provided TURN server: =20 - NSPs (Network Service Providers) want to provide a path where the = bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 - Note that to achieve some of the above points, TURN must be favored = over STUN to enforce that the TURN-path actually is used. (The Anycast = method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.)=20 =20 -- In my view, a TURN server is the network providers=E2=80=99 = responsibility to provide (just like the IP address, the default = gateway, the DNS etc.) =E2=80=93 rather than the application = provider=E2=80=99s. Our current Internet accesses may not cope with or = be optimized for WebRTC usage =E2=80=93 The NSP (or Enterprise LAN = administrator) should then be able to fix the access (here by offering a = TURN server).=20 =20 > IMHO this is also a top-priority milestone. We need to quickly have a > mechanism that people can implement in WebRTC browsers now, while > there is still frenetic development happening.=20 --- Agree I don't foresee actual server- > side deployment happening quickly though. But as soon as clients are = ready, > any ISP or enterprise can deploy and immediately benefit. - There is a definitive interest among forward SPs already, especially = carriers owning the network. (They have learned that their networks (especially mobile) seem to = become data crowded no matter how much bandwidth they invest in.) =20 > I imagine that the solution will be fairly simple, spec- and = implementation- > wise.=20 --- Agree that such solution should and could be found, but it is not = obvious. Below you find 3 proposals (initiated by me or colleagues, = where I see flaws in the two first and now only suggest the third (the = Anycast mechanism). From below: =20 - 1st: =E2=80=A6 withdraw my suggestion to use DHCP to find a network = provider offered TURN server in favor of the DNS-Based Service Discovery = method (inserted last below). The major problem with the DHCP usage was = that you then also have to do something similar for: RA - Router = Advertisement - in IPv6, addition to the IPCP protocol for PPPoE and = something for the mobile OTT channel =E2=80=93 wherever DHCP is NOT the = method to give you an IP address. (There were also concerns whether OSs = actually supports forwards such extended DHCP information for the = browser to use.) =20 - 2nd Reverse DNS-Based Service Discovery method: Justin Uberti pointed out: How does this get bootstrapped? That is, how = is the STUN server found? [Karl] Oops, that got lost when leaving the DHCP track, and is a problem = when using DNS discovery. (There were also hesitations of having to provision this special reverse = DNS for every access.) =20 - 3rd The Anycast method below =E2=80=93 I see no problem It also has the advantage of encouraging (but not requiring) the = STUN/TURN to be built in the default gateway or NAT/firewall/access = router itself, with a second interface to a public IP address on the WAN = side. (Current volume deployed, low cost NSP triple play modems usually = have a quality assured level 2 or level 3 WAN pipe for just voice (and = another for IPTV) =E2=80=93 The anycast discovered TURN-server can be = the access gateway to such quality pipe for WebRTC media, in a single = NSP provided CPE, scaling from residential and up.) =20 So I think we can finish this very quickly once we have a candidate > draft. We just need authors. So I would target not long after Toronto. >=20 > Simon =20 WEB BROWSER BEHAVIOUR: =20 Network provided TURN servers will not appear over night, applications = may for long provide a TURN server address, and there are exceptions = where the TURN server address is preferred to be = =E2=80=9Cmanually=E2=80=9D configured. It is previously suggested, and = to some extent discussed, that the WebRTC browser should select the TURN = server to use in the following priority order, where ICE would assure = that you get some connectivity if several candidates are found and needs = to be tested: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing) 2) TURN server address configured by the network administrator via an = =E2=80=9Cadmin policy template=E2=80=9D or a WPAD method as mentioned = below 3) TURN server address auto-discovered by the mechanism discussed here 4) TURN server address being supplied by the web application =20 With a good step 3), step 2) becomes obsolete since the network = administrator e.g. simply can set a route in the enterprise firewall to = use the Anycast mechanism instead.=20 =20 Even if the need for auto-discovery of the TURN server comes from WebRTC = usage, a general mechanism that also can be used by SIP clients (and = other protocols using TURN via ICE) is preferable. The anycast method = has no application dependence, but e.g. WPAD has (a SIP Client typically = does not have the luxury of a JS engine=E2=80=A6) =20 /Karl =20 =20 Fr=C3=A5n: Karl Stahl [ = mailto:karl.stahl@intertex.se]=20 Skickat: den 22 oktober 2013 16:37 Till: 'Justin Uberti'; 'Cullen Jennings (fluffy)' Kopia: 'Bernard Aboba'; 'Harald Alvestrand'; = 'draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org'; = 'rtcweb@ietf.org' =C3=84mne: [rtcweb] [mmusic] Anycast discovery, Was TURN server address = via DHCP, WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 See my comments below. The problem of having to know a first STUN server = in order to use DNS discovery, makes the suggestions below less good. =20 Another idea came up; to use anycast to allow a WebRTC browser to find a = network provided TURN server (both local on a LAN or provided by a = carrier). (There are some discussion around using anycast in the STUN = and TURN RFCs.) This anycast-way should work both for a TURN server on a = LAN and a TURN server outside the NAT/Firewall (any router in the chain = can take care of an anycast address) and by the simple method below, = return the available TURN server closest to the client. Finding a TURN = server close to the client (the WebRTC browser) will also minimize = =E2=80=9Cthe turn=E2=80=9D the real-time traffic has to take. =20 =20 The suggestion is to define an anycast IP address for STUN servers and: - The network provider, offering a TURN server on his access, adds a = route in his access router (or NAT/Firewall) so that the anycast address = routes to his TURN/STUN server (a TURN server is an extension of STUN = server, thus included in the same box). - The TURN/STUN server is configured to respond to a binding request = with a =E2=80=9C300 Try alternate server=E2=80=9D, that points out the = same TURN/STUN server (by its real IP address, not the anycast address). =20 The WebRTC browser client would then: - Issue a STUN binding request to the anycast address - Issue another STUN binding request to the ALTERNATE SERVER IP address = in the =E2=80=9C300 Try alternate=E2=80=9D response (as any client = should do).=20 - Interpret the received =E2=80=9C300 Try alternate=E2=80=9D response = now having the same ALTERNATE SERVER IP address as the source IP address = of that response, as an indication to use its TURN server (not the STUN = server) at that address.=20 =20 That is the TURN server to use! =20 The only addition to existing standards is the interpretation above of = the =E2=80=9C300 Try alternate=E2=80=9D response in the STUN RCF 5766 = having the same ALTERNATE SERVER IP address as the source IP address of = the response. It means: Use the TURN server at the specified address. = That should be easy to clarify. (The STUN server at the anycast address, may or may not be the same = TURN/STUN server used in second binding request.)=20 =20 Authentication could simply be that the TURN/STUN server only is = reachable from the IP addresses that the network provider want to = support with the TURN server (easy for the network provider, since he is = handing out those IP addresses). =20 This should be easy to provision for a carrier or a LAN administrator = and trivial to try for the WebRTC browser. =20 An advantage is that the two STUN binding requests directly returns the = TURN server address, whereby the following ICE process should be quick = and easy. This could also be done only once when the browser is started = or get a new IP address and cashed for later calls. =20 /Karl =20 PS If you wonder why not define an anycast address for a TURN server = instead, read this thread from 2008: = = http://www.ietf.org/mail-archive/web/behave/current/msg03582.html. = There, the use of anycast to a TURN server is discussed, but found not = to work. (Here anycast is only used for the first request to the STUN = server, where after the real address to the TURN/STUN server is used.) =20 =20 =20 Fr=C3=A5n: Justin Uberti [ = mailto:juberti@google.com]=20 Skickat: den 8 oktober 2013 08:17 Till: Karl Stahl Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy); = = draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org; = rtcweb@ietf.org =C3=84mne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11 =20 =20 On Mon, Oct 7, 2013 at 6:21 AM, Karl Stahl < = karl.stahl@intertex.se> wrote: So the WPAD-way of getting a network provider=E2=80=99s TURN server = address for the real (white, global) IP address he has handed out to a = user, the browser would: - Use STUN to find the global IP address (done anyway in ICE) =20 How does this get bootstrapped? That is, how is the STUN server found? [Karl] Oops, that got lost when leaving the DHCP track, and is a problem = when using DNS discovery. =20 - Do a reverse DNS lookup (instead of the DNS-Based Service Discovery = that is not yet deployed) - Make a URL based on the hostname from the reverse DNS lookup, e.g. = from 179.sub-174-252-35.myvzw.com, make h ttp://turnad.myvzw.com =20 I was hoping we could do something simpler, such as using the ISP's = configured domain search list, to determine the domain. [Karl] But carriers don=E2=80=99t push out such things, do they? And if = they could do it via DHCP we are back with those problems again. - And there find a list (in JS) of TURN server addresses for the network = provider=E2=80=99s IP addresses Or would an alternative be to add your own IP address to the URL and = get only your specific TURN server address? =20 Doing it at this Web level, I think we also should consider clients = using ICE/TURN, but not having the luxury of a JS engine: Would e.g. a = SIP client be able to parse a =E2=80=9CJS table=E2=80=9D to find his = TURN server address easily? Also, are there long time-outs to be = considered when there is no h ttp://turned.myvzw.com to be found? =20 This method may be easier for a network provider to deploy (I = don=E2=80=99t know, but for local use on a LAN I guess it is). On the = other hand, the DNS-Based Service Discovery method is quick and easy for = a WebRTC browser, so that may be tried as well. =20 Independent of how we find the network provided TURN server, one = advantage with it is the authentication: The network provider simply = sets up the TURN for usage from the IP addresses he has handed out. =20 /Karl =20 Fr=C3=A5n: Justin Uberti [mailto: = juberti@google.com]=20 Skickat: den 3 oktober 2013 20:59 Till: Karl Stahl Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings (fluffy); = = draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org; = rtcweb@ietf.org =C3=84mne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11 =20 WPAD already supports DNS-based discovery (in addition to DHCP). If you = have = host-95-199-196-65.mobileonline.telia.com as your endpoint hostname, it = will try to get a PAC file from = wpad.mobileonline.telia.com. =20 Since for all practical purposes, TURN is a "UDP proxy", I think it = should be handled similar to other proxy autoconfig mechanisms. =20 On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl < = karl.stahl@intertex.se> wrote: I happily withdraw my suggestion to use DHCP to find a network provider = offered TURN server in favor of the DNS-Based Service Discovery method = (inserted last below). The major problem with the DHCP usage was that = you then also have to do something similar for: RA - Router = Advertisement - in IPv6, addition to the IPCP protocol for PPPoE and = something for the mobile OTT channel =E2=80=93 wherever DHCP is NOT the = method to give you an IP address. =20 Further: > On Thu, Sep 27, 2013 Justin Uberti wrote: > Agree. I still think that extending PAC files to include TURN = information is the right way to go. > PAC files can already be discovered via DHCP or DNS, there is no need = to reinvent this wheel. =20 >>On Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) < = fluffy@cisco.com> wrote: >>I think we need to give some advise to the browsers vendors on what = they should implement to find turn servers =20 I Googled a bit on PAC and WPAD and saw that a HTTP proxy config JS file = can be picked up through a URL based on the device name. Similar could = work for finding a TURN server on a LAN, but what about the case with a = network provider offered TURN server? The network provider hands out an = IP address and wants to announce a related TURN server address: = =E2=80=93 Is there a =E2=80=9CPAC-way=E2=80=9D to announce it to a = device on a LAN (behind a NAT/firewall)? The device must find such = configuration file based on its public IP address (that he can find = using STUN as in the suggestion below). =20 But generally, finding a TURN-server is a network-thing, ICE (or even = TURN not using ICE), not a Web-thing, so for that reason the DNS-Based = Service Discovery method is at a better level. Such method could also be = used by SIP clients (even a Skype client could implement it to benefit = from a real-time path with better quality, if the network provider = offers such path through his TURN server). =20 The DNS-Based Service Discovery method should be easy to implement in a = WebRTC browser (doing complex ICE things anyway). The question is rather = how easy it is for the network provider to provision. Do they all do = reverse DNS like with found with mobile operators TeliaSonera and Tele2 = in Sweden? Then it should not be too difficult. =20 Or is there yet another better method to announce a TURN server address = with the IP address offered? =20 /Karl =20 =20 Fr=C3=A5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] = F=C3=B6r Bernard Aboba Skickat: den 29 september 2013 02:41 Till: Harald Alvestrand Kopia: rtcweb@ietf.org =C3=84mne: Re: [rtcweb] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11 =20 On Sep 26, 2013 8:46 PM, "Harald Alvestrand" < = harald@alvestrand.no> wrote: "So far, neither the POSIX standard nor any OS vendor has offered a = generic facility to access information made available in DHCP packets." =20 [BA] The Windows DHCP client API does provide this:=20 = = http://msdn.microsoft.com/en-us/library/windows/desktop/aa363351(v=3Dvs.8= 5).aspx =20 In particular, the SendParams argument to the DhcpRequestParams function = can be used to request a particular parameter (e.g. TURN server = address), which will then be returned in the RecdParams variable. =20 =20 Nevertheless, I still think that using DHCP to configure the TURN server = address in a browser isn't a good idea. For one thing, since DHCP is = effectively unsecured, this mechanism could be used by a rogue DHCP = server to force traffic to a rogue turnserver. Great for surveillance! =20 =20 On Sep 27, 2013 1:27 AM, "Karl Stahl" < = karl.stahl@intertex.se> wrote: Here comes the suggestion I got from my developer that would allow a = network provider to offer his TURN server for the WebRTC browser to use. This = would require NO new DHCP-options or similar, and NO OS changes (I do realize those should be avoided if possible...). The idea is still, that whoever is responsible for giving a device an IP address (the network provider or a LAN administrator) can also announce = a TURN server for the WebRTC browser to use. The suggestion is to use RFC6763 (DNS-Based Service Discovery, see = chapter 11) where the network provider (the owner of the IP address) has set up = a DNS PTR record for the TURN server in the in-addr.arpa domain. If the device got IP 173.164.252.149, then make a query for the PTR = record for: _turn._udp.149.252.164.173.in-addr.arpa. Then the SRV record would return the actual address to the TURN server = (and you may find several for load balancing and failover I guess) If the device is on a LAN, the IP 173.164.252.149 to query would be the = WAN IP you get via STUN in the ICE process. But if the LAN administrator provides a local TURN server, then he also should have blocked STUN in = the firewall, and the browser should query the device's local host address = (as in the ICE procedure) and the local LAN DNS server should answer the = query to give the local TURN server address on the LAN. Shouldn't this work to allow network provider to offer his TURN server "automatically and generally"? And wouldn't this work nicely for mobile devices, whenever the device is = on a "WebRTC-ready access" (actually good for everything using ICE), = whether fixed, WiFi or 3G/4G OTT, you get also a TURN server (and the network provider hopefully offers a prioritized pipe there as one usage of this mechanism). Not to slow down every call setup by doing this in the ICE process, I = guess this could be done when starting the browser and when the device gets a = new IP address, to have the TURN server address ready for later use. /Karl =20 =20 ------=_NextPart_000_02CE_01CF24D7.A4C3D5E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Ka= rl from Ingate and Intertex just added himself to this list for exactly = the purpose of the subject of Milestone 3 above

 

I = welcome this initiative that I saw yesterday after being reminded by = China Mobile Research Institute who had seen the previous October = discussion on the WebRTC-list, parts of which are inserted below. Large = carriers have also expressed the importance of this = milestone.

--= ------------------

We are = working on this draft, will publish it next = week.

-Tiru.

 

Great, please = consider the input and suggestions below:

 

> = -----Original Message-----

> From: tram = [mailto:tram-bounces at ietf.org] On = Behalf Of Simon Perreault

> Sent: Friday, = February 07, 2014 7:58 PM

> To: tram at = ietf.org

> Subject: = [tram] Milestone 3: TURN server auto-discovery mechanism = for

> enterprise and = ISPs

> =

=E2=80=A6

> = Enterprises or ISPs wishing to provide

> their own TURN = server, in an attempt to reduce so-called "triangle = routing",

> = need a new auto-discovery mechanism.

--= - There are more reasons heard for auto-discovery of a network provided = TURN server:

 

- = NSPs (Network Service Providers) want to provide a path where the = bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic. =

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

 

- = Note that to achieve some of the above points, TURN must be favored over = STUN to enforce that the TURN-path actually is used. (The Anycast method = suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) =

 

--= In my view, a TURN server is the network providers=E2=80=99 = responsibility to provide (just like the IP address, the default = gateway, the DNS etc.) =E2=80=93 rather than the application = provider=E2=80=99s. Our current Internet accesses may not cope with or = be optimized for WebRTC usage =E2=80=93 The NSP (or Enterprise LAN = administrator) should then be able to fix the access (here by offering a = TURN server).

 

> = IMHO this is also a top-priority milestone. We need to quickly have = a

> mechanism that = people can implement in WebRTC browsers now, = while

> there is still = frenetic development happening.

--= - Agree

I don't foresee = actual server-

> = side deployment happening quickly though. But as soon as clients are = ready,

> any ISP or = enterprise can deploy and immediately benefit.

- = There is a definitive interest among forward SPs already, especially = carriers owning the network.

(T= hey have learned that their networks (especially mobile) seem to become = data crowded no matter how much bandwidth they invest in.)

 

> I = imagine that the solution will be fairly simple, spec- and = implementation-

> = wise.

--= - Agree that such solution should and could be found, but it is not = obvious. Below you find 3 proposals (initiated by me or colleagues, = where I see flaws in the two first and now only suggest the third (the = Anycast mechanism). From below:

 

- = 1st: =E2=80=A6 withdraw my suggestion to use DHCP to find a = network provider offered TURN server in favor of the DNS-Based Service = Discovery method (inserted last below). The major problem with the DHCP = usage was that you then also have to do something similar for: RA - = Router Advertisement - in IPv6, addition to the IPCP protocol for PPPoE = and something for the mobile OTT channel =E2=80=93 wherever DHCP is NOT = the method to give you an IP address. (There were also concerns whether = OSs actually supports forwards such extended DHCP information for the = browser to use.)

 

- = 2nd Reverse DNS-Based Service Discovery = method:

Ju= stin Uberti pointed out: =C2=A0How does this = get bootstrapped? That is, how is the STUN server = found?

[K= arl] Oops, that got lost when leaving the DHCP track, and is a problem = when using DNS discovery.

(T= here were also hesitations of having to provision this special reverse = DNS for every access.)

 

- = 3rd The Anycast method below =E2=80=93 I see no = problem

It= also has the advantage of encouraging (but not requiring) the STUN/TURN = to be built in the default gateway or NAT/firewall/access router itself, = with a second interface to a public IP address on the WAN side. (Current = volume deployed, low cost NSP triple play modems usually have a quality = assured level 2 or level 3 WAN pipe for just voice (and another for = IPTV) =E2=80=93 The anycast discovered TURN-server can be the access = gateway to such quality pipe for WebRTC media, in a single NSP provided = CPE, scaling from residential and up.)

 

So I = think we can finish this very quickly once we have a = candidate

> draft. We just = need authors. So I would target not long after = Toronto.

> =

> = Simon

 

WE= B BROWSER BEHAVIOUR:

 

Ne= twork provided TURN servers will not appear over night, applications may = for long provide a TURN server address, and there are exceptions where = the TURN server address is preferred to be =E2=80=9Cmanually=E2=80=9D = configured. It is previously suggested, and to some extent discussed, = that the WebRTC browser should select the TURN server to use in the = following priority order, where ICE would assure that you get some = connectivity if several candidates are found and needs to be = tested:

 

1)= TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing)

2)= TURN server address configured by the network administrator via an = =E2=80=9Cadmin policy template=E2=80=9D or a WPAD method as mentioned = below

3)= TURN server address auto-discovered by the mechanism discussed = here

4)= TURN server address being supplied by the web = application

 

Wi= th a good step 3), step 2) becomes obsolete since the network = administrator e.g. simply can set a route in the enterprise firewall to = use the Anycast mechanism instead.

 

Ev= en if the need for auto-discovery of the TURN server comes from WebRTC = usage, a general mechanism that also can be used by SIP clients (and = other protocols using TURN via ICE) is preferable. The anycast method = has no application dependence, but e.g. WPAD has (a SIP Client typically = does not have the luxury of a JS = engine=E2=80=A6)

 

/K= arl

 

 

Fr=C3=A5n: Karl Stahl = [mailto:karl.stahl@intertex.se] =
Skickat: den 22 oktober 2013 16:37
Till: 'Justin = Uberti'; 'Cullen Jennings (fluffy)'
Kopia: 'Bernard Aboba'; = 'Harald Alvestrand'; = 'draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org'; = 'rtcweb@ietf.org'
=C3=84mne: [rtcweb] [mmusic] Anycast = discovery, Was TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

Se= e my comments below. The problem of having to know a first STUN server = in order to use DNS discovery, makes the suggestions below less = good.

 

An= other idea came up; to use anycast to allow a WebRTC browser to find a = network provided TURN server (both local on a LAN or provided by a = carrier). (There are some discussion around using anycast in the STUN = and TURN RFCs.) This anycast-way should work both for a TURN server on a = LAN and a TURN server outside the NAT/Firewall (any router in the chain = can take care of an anycast address) and by the simple method below, = return the available TURN server closest to the client. Finding a TURN = server close to the client (the WebRTC browser) will also minimize = =E2=80=9Cthe turn=E2=80=9D the real-time traffic has to take.  =

 

Th= e suggestion is to define an anycast IP address for STUN servers = and:

- = The network provider, offering a TURN server on his access, adds a route = in his access router (or NAT/Firewall) so that the anycast address = routes to his TURN/STUN server (a TURN server is an extension of STUN = server, thus included in the same box).

- = The TURN/STUN server is configured to respond to a binding request with = a =E2=80=9C300 Try alternate server=E2=80=9D, that points out the same = TURN/STUN server (by its real IP address, not the anycast = address).

 

Th= e WebRTC browser client would then:

- = Issue a STUN binding request to the anycast = address

- = Issue another STUN binding request to the ALTERNATE SERVER IP address in = the =E2=80=9C300 Try alternate=E2=80=9D response (as any client should = do).

- = Interpret the received =E2=80=9C300 Try alternate=E2=80=9D response now = having the same ALTERNATE SERVER IP address as the source IP address of = that response, as an indication to use its TURN server (not the STUN = server) at that address.

 

Th= at is the TURN server to use!

 

Th= e only addition to existing standards is the interpretation above of the = =E2=80=9C300 Try alternate=E2=80=9D response in the STUN RCF 5766 having = the same ALTERNATE SERVER IP address as the source IP address of the = response. It means: Use the TURN server at the specified address. That = should be easy to clarify.

(T= he STUN server at the anycast address, may or may not be the same = TURN/STUN server used in second binding request.) =

 

Au= thentication could simply be that the TURN/STUN server only is reachable = from the IP addresses that the network provider want to support with the = TURN server (easy for the network provider, since he is handing out = those IP addresses).

 

Th= is should be easy to provision for a carrier or a LAN administrator and = trivial to try for the WebRTC browser.

 

An= advantage is that the two STUN binding requests directly returns the = TURN server address, whereby the following ICE process should be quick = and easy. This could also be done only once when the browser is started = or get a new IP address and cashed for later = calls.

 

/K= arl

 

PS= If you wonder why not define an anycast address for a TURN server = instead, read this thread from 2008:  http://www.ietf.org/mail-archive/web/behave/current/msg03582= .html. There, the use of anycast to a TURN server is = discussed, but found not to work. (Here anycast is only used for the = first request to the STUN server, where after the real address to the = TURN/STUN server is used.)

 

 

 

Fr=C3=A5n: Justin = Uberti [mailto:juberti@google.com] =
Skickat: den 8 oktober 2013 08:17
Till: Karl = Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings = (fluffy); draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org<= /span>; = rtcweb@ietf.org
=C3=84= mne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

 

On = Mon, Oct 7, 2013 at 6:21 AM, Karl Stahl <karl.stahl@intertex.se> = wrote:

So= the WPAD-way of getting a network provider=E2=80=99s TURN server = address for the real (white, global) IP address he has handed out to a = user, the browser would:

- = Use STUN to find the global IP address (done anyway in ICE)

 

How does this get bootstrapped? = That is, how is the STUN server found?

[K= arl] Oops, that got lost when leaving the DHCP track, and is a problem = when using DNS discovery.

 

- = Do a reverse DNS lookup (instead of the DNS-Based Service Discovery that = is not yet deployed)

- = Make a URL based on the hostname from the reverse DNS lookup, e.g. from = 179.sub-174-252-35.myvzw.com, make h ttp://turnad.myvzw.com

 

I was hoping we could do something = simpler, such as using the ISP's configured domain search list, to = determine the domain.

 [Karl] But carriers don=E2=80=99t push out such = things, do they? And if they could do it via DHCP we are back with those = problems again.

- = And there find a list (in JS) of TURN server addresses for the network = provider=E2=80=99s IP addresses

&n= bsp;Or would an alternative be to add your own IP address to the URL and = get only your specific TURN server address?

&n= bsp;

Do= ing it at this Web level, I think we also should consider clients using = ICE/TURN, but not having the luxury of a JS engine: Would e.g. a SIP = client be able to parse a =E2=80=9CJS table=E2=80=9D to find his TURN = server address easily? Also, are there long time-outs to be considered = when there is no h ttp://turned.myvzw.com to be found?

&n= bsp;

Th= is method may be easier for a network provider to deploy (I = don=E2=80=99t know, but for local use on a LAN I guess it is). On the = other hand, the DNS-Based Service Discovery method is quick and easy for = a WebRTC browser, so that may be tried as well.

&n= bsp;

In= dependent of how we find the network provided TURN server, one advantage = with it is the authentication: The network provider simply sets up the = TURN for usage from the IP addresses he has handed out.

&n= bsp;

/K= arl

&n= bsp;

Fr=C3=A5n: Justin = Uberti [mailto:juberti@google.com] =
Skickat: den 3 oktober 2013 20:59
Till: Karl = Stahl
Kopia: Bernard Aboba; Harald Alvestrand; Cullen Jennings = (fluffy); draft-ietf-rtcweb-use-cases-and-requirements@tools.ietf.org<= /span>; = rtcweb@ietf.org
=C3=84= mne: Re: [rtcweb] [mmusic] TURN server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

WPAD already supports DNS-based discovery (in addition to = DHCP). If you have host-95-199-1= 96-65.mobileonline.telia.com as your = endpoint hostname, it will try to get a PAC file from wpad.mobileonline.telia.com.

 

Since for all practical purposes, TURN is a "UDP = proxy", I think it should be handled similar to other proxy = autoconfig mechanisms.

 

On Mon, Sep 30, 2013 at 5:13 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

I happily = withdraw my suggestion to use DHCP to find a network provider offered = TURN server in favor of the DNS-Based Service Discovery method (inserted = last below). The major problem with the DHCP usage was that you then = also have to do something similar for: RA - Router Advertisement - in = IPv6, addition to the IPCP protocol for PPPoE and something for the = mobile OTT channel =E2=80=93 wherever DHCP is NOT the method to give you = an IP address.

 

Further:

> On Thu, = Sep 27, 2013 Justin Uberti wrote:

> Agree. I = still think that extending PAC files to include TURN information is the = right way to go.

> PAC files = can already be discovered via DHCP or DNS, there is no need to reinvent = this wheel.

 

>>On = Thu, Sep 26, 2013 at 4:55 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

>>I = think we need to give some advise to the browsers vendors on what they = should implement to find turn servers

 

I Googled a = bit on PAC and WPAD and saw that a HTTP proxy config JS file can be = picked up through a URL based on the device name. Similar could work for = finding a TURN server on a LAN, but what about the case with a network = provider offered TURN server? The network provider hands out an IP = address and wants to announce a related TURN server address: =E2=80=93 = Is there a =E2=80=9CPAC-way=E2=80=9D to announce it to a device on a LAN = (behind a NAT/firewall)? The device must find such configuration file = based on its public IP address (that he can find using STUN as in the = suggestion below).

 

But generally, = finding a TURN-server is a network-thing, ICE (or even TURN not using = ICE), not a Web-thing, so for that reason the DNS-Based Service = Discovery method is at a better level. Such method could also be used by = SIP clients (even a Skype client could implement it to benefit from a = real-time path with better quality, if the network provider offers such = path through his TURN server).

 

The DNS-Based = Service Discovery method should be easy to implement in a WebRTC browser = (doing complex ICE things anyway). The question is rather how easy it is = for the network provider to provision. Do they all do reverse DNS like = with found with mobile operators TeliaSonera and Tele2 in Sweden? Then = it should not be too difficult.

 

Or is there = yet another better method to announce a TURN server address with the IP = address offered?

 

/Karl

<= p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&n= bsp;

&n= bsp;

Fr=C3=A5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=C3=B6r Bernard = Aboba
Skickat: den 29 september 2013 02:41
Till: = Harald Alvestrand
Kopia: rtcweb@ietf.org


=C3=84mne: Re: [rtcweb] TURN = server address via DHCP, WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On Sep 26, = 2013 8:46 PM, "Harald Alvestrand" <harald@alvestrand.no> wrote:


"So far, neither the POSIX standard nor any OS = vendor has offered a generic facility to access information made = available in DHCP = packets."

 

[BA] The = Windows DHCP client API does provide this: 

http://msdn.microsoft.com/en-us/library/windows/desktop/aa36= 3351(v=3Dvs.85).aspx

 

In particular, = the SendParams argument to the DhcpRequestParams function can be = used to request a particular parameter (e.g. TURN server address), which = will then be returned in the RecdParams variable.  

 

Nevertheless, = I still think that using DHCP to configure the TURN server address in a = browser isn't a good idea.  For one thing, since DHCP is = effectively unsecured, this mechanism could be used by a rogue DHCP = server to force traffic to a rogue turnserver.   Great for = surveillance!

&n= bsp;

&n= bsp;

On Sep 27, 2013 1:27 AM, "Karl Stahl" = <karl.stahl@intertex.se> = wrote:

Here comes the suggestion I got from my developer that = would allow a network
provider to offer his TURN server for the = WebRTC browser to use. This would
require NO new DHCP-options or = similar, and NO OS changes (I do realize
those should be avoided if = possible...).

The idea is still, that whoever is responsible for = giving a device an IP
address (the network provider or a LAN = administrator) can also announce a
TURN server for the WebRTC browser = to use.

The suggestion is to use RFC6763 (DNS-Based Service = Discovery, see chapter
11) where the network provider (the owner of = the IP address) has set up a
DNS PTR record for the TURN server in = the in-addr.arpa domain.

If the device got IP 173.164.252.149, = then make a query for the PTR = record
for:
_turn._udp.149.252.164.173.in-addr.arpa.
Then the = SRV record would return the actual address to the TURN server = (and
you may find several for load balancing and failover I = guess)

If the device is on a LAN, the IP 173.164.252.149 to query = would be the WAN
IP you get via STUN in the ICE process. But if the = LAN administrator
provides a local TURN server, then he also should = have blocked STUN in the
firewall, and the browser should query the = device's local host address (as
in the ICE procedure) and the local = LAN DNS server should answer the query
to give the local TURN server = address on the LAN.

Shouldn't this work to allow network provider = to offer his TURN server
"automatically and = generally"?

And wouldn't this work nicely for mobile = devices, whenever the device is on
a "WebRTC-ready access" = (actually good for everything using ICE), whether
fixed, WiFi or = 3G/4G OTT, you get also a TURN server (and the network
provider = hopefully offers a prioritized pipe there as one usage of = this
mechanism).

Not to slow down every call setup by doing this in the ICE = process, I guess
this could be done when starting the browser and = when the device gets a new
IP address, to have the TURN server = address ready for later use.

/Karl

 <= /o:p>

 

------=_NextPart_000_02CE_01CF24D7.A4C3D5E0-- From pkyzivat@alum.mit.edu Sun Feb 9 10:24:51 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BF31A03B2 for ; Sun, 9 Feb 2014 10:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 bdSlTtPoa3BY for ; Sun, 9 Feb 2014 10:24:49 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id A17461A0433 for ; Sun, 9 Feb 2014 10:24:40 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta09.westchester.pa.mail.comcast.net with comcast id QHDJ1n00516LCl059JQghs; Sun, 09 Feb 2014 18:24:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id QJQf1n00L3ZTu2S3SJQflK; Sun, 09 Feb 2014 18:24:40 +0000 Message-ID: <52F7C7E7.7050005@alum.mit.edu> Date: Sun, 09 Feb 2014 13:24:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <52F54CDC.1040502@viagenie.ca> <52F5550D.3020203@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391970280; bh=FsWt9A3wsnI3yyl7t+Zwc1j9HW8a4lXN3nItBBgmptM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Nig8mfCqjNWq6dpdXFn+3UT9ME5rDcMHOFC8zbqM8lV4lA9oWvwtX7WyS5ugJLnt8 cxC7G68GbLuLcgCVgZD82c/Zo5KCMHwQQGA4LXuFIb103pAYYrRpaiObECmBbvdIO2 jW7aa6axl5bQe1VoKTpMTO5mzh7iprgLjagy1IiTfEzty/WwpQxPEvEBY1hFiRO47H IPpMH9r5fQ7UQUW3aHBmofKWwEQGrOVfrAOvFnHphs9tpUV4LOsE4f2hjUc0xei5E5 LFMD43O8W9yci9hDIFI+5rJA8OKW/Oust33NudhlkYUrp31An0pOLoYM36d4jAaHp8 y5keXVIA6XhbA== Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 18:24:51 -0000 Shouldn't backward compatibility of TURN-bis servers with TURN clients be *mandatory*, rather than optional? Thanks, Paul On 2/7/14 5:08 PM, Oleg Moskalenko wrote: > OK, that's fine. > > Oleg > > > On Fri, Feb 7, 2014 at 1:50 PM, Simon Perreault > > wrote: > > Le 2014-02-07 16:19, Oleg Moskalenko a écrit : > > Well... OK. If we want the client always to send the address-family - > > but we do not enforce that on the receiving side... that sounds > > awkward, like a speed limit without cops. It is great - but does > that > > strict requirement make sense without enforcement ? We can always say > > that TURN client SHOULD send the address-family, but MUST > probably would > > be too strict... I guess. > > The idea is: first, we specify that TURN bis clients MUST send > REQUESTED-ADDRESS-FAMILY. Then we specify TURN bis server behaviour > depending on the value of REQUESTED-ADDRESS-FAMILY. We do *not* specify > TURN bis server behaviour when that parameter is absent. If the > parameter is absent, the client is not following the TURN bis spec, and > the server is free to behave however it wants. That includes *wink wink* > being backward-compatible with TURN. > > This is exactly like the STUNv2 magic cookie: STUNv2 clients MUST send > the magic cookie, and STUNv2 server behaviour is defined when the cookie > is present. But STUNv2 does not specify server behaviour when the cookie > is absent. The cookie being absent means the client is not a STUNv2 > client. The server is free to behave however it wishes. That includes > *wink wink* being backward-compatible with STUNv1. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From mom040267@gmail.com Sun Feb 9 16:15:16 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95611A0628 for ; Sun, 9 Feb 2014 16:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 PeZGQTkG1jQb for ; Sun, 9 Feb 2014 16:15:14 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 10E7C1A061B for ; Sun, 9 Feb 2014 16:15:14 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id y10so5338410pdj.26 for ; Sun, 09 Feb 2014 16:15:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZlaKHsmHCuCoHZz1zb/vrz9BAzTYcfX3SylYqcjft3g=; b=rdAzBJ0ot1t+CyNy4/SQPxhvcgcVbmvw/k6o3Boxa/kiO9v97tT5QGAdLLAIbnVW/k ztxIVCH/iLZIf0UH/ZY2sjK9UI5iKOGvKnmqQVjHALEX7xDI8aNWjlsLQRii9IdjNeJ3 HKutHDiy+Ln9sk6qkqshJ+Qn9Zgb08hXEiTy1yuMCANiVHE7Qvq7X59ujnqGMbXK2E7T IN1t3rqHSZFILR0uUpfoKOqnCYenY4eqgvVRbTDwGKGmmP2zjX0EjiNJMG+1yVnOSpV7 gLx//LqQ8X46hWMZy4M6dlfvu3v63l04/3sxxYZAHyGZyH3To3OG5XBn09n5hbGiaImv ulZQ== MIME-Version: 1.0 X-Received: by 10.68.226.70 with SMTP id rq6mr34334022pbc.107.1391991314212; Sun, 09 Feb 2014 16:15:14 -0800 (PST) Received: by 10.68.147.131 with HTTP; Sun, 9 Feb 2014 16:15:14 -0800 (PST) In-Reply-To: <52F7C7E7.7050005@alum.mit.edu> References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <52F54CDC.1040502@viagenie.ca> <52F5550D.3020203@viagenie.ca> <52F7C7E7.7050005@alum.mit.edu> Date: Sun, 9 Feb 2014 16:15:14 -0800 Message-ID: From: Oleg Moskalenko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e89a8ff24355d06df404f2023bb8 Cc: "tram@ietf.org" Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 00:15:17 -0000 --e89a8ff24355d06df404f2023bb8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not sure whether we want a very strict language here. This is about how the TURN server will react in case of missed REQUESTED-TRANSPORT attribute. There may be three ways to react: 1) Respond with IPv4 relay endpoint (the current TURN way of doing things); 2) Reject the request (strict enforcement of REQUESTED-TRANSPORT attribute)= ; 3) Respond with IPv6 relay endpoint (may make sense in some networks with heavy IPv6 infestation, like mobile networks). The new standard (TURN-bis) may have three options for the TURN server: 1) Keep the 1st way (as in current TURN) as backward-compatible solution; 2) Require that the client always includes that attribute and the TURN server rejects the request if not; 3) Make the behavior undefined (as Simon suggests). 4) Make the behavior configurable. I can see a sense in options 1 and 3. The first option is 100% backward-compatible and that's good. The third option allows legacy TURN clients in networks where IPv6 is the default protocol (if the legacy client is IPv6 - aware) and leaves the decision to the TURN server administrator or implementation. I am not sure about the fourth option - it may impose unnecessary complication on the implementation. But I am against the option 2. It is too harsh and it introduces mandatory backward incompatibility. Oleg On Sun, Feb 9, 2014 at 10:24 AM, Paul Kyzivat wrote= : > Shouldn't backward compatibility of TURN-bis servers with TURN clients be > *mandatory*, rather than optional? > > Thanks, > Paul > > > On 2/7/14 5:08 PM, Oleg Moskalenko wrote: > >> OK, that's fine. >> >> Oleg >> >> >> On Fri, Feb 7, 2014 at 1:50 PM, Simon Perreault >> > wrote= : >> >> Le 2014-02-07 16:19, Oleg Moskalenko a =E9crit : >> > Well... OK. If we want the client always to send the >> address-family - >> > but we do not enforce that on the receiving side... that sounds >> > awkward, like a speed limit without cops. It is great - but does >> that >> > strict requirement make sense without enforcement ? We can always >> say >> > that TURN client SHOULD send the address-family, but MUST >> probably would >> > be too strict... I guess. >> >> The idea is: first, we specify that TURN bis clients MUST send >> REQUESTED-ADDRESS-FAMILY. Then we specify TURN bis server behaviour >> depending on the value of REQUESTED-ADDRESS-FAMILY. We do *not* >> specify >> TURN bis server behaviour when that parameter is absent. If the >> parameter is absent, the client is not following the TURN bis spec, >> and >> the server is free to behave however it wants. That includes *wink >> wink* >> being backward-compatible with TURN. >> >> This is exactly like the STUNv2 magic cookie: STUNv2 clients MUST se= nd >> the magic cookie, and STUNv2 server behaviour is defined when the >> cookie >> is present. But STUNv2 does not specify server behaviour when the >> cookie >> is absent. The cookie being absent means the client is not a STUNv2 >> client. The server is free to behave however it wishes. That include= s >> *wink wink* being backward-compatible with STUNv1. >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> >> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --e89a8ff24355d06df404f2023bb8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I a= m not sure whether we want a very strict language here.

This i= s about how the TURN server will react in case of missed REQUESTED-TRANSPOR= T attribute. There may be three ways to react:

1) Respond with IPv4 relay endpoint (the current TURN way of doin= g things);
2) Reject the request (strict enforcement of REQUESTED-= TRANSPORT attribute);
3) Respond with IPv6 relay endpoint (may mak= e sense in some networks with heavy IPv6 infestation, like mobile networks)= .

The new standard (TURN-bis) may have three options for the TURN s= erver:

1) Keep the 1st way (as in current TURN) as backward-co= mpatible solution;
2) Require that the client always includes that= attribute and the TURN server rejects the request if not;
3) Make the behavior undefined (as Simon suggests).
4) = Make the behavior configurable.

I can see a sense i= n options 1 and 3. The first option is 100% backward-compatible and that= 9;s good. The third option allows legacy TURN clients in networks where IPv= 6 is the default protocol (if the legacy client is IPv6 - aware) and leaves= the decision to the TURN server administrator or implementation. I am not = sure about the fourth option - it may impose unnecessary complication on th= e implementation.

But I am against the option 2. It is too harsh and it introduces = mandatory backward incompatibility.

Oleg






On Sun,= Feb 9, 2014 at 10:24 AM, Paul Kyzivat <pkyzivat@alum.mit.edu><= /span> wrote:
Shouldn't backward compatibility of TURN= -bis servers with TURN clients be *mandatory*, rather than optional?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


On 2/7/14 5:08 PM, Oleg Moskalenko wrote:
OK, that's fine.

Oleg


On Fri, Feb 7, 2014 at 1:50 PM, Simon Perreault
<simon.= perreault@viagenie.ca <mailto:simon.perreault@viagenie.ca>> w= rote:

=A0 =A0 Le 2014-02-07 16:19, Oleg Moskalenko a =E9crit :
=A0 =A0 =A0> Well... OK. If we want the client always to send the addres= s-family -
=A0 =A0 =A0> but we do not enforce that on the receiving side... that so= unds
=A0 =A0 =A0> awkward, =A0like a speed limit without cops. It is great - = but does
=A0 =A0 that
=A0 =A0 =A0> strict requirement make sense without enforcement ? We can = always say
=A0 =A0 =A0> that TURN client SHOULD send the address-family, but MUST =A0 =A0 probably would
=A0 =A0 =A0> be too strict... I guess.

=A0 =A0 The idea is: first, we specify that TURN bis clients MUST send
=A0 =A0 REQUESTED-ADDRESS-FAMILY. Then we specify TURN bis server behaviour=
=A0 =A0 depending on the value of REQUESTED-ADDRESS-FAMILY. We do *not* spe= cify
=A0 =A0 TURN bis server behaviour when that parameter is absent. If the
=A0 =A0 parameter is absent, the client is not following the TURN bis spec,= and
=A0 =A0 the server is free to behave however it wants. That includes *wink = wink*
=A0 =A0 being backward-compatible with TURN.

=A0 =A0 This is exactly like the STUNv2 magic cookie: STUNv2 clients MUST s= end
=A0 =A0 the magic cookie, and STUNv2 server behaviour is defined when the c= ookie
=A0 =A0 is present. But STUNv2 does not specify server behaviour when the c= ookie
=A0 =A0 is absent. The cookie being absent means the client is not a STUNv2=
=A0 =A0 client. The server is free to behave however it wishes. That includ= es
=A0 =A0 *wink wink* being backward-compatible with STUNv1.

=A0 =A0 Simon
=A0 =A0 --
=A0 =A0 DTN made easy, lean, and smart --> http://postellation.viagenie.ca=
=A0 =A0 NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
=A0 =A0 STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca
=A0 =A0 _______________________________________________
=A0 =A0 tram mailing list
=A0 =A0 tram@ietf.org <mailto:tram@ietf.o= rg>
=A0 =A0 https://www.ietf.org/mailman/listinfo/tram
=




_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--e89a8ff24355d06df404f2023bb8-- From pkyzivat@alum.mit.edu Sun Feb 9 18:44:33 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EDC1A066E for ; Sun, 9 Feb 2014 18:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 S2NGzyvd0kWE for ; Sun, 9 Feb 2014 18:44:32 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id A75F51A062A for ; Sun, 9 Feb 2014 18:44:31 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta09.westchester.pa.mail.comcast.net with comcast id QSTB1n0060cZkys59SkXkb; Mon, 10 Feb 2014 02:44:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id QSkX1n0083ZTu2S3WSkXzv; Mon, 10 Feb 2014 02:44:31 +0000 Message-ID: <52F83D0F.2090301@alum.mit.edu> Date: Sun, 09 Feb 2014 21:44:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <52F54CDC.1040502@viagenie.ca> <52F5550D.3020203@viagenie.ca> <52F7C7E7.7050005@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392000271; bh=VBVQ865TZh5JKl5R/TQBjX0C65cqJ+YyDzM25iEJ2IY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hq68mJERqR/Pgb0Fhf8QhuznA9Fc1/5fTd+WZH6bel2gRvkpxgZTQNnIV92AobM5k Ak1xuLP/uUsY//Rq84L2zL17ItkAXpjbZ9k74CS8rPle9nuIFwjjhvmTSuiFJO0Ekm hdiGeKuEX71Czj4NJpEgSriaSjhywAj0GIZ9V9UQG6GIdM4hwtQ2DZLBD19a2J3XJI evJpV1XXr3aWXgNoxMBdU+kKlgzIdUBRhS3tWdOWv95YbRXlGLVSGlXlIPuRmYtpkb uYwmnl3JANSLraGgj6q9VjqQsLQr0AVXfvkJbMu8Dl0BJTGfjIAHOyE0jMOo9MoyWF 2fMODz5R+tW4Q== Cc: "tram@ietf.org" Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 02:44:34 -0000 IMO only (1) makes sense. With the others, migration becomes a nightmare. No flag days! Thanks, Paul On 2/9/14 7:15 PM, Oleg Moskalenko wrote: > I am not sure whether we want a very strict language here. > > This is about how the TURN server will react in case of missed > REQUESTED-TRANSPORT attribute. There may be three ways to react: > > 1) Respond with IPv4 relay endpoint (the current TURN way of doing things); > 2) Reject the request (strict enforcement of REQUESTED-TRANSPORT attribute); > 3) Respond with IPv6 relay endpoint (may make sense in some networks > with heavy IPv6 infestation, like mobile networks). > > The new standard (TURN-bis) may have three options for the TURN server: > > 1) Keep the 1st way (as in current TURN) as backward-compatible solution; > 2) Require that the client always includes that attribute and the TURN > server rejects the request if not; > 3) Make the behavior undefined (as Simon suggests). > 4) Make the behavior configurable. > > I can see a sense in options 1 and 3. The first option is 100% > backward-compatible and that's good. The third option allows legacy TURN > clients in networks where IPv6 is the default protocol (if the legacy > client is IPv6 - aware) and leaves the decision to the TURN server > administrator or implementation. I am not sure about the fourth option - > it may impose unnecessary complication on the implementation. > > But I am against the option 2. It is too harsh and it introduces > mandatory backward incompatibility. > > Oleg > > > > > > > On Sun, Feb 9, 2014 at 10:24 AM, Paul Kyzivat > wrote: > > Shouldn't backward compatibility of TURN-bis servers with TURN > clients be *mandatory*, rather than optional? > > Thanks, > Paul > > > On 2/7/14 5:08 PM, Oleg Moskalenko wrote: > > OK, that's fine. > > Oleg > > > On Fri, Feb 7, 2014 at 1:50 PM, Simon Perreault > > >> wrote: > > Le 2014-02-07 16:19, Oleg Moskalenko a écrit : > > Well... OK. If we want the client always to send the > address-family - > > but we do not enforce that on the receiving side... that > sounds > > awkward, like a speed limit without cops. It is great - > but does > that > > strict requirement make sense without enforcement ? We > can always say > > that TURN client SHOULD send the address-family, but MUST > probably would > > be too strict... I guess. > > The idea is: first, we specify that TURN bis clients MUST send > REQUESTED-ADDRESS-FAMILY. Then we specify TURN bis server > behaviour > depending on the value of REQUESTED-ADDRESS-FAMILY. We do > *not* specify > TURN bis server behaviour when that parameter is absent. If the > parameter is absent, the client is not following the TURN > bis spec, and > the server is free to behave however it wants. That > includes *wink wink* > being backward-compatible with TURN. > > This is exactly like the STUNv2 magic cookie: STUNv2 > clients MUST send > the magic cookie, and STUNv2 server behaviour is defined > when the cookie > is present. But STUNv2 does not specify server behaviour > when the cookie > is absent. The cookie being absent means the client is not > a STUNv2 > client. The server is free to behave however it wishes. > That includes > *wink wink* being backward-compatible with STUNv1. > > Simon > -- > DTN made easy, lean, and smart --> > http://postellation.viagenie.__ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _________________________________________________ > tram mailing list > tram@ietf.org > > https://www.ietf.org/mailman/__listinfo/tram > > > > > > > _________________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/__listinfo/tram > > > > _________________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/__listinfo/tram > > > From andrew.hutton@unify.com Mon Feb 10 02:49:42 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CDF1A06CA for ; Mon, 10 Feb 2014 02:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 xWNVIF3o4y5q for ; Mon, 10 Feb 2014 02:49:37 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 10BEC1A06CF for ; Mon, 10 Feb 2014 02:49:36 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 5FC3F23F0610; Mon, 10 Feb 2014 11:49:35 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.100]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 11:49:35 +0100 From: "Hutton, Andrew" To: Karl Stahl , "tram@ietf.org" , "tireddy@icisco.com" , 'Simon Perreault' Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPJk3JsGfKk07E6EmWIrDs9i+Ifw== Date: Mon, 10 Feb 2014 10:49:34 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17CED9A9@MCHP04MSX.global-ad.net> References: <082c01cf17d4$393d7bb0$abb87310$@stahl@intertex.se> <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se> In-Reply-To: <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17CED9A9MCHP04MSXglobal_" MIME-Version: 1.0 Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 10:49:42 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17CED9A9MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgdGhhdCB0aGlzIGlzIHRvcCBwcmlvcml0eSBtaWxlc3RvbmUgZm9yIFRSQU0gYW5kIEkg YW0gd2lsbGluZyB0byBjb250cmlidXRlIHRvIHRoaXMuDQoNCkl0IGlzIGdyZWF0IHRvIGhlcmUg dGhhdCBhIGRyYWZ0IHdpbGwgYmUgcHVibGlzaGVkIHNvb24gb24gdGhpcyBzdWJqZWN0IG9ubHkg c29ycnkgdGhhdCBJIGhhdmUgbm90IGZvdW5kIHRpbWUgdG8gZG8gaXQgYmVmb3JlIG5vdy4NCg0K UmVnYXJkcw0KQW5keQ0KDQoNCg0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEthcmwgU3RhaGwNClNlbnQ6IDA4IEZlYnJ1YXJ5IDIwMTQgMTM6 MTENClRvOiB0cmFtQGlldGYub3JnOyB0aXJlZGR5QGljaXNjby5jb207ICdTaW1vbiBQZXJyZWF1 bHQnDQpTdWJqZWN0OiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292 ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpLYXJsIGZyb20gSW5nYXRl IGFuZCBJbnRlcnRleCBqdXN0IGFkZGVkIGhpbXNlbGYgdG8gdGhpcyBsaXN0IGZvciBleGFjdGx5 IHRoZSBwdXJwb3NlIG9mIHRoZSBzdWJqZWN0IG9mIE1pbGVzdG9uZSAzIGFib3ZlDQoNCkkgd2Vs Y29tZSB0aGlzIGluaXRpYXRpdmUgdGhhdCBJIHNhdyB5ZXN0ZXJkYXkgYWZ0ZXIgYmVpbmcgcmVt aW5kZWQgYnkgQ2hpbmEgTW9iaWxlIFJlc2VhcmNoIEluc3RpdHV0ZSB3aG8gaGFkIHNlZW4gdGhl IHByZXZpb3VzIE9jdG9iZXIgZGlzY3Vzc2lvbiBvbiB0aGUgV2ViUlRDLWxpc3QsIHBhcnRzIG9m IHdoaWNoIGFyZSBpbnNlcnRlZCBiZWxvdy4gTGFyZ2UgY2FycmllcnMgaGF2ZSBhbHNvIGV4cHJl c3NlZCB0aGUgaW1wb3J0YW5jZSBvZiB0aGlzIG1pbGVzdG9uZS4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tDQpXZSBhcmUgd29ya2luZyBvbiB0aGlzIGRyYWZ0LCB3aWxsIHB1Ymxpc2ggaXQgbmV4dCB3 ZWVrLg0KLVRpcnUuDQoNCkdyZWF0LCBwbGVhc2UgY29uc2lkZXIgdGhlIGlucHV0IGFuZCBzdWdn ZXN0aW9ucyBiZWxvdzoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0 cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzIGF0IGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU2ltb24g UGVycmVhdWx0DQo+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDcsIDIwMTQgNzo1OCBQTQ0KPiBU bzogdHJhbSBhdCBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4g c2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3INCj4gZW50ZXJwcmlzZSBhbmQgSVNQ cw0KPg0K4oCmDQo+IEVudGVycHJpc2VzIG9yIElTUHMgd2lzaGluZyB0byBwcm92aWRlDQo+IHRo ZWlyIG93biBUVVJOIHNlcnZlciwgaW4gYW4gYXR0ZW1wdCB0byByZWR1Y2Ugc28tY2FsbGVkICJ0 cmlhbmdsZSByb3V0aW5nIiwNCj4gbmVlZCBhIG5ldyBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20u DQotLS0gVGhlcmUgYXJlIG1vcmUgcmVhc29ucyBoZWFyZCBmb3IgYXV0by1kaXNjb3Zlcnkgb2Yg YSBuZXR3b3JrIHByb3ZpZGVkIFRVUk4gc2VydmVyOg0KDQotIE5TUHMgKE5ldHdvcmsgU2Vydmlj ZSBQcm92aWRlcnMpIHdhbnQgdG8gcHJvdmlkZSBhIHBhdGggd2hlcmUgdGhlIGJhbmR3aWR0aCBv ZiBXZWJSVEMgaXMgYmV0dGVyIGNvcGVkIHdpdGguDQotIE5TUHMgb3IgRW50ZXJwcmlzZXMgd2Fu dCB0byBvZmZlciBhbiBJbnRlcm5ldCBhY2Nlc3MgcXVhbGl0eSBwaXBlIGZvciBwcmlvcml0aXpl ZCBSVEMgKFJlYWwgVGltZSBDb21tdW5pY2F0aW9uKSB0cmFmZmljLg0KLSBFbnRlcnByaXNlcyBo YXZpbmcgcmVzdHJpY3RpdmUgZmlyZXdhbGxzLCB3YW50IHRvIHByb3ZpZGUgYSBVRFAtcGF0aCBm b3IgV2ViUlRDIGFuZCBwb3NzaWJseSBhbHNvIGZvciBiZXR0ZXIgcXVhbGl0eSB3aGVyZSBSVEMg ZG8gbm90IGNvbXBldGUgd2l0aCBkYXRhIHRyYWZmaWMuDQotIE1vYmlsaXR5OyBJdCBpcyBjb21t b24gdG8gbW92ZSBmcm9tIGEgTEFOIHRvIGFjY2Vzc2luZyB2aWEgV2lGaSBvciAzRy80RyBPVFQg Y2hhbm5lbHMsIGFsbCBzaG91bGQgYmUgYWJsZSB0byBhdXRvbWF0aWNhbGx5IG9mZmVyIHRoZWly IG93biBvcHRpbWFsIFRVUk4gc2VydmVyDQoNCi0gTm90ZSB0aGF0IHRvIGFjaGlldmUgc29tZSBv ZiB0aGUgYWJvdmUgcG9pbnRzLCBUVVJOIG11c3QgYmUgZmF2b3JlZCBvdmVyIFNUVU4gdG8gZW5m b3JjZSB0aGF0IHRoZSBUVVJOLXBhdGggYWN0dWFsbHkgaXMgdXNlZC4gKFRoZSBBbnljYXN0IG1l dGhvZCBzdWdnZXN0ZWQgYmVsb3csIOKAnGF1dG9tYXRpY2FsbHnigJ0gZG9lcyB0aGlzLikNCg0K LS0gSW4gbXkgdmlldywgYSBUVVJOIHNlcnZlciBpcyB0aGUgbmV0d29yayBwcm92aWRlcnPigJkg cmVzcG9uc2liaWxpdHkgdG8gcHJvdmlkZSAoanVzdCBsaWtlIHRoZSBJUCBhZGRyZXNzLCB0aGUg ZGVmYXVsdCBnYXRld2F5LCB0aGUgRE5TIGV0Yy4pIOKAkyByYXRoZXIgdGhhbiB0aGUgYXBwbGlj YXRpb24gcHJvdmlkZXLigJlzLiBPdXIgY3VycmVudCBJbnRlcm5ldCBhY2Nlc3NlcyBtYXkgbm90 IGNvcGUgd2l0aCBvciBiZSBvcHRpbWl6ZWQgZm9yIFdlYlJUQyB1c2FnZSDigJMgVGhlIE5TUCAo b3IgRW50ZXJwcmlzZSBMQU4gYWRtaW5pc3RyYXRvcikgc2hvdWxkIHRoZW4gYmUgYWJsZSB0byBm aXggdGhlIGFjY2VzcyAoaGVyZSBieSBvZmZlcmluZyBhIFRVUk4gc2VydmVyKS4NCg0KPiBJTUhP IHRoaXMgaXMgYWxzbyBhIHRvcC1wcmlvcml0eSBtaWxlc3RvbmUuIFdlIG5lZWQgdG8gcXVpY2ts eSBoYXZlIGENCj4gbWVjaGFuaXNtIHRoYXQgcGVvcGxlIGNhbiBpbXBsZW1lbnQgaW4gV2ViUlRD IGJyb3dzZXJzIG5vdywgd2hpbGUNCj4gdGhlcmUgaXMgc3RpbGwgZnJlbmV0aWMgZGV2ZWxvcG1l bnQgaGFwcGVuaW5nLg0KLS0tIEFncmVlDQpJIGRvbid0IGZvcmVzZWUgYWN0dWFsIHNlcnZlci0N Cj4gc2lkZSBkZXBsb3ltZW50IGhhcHBlbmluZyBxdWlja2x5IHRob3VnaC4gQnV0IGFzIHNvb24g YXMgY2xpZW50cyBhcmUgcmVhZHksDQo+IGFueSBJU1Agb3IgZW50ZXJwcmlzZSBjYW4gZGVwbG95 IGFuZCBpbW1lZGlhdGVseSBiZW5lZml0Lg0KLSBUaGVyZSBpcyBhIGRlZmluaXRpdmUgaW50ZXJl c3QgYW1vbmcgZm9yd2FyZCBTUHMgYWxyZWFkeSwgZXNwZWNpYWxseSBjYXJyaWVycyBvd25pbmcg dGhlIG5ldHdvcmsuDQooVGhleSBoYXZlIGxlYXJuZWQgdGhhdCB0aGVpciBuZXR3b3JrcyAoZXNw ZWNpYWxseSBtb2JpbGUpIHNlZW0gdG8gYmVjb21lIGRhdGEgY3Jvd2RlZCBubyBtYXR0ZXIgaG93 IG11Y2ggYmFuZHdpZHRoIHRoZXkgaW52ZXN0IGluLikNCg0KPiBJIGltYWdpbmUgdGhhdCB0aGUg c29sdXRpb24gd2lsbCBiZSBmYWlybHkgc2ltcGxlLCBzcGVjLSBhbmQgaW1wbGVtZW50YXRpb24t DQo+IHdpc2UuDQotLS0gQWdyZWUgdGhhdCBzdWNoIHNvbHV0aW9uIHNob3VsZCBhbmQgY291bGQg YmUgZm91bmQsIGJ1dCBpdCBpcyBub3Qgb2J2aW91cy4gQmVsb3cgeW91IGZpbmQgMyBwcm9wb3Nh bHMgKGluaXRpYXRlZCBieSBtZSBvciBjb2xsZWFndWVzLCB3aGVyZSBJIHNlZSBmbGF3cyBpbiB0 aGUgdHdvIGZpcnN0IGFuZCBub3cgb25seSBzdWdnZXN0IHRoZSB0aGlyZCAodGhlIEFueWNhc3Qg bWVjaGFuaXNtKS4gRnJvbSBiZWxvdzoNCg0KLSAxc3Q6IOKApiB3aXRoZHJhdyBteSBzdWdnZXN0 aW9uIHRvIHVzZSBESENQIHRvIGZpbmQgYSBuZXR3b3JrIHByb3ZpZGVyIG9mZmVyZWQgVFVSTiBz ZXJ2ZXIgaW4gZmF2b3Igb2YgdGhlIEROUy1CYXNlZCBTZXJ2aWNlIERpc2NvdmVyeSBtZXRob2Qg KGluc2VydGVkIGxhc3QgYmVsb3cpLiBUaGUgbWFqb3IgcHJvYmxlbSB3aXRoIHRoZSBESENQIHVz YWdlIHdhcyB0aGF0IHlvdSB0aGVuIGFsc28gaGF2ZSB0byBkbyBzb21ldGhpbmcgc2ltaWxhciBm b3I6IFJBIC0gUm91dGVyIEFkdmVydGlzZW1lbnQgLSBpbiBJUHY2LCBhZGRpdGlvbiB0byB0aGUg SVBDUCBwcm90b2NvbCBmb3IgUFBQb0UgYW5kIHNvbWV0aGluZyBmb3IgdGhlIG1vYmlsZSBPVFQg Y2hhbm5lbCDigJMgd2hlcmV2ZXIgREhDUCBpcyBOT1QgdGhlIG1ldGhvZCB0byBnaXZlIHlvdSBh biBJUCBhZGRyZXNzLiAoVGhlcmUgd2VyZSBhbHNvIGNvbmNlcm5zIHdoZXRoZXIgT1NzIGFjdHVh bGx5IHN1cHBvcnRzIGZvcndhcmRzIHN1Y2ggZXh0ZW5kZWQgREhDUCBpbmZvcm1hdGlvbiBmb3Ig dGhlIGJyb3dzZXIgdG8gdXNlLikNCg0KLSAybmQgUmV2ZXJzZSBETlMtQmFzZWQgU2VydmljZSBE aXNjb3ZlcnkgbWV0aG9kOg0KSnVzdGluIFViZXJ0aSBwb2ludGVkIG91dDogIEhvdyBkb2VzIHRo aXMgZ2V0IGJvb3RzdHJhcHBlZD8gVGhhdCBpcywgaG93IGlzIHRoZSBTVFVOIHNlcnZlciBmb3Vu ZD8NCltLYXJsXSBPb3BzLCB0aGF0IGdvdCBsb3N0IHdoZW4gbGVhdmluZyB0aGUgREhDUCB0cmFj aywgYW5kIGlzIGEgcHJvYmxlbSB3aGVuIHVzaW5nIEROUyBkaXNjb3ZlcnkuDQooVGhlcmUgd2Vy ZSBhbHNvIGhlc2l0YXRpb25zIG9mIGhhdmluZyB0byBwcm92aXNpb24gdGhpcyBzcGVjaWFsIHJl dmVyc2UgRE5TIGZvciBldmVyeSBhY2Nlc3MuKQ0KDQotIDNyZCBUaGUgQW55Y2FzdCBtZXRob2Qg YmVsb3cg4oCTIEkgc2VlIG5vIHByb2JsZW0NCkl0IGFsc28gaGFzIHRoZSBhZHZhbnRhZ2Ugb2Yg ZW5jb3VyYWdpbmcgKGJ1dCBub3QgcmVxdWlyaW5nKSB0aGUgU1RVTi9UVVJOIHRvIGJlIGJ1aWx0 IGluIHRoZSBkZWZhdWx0IGdhdGV3YXkgb3IgTkFUL2ZpcmV3YWxsL2FjY2VzcyByb3V0ZXIgaXRz ZWxmLCB3aXRoIGEgc2Vjb25kIGludGVyZmFjZSB0byBhIHB1YmxpYyBJUCBhZGRyZXNzIG9uIHRo ZSBXQU4gc2lkZS4gKEN1cnJlbnQgdm9sdW1lIGRlcGxveWVkLCBsb3cgY29zdCBOU1AgdHJpcGxl IHBsYXkgbW9kZW1zIHVzdWFsbHkgaGF2ZSBhIHF1YWxpdHkgYXNzdXJlZCBsZXZlbCAyIG9yIGxl dmVsIDMgV0FOIHBpcGUgZm9yIGp1c3Qgdm9pY2UgKGFuZCBhbm90aGVyIGZvciBJUFRWKSDigJMg VGhlIGFueWNhc3QgZGlzY292ZXJlZCBUVVJOLXNlcnZlciBjYW4gYmUgdGhlIGFjY2VzcyBnYXRl d2F5IHRvIHN1Y2ggcXVhbGl0eSBwaXBlIGZvciBXZWJSVEMgbWVkaWEsIGluIGEgc2luZ2xlIE5T UCBwcm92aWRlZCBDUEUsIHNjYWxpbmcgZnJvbSByZXNpZGVudGlhbCBhbmQgdXAuKQ0KDQpTbyBJ IHRoaW5rIHdlIGNhbiBmaW5pc2ggdGhpcyB2ZXJ5IHF1aWNrbHkgb25jZSB3ZSBoYXZlIGEgY2Fu ZGlkYXRlDQo+IGRyYWZ0LiBXZSBqdXN0IG5lZWQgYXV0aG9ycy4gU28gSSB3b3VsZCB0YXJnZXQg bm90IGxvbmcgYWZ0ZXIgVG9yb250by4NCj4NCj4gU2ltb24NCg0KV0VCIEJST1dTRVIgQkVIQVZJ T1VSOg0KDQpOZXR3b3JrIHByb3ZpZGVkIFRVUk4gc2VydmVycyB3aWxsIG5vdCBhcHBlYXIgb3Zl ciBuaWdodCwgYXBwbGljYXRpb25zIG1heSBmb3IgbG9uZyBwcm92aWRlIGEgVFVSTiBzZXJ2ZXIg YWRkcmVzcywgYW5kIHRoZXJlIGFyZSBleGNlcHRpb25zIHdoZXJlIHRoZSBUVVJOIHNlcnZlciBh ZGRyZXNzIGlzIHByZWZlcnJlZCB0byBiZSDigJxtYW51YWxseeKAnSBjb25maWd1cmVkLiBJdCBp cyBwcmV2aW91c2x5IHN1Z2dlc3RlZCwgYW5kIHRvIHNvbWUgZXh0ZW50IGRpc2N1c3NlZCwgdGhh dCB0aGUgV2ViUlRDIGJyb3dzZXIgc2hvdWxkIHNlbGVjdCB0aGUgVFVSTiBzZXJ2ZXIgdG8gdXNl IGluIHRoZSBmb2xsb3dpbmcgcHJpb3JpdHkgb3JkZXIsIHdoZXJlIElDRSB3b3VsZCBhc3N1cmUg dGhhdCB5b3UgZ2V0IHNvbWUgY29ubmVjdGl2aXR5IGlmIHNldmVyYWwgY2FuZGlkYXRlcyBhcmUg Zm91bmQgYW5kIG5lZWRzIHRvIGJlIHRlc3RlZDoNCg0KMSkgVFVSTiBzZXJ2ZXIgYWRkcmVzcyBj b25maWd1cmVkIGluIHRoZSBicm93c2VyIGJ5IHRoZSB1c2VyIChzcGVjaWFsIGNhc2VzLCBub3Jt YWxseSBub3QgdXNlZCwgYnV0IGhhbmR5IGZvciB0ZXN0aW5nKQ0KMikgVFVSTiBzZXJ2ZXIgYWRk cmVzcyBjb25maWd1cmVkIGJ5IHRoZSBuZXR3b3JrIGFkbWluaXN0cmF0b3IgdmlhIGFuIOKAnGFk bWluIHBvbGljeSB0ZW1wbGF0ZeKAnSBvciBhIFdQQUQgbWV0aG9kIGFzIG1lbnRpb25lZCBiZWxv dw0KMykgVFVSTiBzZXJ2ZXIgYWRkcmVzcyBhdXRvLWRpc2NvdmVyZWQgYnkgdGhlIG1lY2hhbmlz bSBkaXNjdXNzZWQgaGVyZQ0KNCkgVFVSTiBzZXJ2ZXIgYWRkcmVzcyBiZWluZyBzdXBwbGllZCBi eSB0aGUgd2ViIGFwcGxpY2F0aW9uDQoNCldpdGggYSBnb29kIHN0ZXAgMyksIHN0ZXAgMikgYmVj b21lcyBvYnNvbGV0ZSBzaW5jZSB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9yIGUuZy4gc2ltcGx5 IGNhbiBzZXQgYSByb3V0ZSBpbiB0aGUgZW50ZXJwcmlzZSBmaXJld2FsbCB0byB1c2UgdGhlIEFu eWNhc3QgbWVjaGFuaXNtIGluc3RlYWQuDQoNCkV2ZW4gaWYgdGhlIG5lZWQgZm9yIGF1dG8tZGlz Y292ZXJ5IG9mIHRoZSBUVVJOIHNlcnZlciBjb21lcyBmcm9tIFdlYlJUQyB1c2FnZSwgYSBnZW5l cmFsIG1lY2hhbmlzbSB0aGF0IGFsc28gY2FuIGJlIHVzZWQgYnkgU0lQIGNsaWVudHMgKGFuZCBv dGhlciBwcm90b2NvbHMgdXNpbmcgVFVSTiB2aWEgSUNFKSBpcyBwcmVmZXJhYmxlLiBUaGUgYW55 Y2FzdCBtZXRob2QgaGFzIG5vIGFwcGxpY2F0aW9uIGRlcGVuZGVuY2UsIGJ1dCBlLmcuIFdQQUQg aGFzIChhIFNJUCBDbGllbnQgdHlwaWNhbGx5IGRvZXMgbm90IGhhdmUgdGhlIGx1eHVyeSBvZiBh IEpTIGVuZ2luZeKApikNCg0KL0thcmwNCg0KDQpGcsOlbjogS2FybCBTdGFobCBbbWFpbHRvOmth cmwuc3RhaGxAaW50ZXJ0ZXguc2VdDQpTa2lja2F0OiBkZW4gMjIgb2t0b2JlciAyMDEzIDE2OjM3 DQpUaWxsOiAnSnVzdGluIFViZXJ0aSc7ICdDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSknDQpLb3Bp YTogJ0Jlcm5hcmQgQWJvYmEnOyAnSGFyYWxkIEFsdmVzdHJhbmQnOyAnZHJhZnQtaWV0Zi1ydGN3 ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHNAdG9vbHMuaWV0Zi5vcmcnOyAncnRjd2ViQGll dGYub3JnJw0Kw4RtbmU6IFtydGN3ZWJdIFttbXVzaWNdIEFueWNhc3QgZGlzY292ZXJ5LCBXYXMg VFVSTiBzZXJ2ZXIgYWRkcmVzcyB2aWEgREhDUCwgV0dMQyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi11 c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xMQ0KDQpTZWUgbXkgY29tbWVudHMgYmVsb3cuIFRo ZSBwcm9ibGVtIG9mIGhhdmluZyB0byBrbm93IGEgZmlyc3QgU1RVTiBzZXJ2ZXIgaW4gb3JkZXIg dG8gdXNlIEROUyBkaXNjb3ZlcnksIG1ha2VzIHRoZSBzdWdnZXN0aW9ucyBiZWxvdyBsZXNzIGdv b2QuDQoNCkFub3RoZXIgaWRlYSBjYW1lIHVwOyB0byB1c2UgYW55Y2FzdCB0byBhbGxvdyBhIFdl YlJUQyBicm93c2VyIHRvIGZpbmQgYSBuZXR3b3JrIHByb3ZpZGVkIFRVUk4gc2VydmVyIChib3Ro IGxvY2FsIG9uIGEgTEFOIG9yIHByb3ZpZGVkIGJ5IGEgY2FycmllcikuIChUaGVyZSBhcmUgc29t ZSBkaXNjdXNzaW9uIGFyb3VuZCB1c2luZyBhbnljYXN0IGluIHRoZSBTVFVOIGFuZCBUVVJOIFJG Q3MuKSBUaGlzIGFueWNhc3Qtd2F5IHNob3VsZCB3b3JrIGJvdGggZm9yIGEgVFVSTiBzZXJ2ZXIg b24gYSBMQU4gYW5kIGEgVFVSTiBzZXJ2ZXIgb3V0c2lkZSB0aGUgTkFUL0ZpcmV3YWxsIChhbnkg cm91dGVyIGluIHRoZSBjaGFpbiBjYW4gdGFrZSBjYXJlIG9mIGFuIGFueWNhc3QgYWRkcmVzcykg YW5kIGJ5IHRoZSBzaW1wbGUgbWV0aG9kIGJlbG93LCByZXR1cm4gdGhlIGF2YWlsYWJsZSBUVVJO IHNlcnZlciBjbG9zZXN0IHRvIHRoZSBjbGllbnQuIEZpbmRpbmcgYSBUVVJOIHNlcnZlciBjbG9z ZSB0byB0aGUgY2xpZW50ICh0aGUgV2ViUlRDIGJyb3dzZXIpIHdpbGwgYWxzbyBtaW5pbWl6ZSDi gJx0aGUgdHVybuKAnSB0aGUgcmVhbC10aW1lIHRyYWZmaWMgaGFzIHRvIHRha2UuDQoNClRoZSBz dWdnZXN0aW9uIGlzIHRvIGRlZmluZSBhbiBhbnljYXN0IElQIGFkZHJlc3MgZm9yIFNUVU4gc2Vy dmVycyBhbmQ6DQotIFRoZSBuZXR3b3JrIHByb3ZpZGVyLCBvZmZlcmluZyBhIFRVUk4gc2VydmVy IG9uIGhpcyBhY2Nlc3MsIGFkZHMgYSByb3V0ZSBpbiBoaXMgYWNjZXNzIHJvdXRlciAob3IgTkFU L0ZpcmV3YWxsKSBzbyB0aGF0IHRoZSBhbnljYXN0IGFkZHJlc3Mgcm91dGVzIHRvIGhpcyBUVVJO L1NUVU4gc2VydmVyIChhIFRVUk4gc2VydmVyIGlzIGFuIGV4dGVuc2lvbiBvZiBTVFVOIHNlcnZl ciwgdGh1cyBpbmNsdWRlZCBpbiB0aGUgc2FtZSBib3gpLg0KLSBUaGUgVFVSTi9TVFVOIHNlcnZl ciBpcyBjb25maWd1cmVkIHRvIHJlc3BvbmQgdG8gYSBiaW5kaW5nIHJlcXVlc3Qgd2l0aCBhIOKA nDMwMCBUcnkgYWx0ZXJuYXRlIHNlcnZlcuKAnSwgdGhhdCBwb2ludHMgb3V0IHRoZSBzYW1lIFRV Uk4vU1RVTiBzZXJ2ZXIgKGJ5IGl0cyByZWFsIElQIGFkZHJlc3MsIG5vdCB0aGUgYW55Y2FzdCBh ZGRyZXNzKS4NCg0KVGhlIFdlYlJUQyBicm93c2VyIGNsaWVudCB3b3VsZCB0aGVuOg0KLSBJc3N1 ZSBhIFNUVU4gYmluZGluZyByZXF1ZXN0IHRvIHRoZSBhbnljYXN0IGFkZHJlc3MNCi0gSXNzdWUg YW5vdGhlciBTVFVOIGJpbmRpbmcgcmVxdWVzdCB0byB0aGUgQUxURVJOQVRFIFNFUlZFUiBJUCBh ZGRyZXNzIGluIHRoZSDigJwzMDAgVHJ5IGFsdGVybmF0ZeKAnSByZXNwb25zZSAoYXMgYW55IGNs aWVudCBzaG91bGQgZG8pLg0KLSBJbnRlcnByZXQgdGhlIHJlY2VpdmVkIOKAnDMwMCBUcnkgYWx0 ZXJuYXRl4oCdIHJlc3BvbnNlIG5vdyBoYXZpbmcgdGhlIHNhbWUgQUxURVJOQVRFIFNFUlZFUiBJ UCBhZGRyZXNzIGFzIHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBvZiB0aGF0IHJlc3BvbnNlLCBhcyBh biBpbmRpY2F0aW9uIHRvIHVzZSBpdHMgVFVSTiBzZXJ2ZXIgKG5vdCB0aGUgU1RVTiBzZXJ2ZXIp IGF0IHRoYXQgYWRkcmVzcy4NCg0KVGhhdCBpcyB0aGUgVFVSTiBzZXJ2ZXIgdG8gdXNlIQ0KDQpU aGUgb25seSBhZGRpdGlvbiB0byBleGlzdGluZyBzdGFuZGFyZHMgaXMgdGhlIGludGVycHJldGF0 aW9uIGFib3ZlIG9mIHRoZSDigJwzMDAgVHJ5IGFsdGVybmF0ZeKAnSByZXNwb25zZSBpbiB0aGUg U1RVTiBSQ0YgNTc2NiBoYXZpbmcgdGhlIHNhbWUgQUxURVJOQVRFIFNFUlZFUiBJUCBhZGRyZXNz IGFzIHRoZSBzb3VyY2UgSVAgYWRkcmVzcyBvZiB0aGUgcmVzcG9uc2UuIEl0IG1lYW5zOiBVc2Ug dGhlIFRVUk4gc2VydmVyIGF0IHRoZSBzcGVjaWZpZWQgYWRkcmVzcy4gVGhhdCBzaG91bGQgYmUg ZWFzeSB0byBjbGFyaWZ5Lg0KKFRoZSBTVFVOIHNlcnZlciBhdCB0aGUgYW55Y2FzdCBhZGRyZXNz LCBtYXkgb3IgbWF5IG5vdCBiZSB0aGUgc2FtZSBUVVJOL1NUVU4gc2VydmVyIHVzZWQgaW4gc2Vj b25kIGJpbmRpbmcgcmVxdWVzdC4pDQoNCkF1dGhlbnRpY2F0aW9uIGNvdWxkIHNpbXBseSBiZSB0 aGF0IHRoZSBUVVJOL1NUVU4gc2VydmVyIG9ubHkgaXMgcmVhY2hhYmxlIGZyb20gdGhlIElQIGFk ZHJlc3NlcyB0aGF0IHRoZSBuZXR3b3JrIHByb3ZpZGVyIHdhbnQgdG8gc3VwcG9ydCB3aXRoIHRo ZSBUVVJOIHNlcnZlciAoZWFzeSBmb3IgdGhlIG5ldHdvcmsgcHJvdmlkZXIsIHNpbmNlIGhlIGlz IGhhbmRpbmcgb3V0IHRob3NlIElQIGFkZHJlc3NlcykuDQoNClRoaXMgc2hvdWxkIGJlIGVhc3kg dG8gcHJvdmlzaW9uIGZvciBhIGNhcnJpZXIgb3IgYSBMQU4gYWRtaW5pc3RyYXRvciBhbmQgdHJp dmlhbCB0byB0cnkgZm9yIHRoZSBXZWJSVEMgYnJvd3Nlci4NCg0KQW4gYWR2YW50YWdlIGlzIHRo YXQgdGhlIHR3byBTVFVOIGJpbmRpbmcgcmVxdWVzdHMgZGlyZWN0bHkgcmV0dXJucyB0aGUgVFVS TiBzZXJ2ZXIgYWRkcmVzcywgd2hlcmVieSB0aGUgZm9sbG93aW5nIElDRSBwcm9jZXNzIHNob3Vs ZCBiZSBxdWljayBhbmQgZWFzeS4gVGhpcyBjb3VsZCBhbHNvIGJlIGRvbmUgb25seSBvbmNlIHdo ZW4gdGhlIGJyb3dzZXIgaXMgc3RhcnRlZCBvciBnZXQgYSBuZXcgSVAgYWRkcmVzcyBhbmQgY2Fz aGVkIGZvciBsYXRlciBjYWxscy4NCg0KL0thcmwNCg0KDQpQUyBJZiB5b3Ugd29uZGVyIHdoeSBu b3QgZGVmaW5lIGFuIGFueWNhc3QgYWRkcmVzcyBmb3IgYSBUVVJOIHNlcnZlciBpbnN0ZWFkLCBy ZWFkIHRoaXMgdGhyZWFkIGZyb20gMjAwODogIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNo aXZlL3dlYi9iZWhhdmUvY3VycmVudC9tc2cwMzU4Mi5odG1sLiBUaGVyZSwgdGhlIHVzZSBvZiBh bnljYXN0IHRvIGEgVFVSTiBzZXJ2ZXIgaXMgZGlzY3Vzc2VkLCBidXQgZm91bmQgbm90IHRvIHdv cmsuIChIZXJlIGFueWNhc3QgaXMgb25seSB1c2VkIGZvciB0aGUgZmlyc3QgcmVxdWVzdCB0byB0 aGUgU1RVTiBzZXJ2ZXIsIHdoZXJlIGFmdGVyIHRoZSByZWFsIGFkZHJlc3MgdG8gdGhlIFRVUk4v U1RVTiBzZXJ2ZXIgaXMgdXNlZC4pDQoNCg0KDQpGcsOlbjogSnVzdGluIFViZXJ0aSBbbWFpbHRv Omp1YmVydGlAZ29vZ2xlLmNvbV0NClNraWNrYXQ6IGRlbiA4IG9rdG9iZXIgMjAxMyAwODoxNw0K VGlsbDogS2FybCBTdGFobA0KS29waWE6IEJlcm5hcmQgQWJvYmE7IEhhcmFsZCBBbHZlc3RyYW5k OyBDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSk7IGRyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1h bmQtcmVxdWlyZW1lbnRzQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXJ0Y3dlYi11 c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50c0B0b29scy5pZXRmLm9yZz47IHJ0Y3dlYkBpZXRmLm9y ZzxtYWlsdG86cnRjd2ViQGlldGYub3JnPg0Kw4RtbmU6IFJlOiBbcnRjd2ViXSBbbW11c2ljXSBU VVJOIHNlcnZlciBhZGRyZXNzIHZpYSBESENQLCBXR0xDIG9mIGRyYWZ0LWlldGYtcnRjd2ViLXVz ZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTExDQoNCg0KT24gTW9uLCBPY3QgNywgMjAxMyBhdCA2 OjIxIEFNLCBLYXJsIFN0YWhsIDxrYXJsLnN0YWhsQGludGVydGV4LnNlPG1haWx0bzprYXJsLnN0 YWhsQGludGVydGV4LnNlPj4gd3JvdGU6DQpTbyB0aGUgV1BBRC13YXkgb2YgZ2V0dGluZyBhIG5l dHdvcmsgcHJvdmlkZXLigJlzIFRVUk4gc2VydmVyIGFkZHJlc3MgZm9yIHRoZSByZWFsICh3aGl0 ZSwgZ2xvYmFsKSBJUCBhZGRyZXNzIGhlIGhhcyBoYW5kZWQgb3V0IHRvIGEgdXNlciwgdGhlIGJy b3dzZXIgd291bGQ6DQotIFVzZSBTVFVOIHRvIGZpbmQgdGhlIGdsb2JhbCBJUCBhZGRyZXNzIChk b25lIGFueXdheSBpbiBJQ0UpDQoNCkhvdyBkb2VzIHRoaXMgZ2V0IGJvb3RzdHJhcHBlZD8gVGhh dCBpcywgaG93IGlzIHRoZSBTVFVOIHNlcnZlciBmb3VuZD8NCltLYXJsXSBPb3BzLCB0aGF0IGdv dCBsb3N0IHdoZW4gbGVhdmluZyB0aGUgREhDUCB0cmFjaywgYW5kIGlzIGEgcHJvYmxlbSB3aGVu IHVzaW5nIEROUyBkaXNjb3ZlcnkuDQoNCi0gRG8gYSByZXZlcnNlIEROUyBsb29rdXAgKGluc3Rl YWQgb2YgdGhlIEROUy1CYXNlZCBTZXJ2aWNlIERpc2NvdmVyeSB0aGF0IGlzIG5vdCB5ZXQgZGVw bG95ZWQpDQotIE1ha2UgYSBVUkwgYmFzZWQgb24gdGhlIGhvc3RuYW1lIGZyb20gdGhlIHJldmVy c2UgRE5TIGxvb2t1cCwgZS5nLiBmcm9tIDE3OS5zdWItMTc0LTI1Mi0zNS5teXZ6dy5jb208aHR0 cDovLzE3OS5zdWItMTc0LTI1Mi0zNS5teXZ6dy5jb20+LCBtYWtlIGggdHRwOi8vdHVybmFkLm15 dnp3LmNvbTxodHRwOi8vdHVybmFkLm15dnp3LmNvbT4NCg0KSSB3YXMgaG9waW5nIHdlIGNvdWxk IGRvIHNvbWV0aGluZyBzaW1wbGVyLCBzdWNoIGFzIHVzaW5nIHRoZSBJU1AncyBjb25maWd1cmVk IGRvbWFpbiBzZWFyY2ggbGlzdCwgdG8gZGV0ZXJtaW5lIHRoZSBkb21haW4uDQogW0thcmxdIEJ1 dCBjYXJyaWVycyBkb27igJl0IHB1c2ggb3V0IHN1Y2ggdGhpbmdzLCBkbyB0aGV5PyBBbmQgaWYg dGhleSBjb3VsZCBkbyBpdCB2aWEgREhDUCB3ZSBhcmUgYmFjayB3aXRoIHRob3NlIHByb2JsZW1z IGFnYWluLg0KLSBBbmQgdGhlcmUgZmluZCBhIGxpc3QgKGluIEpTKSBvZiBUVVJOIHNlcnZlciBh ZGRyZXNzZXMgZm9yIHRoZSBuZXR3b3JrIHByb3ZpZGVy4oCZcyBJUCBhZGRyZXNzZXMNCiBPciB3 b3VsZCBhbiBhbHRlcm5hdGl2ZSBiZSB0byBhZGQgeW91ciBvd24gSVAgYWRkcmVzcyB0byB0aGUg VVJMIGFuZCBnZXQgb25seSB5b3VyIHNwZWNpZmljIFRVUk4gc2VydmVyIGFkZHJlc3M/DQoNCkRv aW5nIGl0IGF0IHRoaXMgV2ViIGxldmVsLCBJIHRoaW5rIHdlIGFsc28gc2hvdWxkIGNvbnNpZGVy IGNsaWVudHMgdXNpbmcgSUNFL1RVUk4sIGJ1dCBub3QgaGF2aW5nIHRoZSBsdXh1cnkgb2YgYSBK UyBlbmdpbmU6IFdvdWxkIGUuZy4gYSBTSVAgY2xpZW50IGJlIGFibGUgdG8gcGFyc2UgYSDigJxK UyB0YWJsZeKAnSB0byBmaW5kIGhpcyBUVVJOIHNlcnZlciBhZGRyZXNzIGVhc2lseT8gQWxzbywg YXJlIHRoZXJlIGxvbmcgdGltZS1vdXRzIHRvIGJlIGNvbnNpZGVyZWQgd2hlbiB0aGVyZSBpcyBu byBoIHR0cDovL3R1cm5lZC5teXZ6dy5jb208aHR0cDovL3R1cm5lZC5teXZ6dy5jb20+IHRvIGJl IGZvdW5kPw0KDQpUaGlzIG1ldGhvZCBtYXkgYmUgZWFzaWVyIGZvciBhIG5ldHdvcmsgcHJvdmlk ZXIgdG8gZGVwbG95IChJIGRvbuKAmXQga25vdywgYnV0IGZvciBsb2NhbCB1c2Ugb24gYSBMQU4g SSBndWVzcyBpdCBpcykuIE9uIHRoZSBvdGhlciBoYW5kLCB0aGUgRE5TLUJhc2VkIFNlcnZpY2Ug RGlzY292ZXJ5IG1ldGhvZCBpcyBxdWljayBhbmQgZWFzeSBmb3IgYSBXZWJSVEMgYnJvd3Nlciwg c28gdGhhdCBtYXkgYmUgdHJpZWQgYXMgd2VsbC4NCg0KSW5kZXBlbmRlbnQgb2YgaG93IHdlIGZp bmQgdGhlIG5ldHdvcmsgcHJvdmlkZWQgVFVSTiBzZXJ2ZXIsIG9uZSBhZHZhbnRhZ2Ugd2l0aCBp dCBpcyB0aGUgYXV0aGVudGljYXRpb246IFRoZSBuZXR3b3JrIHByb3ZpZGVyIHNpbXBseSBzZXRz IHVwIHRoZSBUVVJOIGZvciB1c2FnZSBmcm9tIHRoZSBJUCBhZGRyZXNzZXMgaGUgaGFzIGhhbmRl ZCBvdXQuDQoNCi9LYXJsDQoNCkZyw6VuOiBKdXN0aW4gVWJlcnRpIFttYWlsdG86anViZXJ0aUBn b29nbGUuY29tPG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+XQ0KU2tpY2thdDogZGVuIDMgb2t0 b2JlciAyMDEzIDIwOjU5DQpUaWxsOiBLYXJsIFN0YWhsDQpLb3BpYTogQmVybmFyZCBBYm9iYTsg SGFyYWxkIEFsdmVzdHJhbmQ7IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KTsgZHJhZnQtaWV0Zi1y dGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRy YWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzQHRvb2xzLmlldGYub3Jn PjsgcnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+DQrDhG1uZTogUmU6IFty dGN3ZWJdIFttbXVzaWNdIFRVUk4gc2VydmVyIGFkZHJlc3MgdmlhIERIQ1AsIFdHTEMgb2YgZHJh ZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTENCg0KV1BBRCBhbHJl YWR5IHN1cHBvcnRzIEROUy1iYXNlZCBkaXNjb3ZlcnkgKGluIGFkZGl0aW9uIHRvIERIQ1ApLiBJ ZiB5b3UgaGF2ZSBob3N0LTk1LTE5OS0xOTYtNjUubW9iaWxlb25saW5lLnRlbGlhLmNvbTxodHRw Oi8vaG9zdC05NS0xOTktMTk2LTY1Lm1vYmlsZW9ubGluZS50ZWxpYS5jb20vPiBhcyB5b3VyIGVu ZHBvaW50IGhvc3RuYW1lLCBpdCB3aWxsIHRyeSB0byBnZXQgYSBQQUMgZmlsZSBmcm9tIHdwYWQu bW9iaWxlb25saW5lLnRlbGlhLmNvbTxodHRwOi8vd3BhZC5tb2JpbGVvbmxpbmUudGVsaWEuY29t Pi4NCg0KU2luY2UgZm9yIGFsbCBwcmFjdGljYWwgcHVycG9zZXMsIFRVUk4gaXMgYSAiVURQIHBy b3h5IiwgSSB0aGluayBpdCBzaG91bGQgYmUgaGFuZGxlZCBzaW1pbGFyIHRvIG90aGVyIHByb3h5 IGF1dG9jb25maWcgbWVjaGFuaXNtcy4NCg0KT24gTW9uLCBTZXAgMzAsIDIwMTMgYXQgNToxMyBQ TSwgS2FybCBTdGFobCA8a2FybC5zdGFobEBpbnRlcnRleC5zZTxtYWlsdG86a2FybC5zdGFobEBp bnRlcnRleC5zZT4+IHdyb3RlOg0KSSBoYXBwaWx5IHdpdGhkcmF3IG15IHN1Z2dlc3Rpb24gdG8g dXNlIERIQ1AgdG8gZmluZCBhIG5ldHdvcmsgcHJvdmlkZXIgb2ZmZXJlZCBUVVJOIHNlcnZlciBp biBmYXZvciBvZiB0aGUgRE5TLUJhc2VkIFNlcnZpY2UgRGlzY292ZXJ5IG1ldGhvZCAoaW5zZXJ0 ZWQgbGFzdCBiZWxvdykuIFRoZSBtYWpvciBwcm9ibGVtIHdpdGggdGhlIERIQ1AgdXNhZ2Ugd2Fz IHRoYXQgeW91IHRoZW4gYWxzbyBoYXZlIHRvIGRvIHNvbWV0aGluZyBzaW1pbGFyIGZvcjogUkEg LSBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCAtIGluIElQdjYsIGFkZGl0aW9uIHRvIHRoZSBJUENQIHBy b3RvY29sIGZvciBQUFBvRSBhbmQgc29tZXRoaW5nIGZvciB0aGUgbW9iaWxlIE9UVCBjaGFubmVs IOKAkyB3aGVyZXZlciBESENQIGlzIE5PVCB0aGUgbWV0aG9kIHRvIGdpdmUgeW91IGFuIElQIGFk ZHJlc3MuDQoNCkZ1cnRoZXI6DQo+IE9uIFRodSwgU2VwIDI3LCAyMDEzIEp1c3RpbiBVYmVydGkg d3JvdGU6DQo+IEFncmVlLiBJIHN0aWxsIHRoaW5rIHRoYXQgZXh0ZW5kaW5nIFBBQyBmaWxlcyB0 byBpbmNsdWRlIFRVUk4gaW5mb3JtYXRpb24gaXMgdGhlIHJpZ2h0IHdheSB0byBnby4NCj4gUEFD IGZpbGVzIGNhbiBhbHJlYWR5IGJlIGRpc2NvdmVyZWQgdmlhIERIQ1Agb3IgRE5TLCB0aGVyZSBp cyBubyBuZWVkIHRvIHJlaW52ZW50IHRoaXMgd2hlZWwuDQoNCj4+T24gVGh1LCBTZXAgMjYsIDIw MTMgYXQgNDo1NSBQTSwgQ3VsbGVuIEplbm5pbmdzIChmbHVmZnkpIDxmbHVmZnlAY2lzY28uY29t PG1haWx0bzpmbHVmZnlAY2lzY28uY29tPj4gd3JvdGU6DQo+PkkgdGhpbmsgd2UgbmVlZCB0byBn aXZlIHNvbWUgYWR2aXNlIHRvIHRoZSBicm93c2VycyB2ZW5kb3JzIG9uIHdoYXQgdGhleSBzaG91 bGQgaW1wbGVtZW50IHRvIGZpbmQgdHVybiBzZXJ2ZXJzDQoNCkkgR29vZ2xlZCBhIGJpdCBvbiBQ QUMgYW5kIFdQQUQgYW5kIHNhdyB0aGF0IGEgSFRUUCBwcm94eSBjb25maWcgSlMgZmlsZSBjYW4g YmUgcGlja2VkIHVwIHRocm91Z2ggYSBVUkwgYmFzZWQgb24gdGhlIGRldmljZSBuYW1lLiBTaW1p bGFyIGNvdWxkIHdvcmsgZm9yIGZpbmRpbmcgYSBUVVJOIHNlcnZlciBvbiBhIExBTiwgYnV0IHdo YXQgYWJvdXQgdGhlIGNhc2Ugd2l0aCBhIG5ldHdvcmsgcHJvdmlkZXIgb2ZmZXJlZCBUVVJOIHNl cnZlcj8gVGhlIG5ldHdvcmsgcHJvdmlkZXIgaGFuZHMgb3V0IGFuIElQIGFkZHJlc3MgYW5kIHdh bnRzIHRvIGFubm91bmNlIGEgcmVsYXRlZCBUVVJOIHNlcnZlciBhZGRyZXNzOiDigJMgSXMgdGhl cmUgYSDigJxQQUMtd2F54oCdIHRvIGFubm91bmNlIGl0IHRvIGEgZGV2aWNlIG9uIGEgTEFOIChi ZWhpbmQgYSBOQVQvZmlyZXdhbGwpPyBUaGUgZGV2aWNlIG11c3QgZmluZCBzdWNoIGNvbmZpZ3Vy YXRpb24gZmlsZSBiYXNlZCBvbiBpdHMgcHVibGljIElQIGFkZHJlc3MgKHRoYXQgaGUgY2FuIGZp bmQgdXNpbmcgU1RVTiBhcyBpbiB0aGUgc3VnZ2VzdGlvbiBiZWxvdykuDQoNCkJ1dCBnZW5lcmFs bHksIGZpbmRpbmcgYSBUVVJOLXNlcnZlciBpcyBhIG5ldHdvcmstdGhpbmcsIElDRSAob3IgZXZl biBUVVJOIG5vdCB1c2luZyBJQ0UpLCBub3QgYSBXZWItdGhpbmcsIHNvIGZvciB0aGF0IHJlYXNv biB0aGUgRE5TLUJhc2VkIFNlcnZpY2UgRGlzY292ZXJ5IG1ldGhvZCBpcyBhdCBhIGJldHRlciBs ZXZlbC4gU3VjaCBtZXRob2QgY291bGQgYWxzbyBiZSB1c2VkIGJ5IFNJUCBjbGllbnRzIChldmVu IGEgU2t5cGUgY2xpZW50IGNvdWxkIGltcGxlbWVudCBpdCB0byBiZW5lZml0IGZyb20gYSByZWFs LXRpbWUgcGF0aCB3aXRoIGJldHRlciBxdWFsaXR5LCBpZiB0aGUgbmV0d29yayBwcm92aWRlciBv ZmZlcnMgc3VjaCBwYXRoIHRocm91Z2ggaGlzIFRVUk4gc2VydmVyKS4NCg0KVGhlIEROUy1CYXNl ZCBTZXJ2aWNlIERpc2NvdmVyeSBtZXRob2Qgc2hvdWxkIGJlIGVhc3kgdG8gaW1wbGVtZW50IGlu IGEgV2ViUlRDIGJyb3dzZXIgKGRvaW5nIGNvbXBsZXggSUNFIHRoaW5ncyBhbnl3YXkpLiBUaGUg cXVlc3Rpb24gaXMgcmF0aGVyIGhvdyBlYXN5IGl0IGlzIGZvciB0aGUgbmV0d29yayBwcm92aWRl ciB0byBwcm92aXNpb24uIERvIHRoZXkgYWxsIGRvIHJldmVyc2UgRE5TIGxpa2Ugd2l0aCBmb3Vu ZCB3aXRoIG1vYmlsZSBvcGVyYXRvcnMgVGVsaWFTb25lcmEgYW5kIFRlbGUyIGluIFN3ZWRlbj8g VGhlbiBpdCBzaG91bGQgbm90IGJlIHRvbyBkaWZmaWN1bHQuDQoNCk9yIGlzIHRoZXJlIHlldCBh bm90aGVyIGJldHRlciBtZXRob2QgdG8gYW5ub3VuY2UgYSBUVVJOIHNlcnZlciBhZGRyZXNzIHdp dGggdGhlIElQIGFkZHJlc3Mgb2ZmZXJlZD8NCg0KL0thcmwNCg0KDQpGcsOlbjogcnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnJ0 Y3dlYi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZz5dIEbD tnIgQmVybmFyZCBBYm9iYQ0KU2tpY2thdDogZGVuIDI5IHNlcHRlbWJlciAyMDEzIDAyOjQxDQpU aWxsOiBIYXJhbGQgQWx2ZXN0cmFuZA0KS29waWE6IHJ0Y3dlYkBpZXRmLm9yZzxtYWlsdG86cnRj d2ViQGlldGYub3JnPg0KDQrDhG1uZTogUmU6IFtydGN3ZWJdIFRVUk4gc2VydmVyIGFkZHJlc3Mg dmlhIERIQ1AsIFdHTEMgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJl bWVudHMtMTENCg0KT24gU2VwIDI2LCAyMDEzIDg6NDYgUE0sICJIYXJhbGQgQWx2ZXN0cmFuZCIg PGhhcmFsZEBhbHZlc3RyYW5kLm5vPG1haWx0bzpoYXJhbGRAYWx2ZXN0cmFuZC5ubz4+IHdyb3Rl Og0KDQoiU28gZmFyLCBuZWl0aGVyIHRoZSBQT1NJWCBzdGFuZGFyZCBub3IgYW55IE9TIHZlbmRv ciBoYXMgb2ZmZXJlZCBhIGdlbmVyaWMgZmFjaWxpdHkgdG8gYWNjZXNzIGluZm9ybWF0aW9uIG1h ZGUgYXZhaWxhYmxlIGluIERIQ1AgcGFja2V0cy4iDQoNCltCQV0gVGhlIFdpbmRvd3MgREhDUCBj bGllbnQgQVBJIGRvZXMgcHJvdmlkZSB0aGlzOg0KaHR0cDovL21zZG4ubWljcm9zb2Z0LmNvbS9l bi11cy9saWJyYXJ5L3dpbmRvd3MvZGVza3RvcC9hYTM2MzM1MSh2PXZzLjg1KS5hc3B4DQoNCklu IHBhcnRpY3VsYXIsIHRoZSBTZW5kUGFyYW1zIGFyZ3VtZW50IHRvIHRoZSBEaGNwUmVxdWVzdFBh cmFtcyBmdW5jdGlvbiBjYW4gYmUgdXNlZCB0byByZXF1ZXN0IGEgcGFydGljdWxhciBwYXJhbWV0 ZXIgKGUuZy4gVFVSTiBzZXJ2ZXIgYWRkcmVzcyksIHdoaWNoIHdpbGwgdGhlbiBiZSByZXR1cm5l ZCBpbiB0aGUgUmVjZFBhcmFtcyB2YXJpYWJsZS4NCg0KTmV2ZXJ0aGVsZXNzLCBJIHN0aWxsIHRo aW5rIHRoYXQgdXNpbmcgREhDUCB0byBjb25maWd1cmUgdGhlIFRVUk4gc2VydmVyIGFkZHJlc3Mg aW4gYSBicm93c2VyIGlzbid0IGEgZ29vZCBpZGVhLiAgRm9yIG9uZSB0aGluZywgc2luY2UgREhD UCBpcyBlZmZlY3RpdmVseSB1bnNlY3VyZWQsIHRoaXMgbWVjaGFuaXNtIGNvdWxkIGJlIHVzZWQg YnkgYSByb2d1ZSBESENQIHNlcnZlciB0byBmb3JjZSB0cmFmZmljIHRvIGEgcm9ndWUgdHVybnNl cnZlci4gICBHcmVhdCBmb3Igc3VydmVpbGxhbmNlIQ0KDQoNCk9uIFNlcCAyNywgMjAxMyAxOjI3 IEFNLCAiS2FybCBTdGFobCIgPGthcmwuc3RhaGxAaW50ZXJ0ZXguc2U8bWFpbHRvOmthcmwuc3Rh aGxAaW50ZXJ0ZXguc2U+PiB3cm90ZToNCkhlcmUgY29tZXMgdGhlIHN1Z2dlc3Rpb24gSSBnb3Qg ZnJvbSBteSBkZXZlbG9wZXIgdGhhdCB3b3VsZCBhbGxvdyBhIG5ldHdvcmsNCnByb3ZpZGVyIHRv IG9mZmVyIGhpcyBUVVJOIHNlcnZlciBmb3IgdGhlIFdlYlJUQyBicm93c2VyIHRvIHVzZS4gVGhp cyB3b3VsZA0KcmVxdWlyZSBOTyBuZXcgREhDUC1vcHRpb25zIG9yIHNpbWlsYXIsIGFuZCBOTyBP UyBjaGFuZ2VzIChJIGRvIHJlYWxpemUNCnRob3NlIHNob3VsZCBiZSBhdm9pZGVkIGlmIHBvc3Np YmxlLi4uKS4NCg0KVGhlIGlkZWEgaXMgc3RpbGwsIHRoYXQgd2hvZXZlciBpcyByZXNwb25zaWJs ZSBmb3IgZ2l2aW5nIGEgZGV2aWNlIGFuIElQDQphZGRyZXNzICh0aGUgbmV0d29yayBwcm92aWRl ciBvciBhIExBTiBhZG1pbmlzdHJhdG9yKSBjYW4gYWxzbyBhbm5vdW5jZSBhDQpUVVJOIHNlcnZl ciBmb3IgdGhlIFdlYlJUQyBicm93c2VyIHRvIHVzZS4NCg0KVGhlIHN1Z2dlc3Rpb24gaXMgdG8g dXNlIFJGQzY3NjMgKEROUy1CYXNlZCBTZXJ2aWNlIERpc2NvdmVyeSwgc2VlIGNoYXB0ZXINCjEx KSB3aGVyZSB0aGUgbmV0d29yayBwcm92aWRlciAodGhlIG93bmVyIG9mIHRoZSBJUCBhZGRyZXNz KSBoYXMgc2V0IHVwIGENCkROUyBQVFIgcmVjb3JkIGZvciB0aGUgVFVSTiBzZXJ2ZXIgaW4gdGhl IGluLWFkZHIuYXJwYSBkb21haW4uDQoNCklmIHRoZSBkZXZpY2UgZ290IElQIDE3My4xNjQuMjUy LjE0OSwgdGhlbiBtYWtlIGEgcXVlcnkgZm9yIHRoZSBQVFIgcmVjb3JkDQpmb3I6DQpfdHVybi5f dWRwLjE0OS4yNTIuMTY0LjE3My5pbi1hZGRyLmFycGEuDQpUaGVuIHRoZSBTUlYgcmVjb3JkIHdv dWxkIHJldHVybiB0aGUgYWN0dWFsIGFkZHJlc3MgdG8gdGhlIFRVUk4gc2VydmVyIChhbmQNCnlv dSBtYXkgZmluZCBzZXZlcmFsIGZvciBsb2FkIGJhbGFuY2luZyBhbmQgZmFpbG92ZXIgSSBndWVz cykNCg0KSWYgdGhlIGRldmljZSBpcyBvbiBhIExBTiwgdGhlIElQIDE3My4xNjQuMjUyLjE0OSB0 byBxdWVyeSB3b3VsZCBiZSB0aGUgV0FODQpJUCB5b3UgZ2V0IHZpYSBTVFVOIGluIHRoZSBJQ0Ug cHJvY2Vzcy4gQnV0IGlmIHRoZSBMQU4gYWRtaW5pc3RyYXRvcg0KcHJvdmlkZXMgYSBsb2NhbCBU VVJOIHNlcnZlciwgdGhlbiBoZSBhbHNvIHNob3VsZCBoYXZlIGJsb2NrZWQgU1RVTiBpbiB0aGUN CmZpcmV3YWxsLCBhbmQgdGhlIGJyb3dzZXIgc2hvdWxkIHF1ZXJ5IHRoZSBkZXZpY2UncyBsb2Nh bCBob3N0IGFkZHJlc3MgKGFzDQppbiB0aGUgSUNFIHByb2NlZHVyZSkgYW5kIHRoZSBsb2NhbCBM QU4gRE5TIHNlcnZlciBzaG91bGQgYW5zd2VyIHRoZSBxdWVyeQ0KdG8gZ2l2ZSB0aGUgbG9jYWwg VFVSTiBzZXJ2ZXIgYWRkcmVzcyBvbiB0aGUgTEFOLg0KDQpTaG91bGRuJ3QgdGhpcyB3b3JrIHRv IGFsbG93IG5ldHdvcmsgcHJvdmlkZXIgdG8gb2ZmZXIgaGlzIFRVUk4gc2VydmVyDQoiYXV0b21h dGljYWxseSBhbmQgZ2VuZXJhbGx5Ij8NCg0KQW5kIHdvdWxkbid0IHRoaXMgd29yayBuaWNlbHkg Zm9yIG1vYmlsZSBkZXZpY2VzLCB3aGVuZXZlciB0aGUgZGV2aWNlIGlzIG9uDQphICJXZWJSVEMt cmVhZHkgYWNjZXNzIiAoYWN0dWFsbHkgZ29vZCBmb3IgZXZlcnl0aGluZyB1c2luZyBJQ0UpLCB3 aGV0aGVyDQpmaXhlZCwgV2lGaSBvciAzRy80RyBPVFQsIHlvdSBnZXQgYWxzbyBhIFRVUk4gc2Vy dmVyIChhbmQgdGhlIG5ldHdvcmsNCnByb3ZpZGVyIGhvcGVmdWxseSBvZmZlcnMgYSBwcmlvcml0 aXplZCBwaXBlIHRoZXJlIGFzIG9uZSB1c2FnZSBvZiB0aGlzDQptZWNoYW5pc20pLg0KTm90IHRv IHNsb3cgZG93biBldmVyeSBjYWxsIHNldHVwIGJ5IGRvaW5nIHRoaXMgaW4gdGhlIElDRSBwcm9j ZXNzLCBJIGd1ZXNzDQp0aGlzIGNvdWxkIGJlIGRvbmUgd2hlbiBzdGFydGluZyB0aGUgYnJvd3Nl ciBhbmQgd2hlbiB0aGUgZGV2aWNlIGdldHMgYSBuZXcNCklQIGFkZHJlc3MsIHRvIGhhdmUgdGhl IFRVUk4gc2VydmVyIGFkZHJlc3MgcmVhZHkgZm9yIGxhdGVyIHVzZS4NCi9LYXJsDQoNCg0K --_000_9F33F40F6F2CD847824537F3C4E37DDF17CED9A9MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4 dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUs IGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21z by1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWls eTpDb25zb2xhczt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWlu IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ bGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5PZm9ybWF0ZXJhZHRleHQsIGxpLk9mb3JtYXRlcmFk dGV4dCwgZGl2Lk9mb3JtYXRlcmFkdGV4dA0KCXttc28tc3R5bGUtbmFtZToiT2Zvcm1hdGVyYWQg dGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6Ik9mb3JtYXRlcmFkIHRleHQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uT2Zvcm1hdGVyYWR0ZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiT2Zvcm1hdGVyYWQgdGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6Ik9mb3JtYXRlcmFkIHRleHQiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzO30NCnAuQmFsbG9uZ3RleHQsIGxpLkJhbGxvbmd0ZXh0LCBkaXYu QmFsbG9uZ3RleHQNCgl7bXNvLXN0eWxlLW5hbWU6QmFsbG9uZ3RleHQ7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvbmd0ZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpzcGFuLkJhbGxvbmd0ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9u Z3RleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOkJh bGxvbmd0ZXh0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVt YWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibHVlO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOmJsdWU7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFs O30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsdWU7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYi Ow0KCWNvbG9yOmJsdWU7fQ0KcC5IVE1MLWZyZm9ybWF0ZXJhZCwgbGkuSFRNTC1mcmZvcm1hdGVy YWQsIGRpdi5IVE1MLWZyZm9ybWF0ZXJhZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCAtIGbDtnJm b3JtYXRlcmFkIjsNCgltc28tc3R5bGUtbGluazoiSFRNTCAtIGbDtnJmb3JtYXRlcmFkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUwt ZnJmb3JtYXRlcmFkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCAtIGbDtnJmb3JtYXRlcmFk IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCAt IGbDtnJmb3JtYXRlcmFkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1h aWxTdHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVw dCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWdyZWUg dGhhdCB0aGlzIGlzIHRvcCBwcmlvcml0eSBtaWxlc3RvbmUgZm9yIFRSQU0gYW5kIEkgYW0gd2ls bGluZyB0byBjb250cmlidXRlIHRvIHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JdCBpcyBncmVhdCB0byBoZXJl IHRoYXQgYSBkcmFmdCB3aWxsIGJlIHB1Ymxpc2hlZCBzb29uIG9uIHRoaXMgc3ViamVjdCBvbmx5 IHNvcnJ5IHRoYXQgSSBoYXZlIG5vdCBmb3VuZCB0aW1lIHRvIGRvIGl0IGJlZm9yZSBub3cuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0 cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5L YXJsIFN0YWhsPGJyPg0KPGI+U2VudDo8L2I+IDA4IEZlYnJ1YXJ5IDIwMTQgMTM6MTE8YnI+DQo8 Yj5Ubzo8L2I+IHRyYW1AaWV0Zi5vcmc7IHRpcmVkZHlAaWNpc2NvLmNvbTsgJ1NpbW9uIFBlcnJl YXVsdCc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZl ciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkthcmwgZnJvbSBJbmdhdGUgYW5kIEludGVydGV4IGp1c3Qg YWRkZWQgaGltc2VsZiB0byB0aGlzIGxpc3QgZm9yIGV4YWN0bHkgdGhlIHB1cnBvc2Ugb2YgdGhl IHN1YmplY3Qgb2YgTWlsZXN0b25lIDMgYWJvdmUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JIHdlbGNvbWUgdGhpcyBpbml0aWF0aXZl IHRoYXQgSSBzYXcgeWVzdGVyZGF5IGFmdGVyIGJlaW5nIHJlbWluZGVkIGJ5IENoaW5hIE1vYmls ZSBSZXNlYXJjaCBJbnN0aXR1dGUgd2hvIGhhZCBzZWVuIHRoZSBwcmV2aW91cyBPY3RvYmVyIGRp c2N1c3Npb24gb24gdGhlIFdlYlJUQy1saXN0LA0KIHBhcnRzIG9mIHdoaWNoIGFyZSBpbnNlcnRl ZCBiZWxvdy4gTGFyZ2UgY2FycmllcnMgaGF2ZSBhbHNvIGV4cHJlc3NlZCB0aGUgaW1wb3J0YW5j ZSBvZiB0aGlzIG1pbGVzdG9uZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0tLS0tLS0tLS0t LS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPldlIGFyZSB3b3JraW5nIG9uIHRoaXMgZHJhZnQsIHdpbGwgcHVibGlzaCBpdCBuZXh0 IHdlZWsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPi1UaXJ1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj5HcmVhdCwgcGxlYXNlIGNvbnNpZGVyIHRoZSBpbnB1dCBh bmQgc3VnZ2VzdGlvbnMgYmVsb3c6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsg RnJvbTogdHJhbSBbPC9zcGFuPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOnRy YW0tYm91bmNlcyI+PHNwYW4gbGFuZz0iRU4tVVMiPm1haWx0bzp0cmFtLWJvdW5jZXM8L3NwYW4+ PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+DQogYXQgaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTaW1vbiBQ ZXJyZWF1bHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jmd0OyBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA3LCAyMDE0IDc6NTggUE08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBUbzog dHJhbSBhdCBpZXRmLm9yZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mZ3Q7IFN1YmplY3Q6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2 ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7IGVudGVycHJpc2UgYW5kIElTUHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyA8 bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij7i gKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jmd0OyBFbnRlcnByaXNlcyBvciBJU1BzIHdpc2hpbmcgdG8gcHJvdmlkZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7IHRoZWlyIG93biBU VVJOIHNlcnZlciwgaW4gYW4gYXR0ZW1wdCB0byByZWR1Y2Ugc28tY2FsbGVkICZxdW90O3RyaWFu Z2xlIHJvdXRpbmcmcXVvdDssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZndDsgbmVlZCBhIG5ldyBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tLS0gVGhlcmUgYXJlIG1vcmUgcmVhc29ucyBoZWFy ZCBmb3IgYXV0by1kaXNjb3Zlcnkgb2YgYSBuZXR3b3JrIHByb3ZpZGVkIFRVUk4gc2VydmVyOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4t IE5TUHMgKE5ldHdvcmsgU2VydmljZSBQcm92aWRlcnMpIHdhbnQgdG8gcHJvdmlkZSBhIHBhdGgg d2hlcmUgdGhlIGJhbmR3aWR0aCBvZiBXZWJSVEMgaXMgYmV0dGVyIGNvcGVkIHdpdGguPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibHVlIj4tIE5TUHMgb3IgRW50ZXJwcmlzZXMgd2FudCB0byBvZmZlciBh biBJbnRlcm5ldCBhY2Nlc3MgcXVhbGl0eSBwaXBlIGZvciBwcmlvcml0aXplZCBSVEMgKFJlYWwg VGltZSBDb21tdW5pY2F0aW9uKSB0cmFmZmljLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4t IEVudGVycHJpc2VzIGhhdmluZyByZXN0cmljdGl2ZSBmaXJld2FsbHMsIHdhbnQgdG8gcHJvdmlk ZSBhIFVEUC1wYXRoIGZvciBXZWJSVEMgYW5kIHBvc3NpYmx5IGFsc28gZm9yIGJldHRlciBxdWFs aXR5IHdoZXJlIFJUQyBkbyBub3QgY29tcGV0ZSB3aXRoIGRhdGEgdHJhZmZpYy4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+LSBNb2JpbGl0eTsgSXQgaXMgY29tbW9uIHRvIG1vdmUgZnJvbSBh IExBTiB0byBhY2Nlc3NpbmcgdmlhIFdpRmkgb3IgM0cvNEcgT1RUIGNoYW5uZWxzLCBhbGwgc2hv dWxkIGJlIGFibGUgdG8gYXV0b21hdGljYWxseSBvZmZlciB0aGVpciBvd24gb3B0aW1hbCBUVVJO IHNlcnZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj4tIE5vdGUgdGhhdCB0byBhY2hpZXZlIHNvbWUgb2YgdGhlIGFib3ZlIHBvaW50cywg VFVSTiBtdXN0IGJlIGZhdm9yZWQgb3ZlciBTVFVOIHRvIGVuZm9yY2UgdGhhdCB0aGUgVFVSTi1w YXRoIGFjdHVhbGx5IGlzIHVzZWQuIChUaGUgQW55Y2FzdCBtZXRob2Qgc3VnZ2VzdGVkIGJlbG93 LA0KIOKAnGF1dG9tYXRpY2FsbHnigJ0gZG9lcyB0aGlzLikgPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0tIEluIG15IHZpZXcsIGEgVFVS TiBzZXJ2ZXIgaXMgdGhlIG5ldHdvcmsgcHJvdmlkZXJz4oCZIHJlc3BvbnNpYmlsaXR5IHRvIHBy b3ZpZGUgKGp1c3QgbGlrZSB0aGUgSVAgYWRkcmVzcywgdGhlIGRlZmF1bHQgZ2F0ZXdheSwgdGhl IEROUyBldGMuKSDigJMgcmF0aGVyIHRoYW4gdGhlDQogYXBwbGljYXRpb24gcHJvdmlkZXLigJlz LiBPdXIgY3VycmVudCBJbnRlcm5ldCBhY2Nlc3NlcyBtYXkgbm90IGNvcGUgd2l0aCBvciBiZSBv cHRpbWl6ZWQgZm9yIFdlYlJUQyB1c2FnZSDigJMgVGhlIE5TUCAob3IgRW50ZXJwcmlzZSBMQU4g YWRtaW5pc3RyYXRvcikgc2hvdWxkIHRoZW4gYmUgYWJsZSB0byBmaXggdGhlIGFjY2VzcyAoaGVy ZSBieSBvZmZlcmluZyBhIFRVUk4gc2VydmVyKS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBJTUhPIHRoaXMgaXMgYWxzbyBh IHRvcC1wcmlvcml0eSBtaWxlc3RvbmUuIFdlIG5lZWQgdG8gcXVpY2tseSBoYXZlIGE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyBtZWNo YW5pc20gdGhhdCBwZW9wbGUgY2FuIGltcGxlbWVudCBpbiBXZWJSVEMgYnJvd3NlcnMgbm93LCB3 aGlsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mZ3Q7IHRoZXJlIGlzIHN0aWxsIGZyZW5ldGljIGRldmVsb3BtZW50IGhhcHBlbmluZy4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LS0tIEFncmVlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+SSBkb24ndCBm b3Jlc2VlIGFjdHVhbCBzZXJ2ZXItPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZndDsgc2lkZSBkZXBsb3ltZW50IGhhcHBlbmluZyBxdWlja2x5 IHRob3VnaC4gQnV0IGFzIHNvb24gYXMgY2xpZW50cyBhcmUgcmVhZHksPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsgYW55IElTUCBvciBl bnRlcnByaXNlIGNhbiBkZXBsb3kgYW5kIGltbWVkaWF0ZWx5IGJlbmVmaXQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj4tIFRoZXJlIGlzIGEgZGVmaW5pdGl2ZSBpbnRlcmVzdCBhbW9uZyBmb3J3 YXJkIFNQcyBhbHJlYWR5LCBlc3BlY2lhbGx5IGNhcnJpZXJzIG93bmluZyB0aGUgbmV0d29yay48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPihUaGV5IGhhdmUgbGVhcm5lZCB0aGF0IHRoZWlyIG5l dHdvcmtzIChlc3BlY2lhbGx5IG1vYmlsZSkgc2VlbSB0byBiZWNvbWUgZGF0YSBjcm93ZGVkIG5v IG1hdHRlciBob3cgbXVjaCBiYW5kd2lkdGggdGhleSBpbnZlc3QgaW4uKTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mZ3Q7IEkgaW1hZ2luZSB0aGF0IHRoZSBzb2x1dGlvbiB3aWxsIGJlIGZhaXJseSBzaW1w bGUsIHNwZWMtIGFuZCBpbXBsZW1lbnRhdGlvbi08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jmd0OyB3aXNlLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj4tLS0gQWdyZWUgdGhhdCBzdWNoIHNvbHV0aW9uIHNob3VsZCBhbmQgY291bGQgYmUg Zm91bmQsIGJ1dCBpdCBpcyBub3Qgb2J2aW91cy4gQmVsb3cgeW91IGZpbmQgMyBwcm9wb3NhbHMg KGluaXRpYXRlZCBieSBtZSBvciBjb2xsZWFndWVzLCB3aGVyZSBJIHNlZSBmbGF3cyBpbiB0aGUN CiB0d28gZmlyc3QgYW5kIG5vdyBvbmx5IHN1Z2dlc3QgdGhlIHRoaXJkICh0aGUgQW55Y2FzdCBt ZWNoYW5pc20pLiBGcm9tIGJlbG93OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIDE8c3VwPnN0PC9zdXA+OiDigKYgd2l0aGRyYXcgbXkg c3VnZ2VzdGlvbiB0byB1c2UgREhDUCB0byBmaW5kIGEgbmV0d29yayBwcm92aWRlciBvZmZlcmVk IFRVUk4gc2VydmVyIGluIGZhdm9yIG9mIHRoZSBETlMtQmFzZWQgU2VydmljZSBEaXNjb3Zlcnkg bWV0aG9kIChpbnNlcnRlZA0KIGxhc3QgYmVsb3cpLiBUaGUgbWFqb3IgcHJvYmxlbSB3aXRoIHRo ZSBESENQIHVzYWdlIHdhcyB0aGF0IHlvdSB0aGVuIGFsc28gaGF2ZSB0byBkbyBzb21ldGhpbmcg c2ltaWxhciBmb3I6IFJBIC0gUm91dGVyIEFkdmVydGlzZW1lbnQgLSBpbiBJUHY2LCBhZGRpdGlv biB0byB0aGUgSVBDUCBwcm90b2NvbCBmb3IgUFBQb0UgYW5kIHNvbWV0aGluZyBmb3IgdGhlIG1v YmlsZSBPVFQgY2hhbm5lbCDigJMgd2hlcmV2ZXIgREhDUCBpcyBOT1QgdGhlIG1ldGhvZA0KIHRv IGdpdmUgeW91IGFuIElQIGFkZHJlc3MuIChUaGVyZSB3ZXJlIGFsc28gY29uY2VybnMgd2hldGhl ciBPU3MgYWN0dWFsbHkgc3VwcG9ydHMgZm9yd2FyZHMgc3VjaCBleHRlbmRlZCBESENQIGluZm9y bWF0aW9uIGZvciB0aGUgYnJvd3NlciB0byB1c2UuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIDI8c3VwPm5kPC9zdXA+IFJldmVyc2Ug RE5TLUJhc2VkIFNlcnZpY2UgRGlzY292ZXJ5IG1ldGhvZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPkp1c3RpbiBVYmVydGkgcG9pbnRlZCBvdXQ6ICZuYnNwOzwvc3Bhbj5Ib3cgZG9lcyB0aGlz IGdldCBib290c3RyYXBwZWQ/IFRoYXQgaXMsIGhvdyBpcyB0aGUgU1RVTiBzZXJ2ZXIgZm91bmQ/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPltLYXJsXSBPb3BzLCB0aGF0IGdvdCBsb3N0IHdoZW4gbGVhdmlu ZyB0aGUgREhDUCB0cmFjaywgYW5kIGlzIGEgcHJvYmxlbSB3aGVuIHVzaW5nIEROUyBkaXNjb3Zl cnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4oVGhlcmUgd2VyZSBhbHNvIGhlc2l0YXRpb25z IG9mIGhhdmluZyB0byBwcm92aXNpb24gdGhpcyBzcGVjaWFsIHJldmVyc2UgRE5TIGZvciBldmVy eSBhY2Nlc3MuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj4tIDM8c3VwPnJkPC9zdXA+IFRoZSBBbnljYXN0IG1ldGhvZCBiZWxvdyDigJMg SSBzZWUgbm8gcHJvYmxlbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SXQgYWxzbyBoYXMgdGhl IGFkdmFudGFnZSBvZiBlbmNvdXJhZ2luZyAoYnV0IG5vdCByZXF1aXJpbmcpIHRoZSBTVFVOL1RV Uk4gdG8gYmUgYnVpbHQgaW4gdGhlIGRlZmF1bHQgZ2F0ZXdheSBvciBOQVQvZmlyZXdhbGwvYWNj ZXNzIHJvdXRlciBpdHNlbGYsIHdpdGggYSBzZWNvbmQNCiBpbnRlcmZhY2UgdG8gYSBwdWJsaWMg SVAgYWRkcmVzcyBvbiB0aGUgV0FOIHNpZGUuIChDdXJyZW50IHZvbHVtZSBkZXBsb3llZCwgbG93 IGNvc3QgTlNQIHRyaXBsZSBwbGF5IG1vZGVtcyB1c3VhbGx5IGhhdmUgYSBxdWFsaXR5IGFzc3Vy ZWQgbGV2ZWwgMiBvciBsZXZlbCAzIFdBTiBwaXBlIGZvciBqdXN0IHZvaWNlIChhbmQgYW5vdGhl ciBmb3IgSVBUVikg4oCTIFRoZSBhbnljYXN0IGRpc2NvdmVyZWQgVFVSTi1zZXJ2ZXIgY2FuIGJl IHRoZSBhY2Nlc3MNCiBnYXRld2F5IHRvIHN1Y2ggcXVhbGl0eSBwaXBlIGZvciBXZWJSVEMgbWVk aWEsIGluIGEgc2luZ2xlIE5TUCBwcm92aWRlZCBDUEUsIHNjYWxpbmcgZnJvbSByZXNpZGVudGlh bCBhbmQgdXAuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+U28gSSB0aGluayB3ZSBjYW4gZmluaXNoIHRoaXMgdmVyeSBxdWlja2x5IG9u Y2Ugd2UgaGF2ZSBhIGNhbmRpZGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mZ3Q7IGRyYWZ0LiBXZSBqdXN0IG5lZWQgYXV0aG9ycy4gU28g SSB3b3VsZCB0YXJnZXQgbm90IGxvbmcgYWZ0ZXIgVG9yb250by48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZndDsNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jmd0OyBTaW1vbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj5XRUIgQlJPV1NFUiBCRUhBVklPVVI6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPk5ldHdvcmsgcHJvdmlkZWQgVFVS TiBzZXJ2ZXJzIHdpbGwgbm90IGFwcGVhciBvdmVyIG5pZ2h0LCBhcHBsaWNhdGlvbnMgbWF5IGZv ciBsb25nIHByb3ZpZGUgYSBUVVJOIHNlcnZlciBhZGRyZXNzLCBhbmQgdGhlcmUgYXJlIGV4Y2Vw dGlvbnMgd2hlcmUgdGhlIFRVUk4gc2VydmVyDQogYWRkcmVzcyBpcyBwcmVmZXJyZWQgdG8gYmUg 4oCcbWFudWFsbHnigJ0gY29uZmlndXJlZC4gSXQgaXMgcHJldmlvdXNseSBzdWdnZXN0ZWQsIGFu ZCB0byBzb21lIGV4dGVudCBkaXNjdXNzZWQsIHRoYXQgdGhlIFdlYlJUQyBicm93c2VyIHNob3Vs ZCBzZWxlY3QgdGhlIFRVUk4gc2VydmVyIHRvIHVzZSBpbiB0aGUgZm9sbG93aW5nIHByaW9yaXR5 IG9yZGVyLCB3aGVyZSBJQ0Ugd291bGQgYXNzdXJlIHRoYXQgeW91IGdldCBzb21lIGNvbm5lY3Rp dml0eQ0KIGlmIHNldmVyYWwgY2FuZGlkYXRlcyBhcmUgZm91bmQgYW5kIG5lZWRzIHRvIGJlIHRl c3RlZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+MSkgVFVSTiBzZXJ2ZXIgYWRkcmVzcyBjb25maWd1cmVkIGluIHRoZSBicm93c2VyIGJ5 IHRoZSB1c2VyIChzcGVjaWFsIGNhc2VzLCBub3JtYWxseSBub3QgdXNlZCwgYnV0IGhhbmR5IGZv ciB0ZXN0aW5nKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+MikgVFVSTiBzZXJ2ZXIgYWRkcmVz cyBjb25maWd1cmVkIGJ5IHRoZSBuZXR3b3JrIGFkbWluaXN0cmF0b3IgdmlhIGFuIOKAnGFkbWlu IHBvbGljeSB0ZW1wbGF0ZeKAnSBvciBhIFdQQUQgbWV0aG9kIGFzIG1lbnRpb25lZCBiZWxvdzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+MykgVFVSTiBzZXJ2ZXIgYWRkcmVzcyBhdXRvLWRpc2Nv dmVyZWQgYnkgdGhlIG1lY2hhbmlzbSBkaXNjdXNzZWQgaGVyZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+NCkgVFVSTiBzZXJ2ZXIgYWRkcmVzcyBiZWluZyBzdXBwbGllZCBieSB0aGUgd2ViIGFw cGxpY2F0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPldpdGggYSBnb29kIHN0ZXAgMyksIHN0ZXAgMikgYmVjb21lcyBvYnNvbGV0ZSBz aW5jZSB0aGUgbmV0d29yayBhZG1pbmlzdHJhdG9yIGUuZy4gc2ltcGx5IGNhbiBzZXQgYSByb3V0 ZSBpbiB0aGUgZW50ZXJwcmlzZSBmaXJld2FsbCB0byB1c2UgdGhlIEFueWNhc3QgbWVjaGFuaXNt DQogaW5zdGVhZC4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPkV2ZW4gaWYgdGhlIG5lZWQgZm9yIGF1dG8tZGlzY292ZXJ5IG9mIHRoZSBU VVJOIHNlcnZlciBjb21lcyBmcm9tIFdlYlJUQyB1c2FnZSwgYSBnZW5lcmFsIG1lY2hhbmlzbSB0 aGF0IGFsc28gY2FuIGJlIHVzZWQgYnkgU0lQIGNsaWVudHMgKGFuZCBvdGhlciBwcm90b2NvbHMg dXNpbmcNCiBUVVJOIHZpYSBJQ0UpIGlzIHByZWZlcmFibGUuIFRoZSBhbnljYXN0IG1ldGhvZCBo YXMgbm8gYXBwbGljYXRpb24gZGVwZW5kZW5jZSwgYnV0IGUuZy4gV1BBRCBoYXMgKGEgU0lQIENs aWVudCB0eXBpY2FsbHkgZG9lcyBub3QgaGF2ZSB0aGUgbHV4dXJ5IG9mIGEgSlMgZW5naW5l4oCm KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVl Ij4vS2FybDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5GcsOlbjo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gS2FybCBTdGFobCBbPC9zcGFuPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOmthcmwuc3RhaGxAaW50ZXJ0 ZXguc2UiPjxzcGFuIGxhbmc9IkVOLVVTIj5tYWlsdG86a2FybC5zdGFobEBpbnRlcnRleC5zZTwv c3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+DQo8Yj5T a2lja2F0OjwvYj4gZGVuIDIyIG9rdG9iZXIgMjAxMyAxNjozNzxicj4NCjxiPlRpbGw6PC9iPiAn SnVzdGluIFViZXJ0aSc7ICdDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSknPGJyPg0KPGI+S29waWE6 PC9iPiAnQmVybmFyZCBBYm9iYSc7ICdIYXJhbGQgQWx2ZXN0cmFuZCc7ICdkcmFmdC1pZXRmLXJ0 Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50c0B0b29scy5pZXRmLm9yZyc7ICdydGN3ZWJA aWV0Zi5vcmcnPGJyPg0KPGI+w4RtbmU6PC9iPiBbcnRjd2ViXSBbbW11c2ljXSBBbnljYXN0IGRp c2NvdmVyeSwgV2FzIFRVUk4gc2VydmVyIGFkZHJlc3MgdmlhIERIQ1AsIFdHTEMgb2YgZHJhZnQt aWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPlNlZSBteSBjb21tZW50cyBiZWxvdy4gVGhlIHByb2JsZW0gb2YgaGF2aW5n IHRvIGtub3cgYSBmaXJzdCBTVFVOIHNlcnZlciBpbiBvcmRlciB0byB1c2UgRE5TIGRpc2NvdmVy eSwgbWFrZXMgdGhlIHN1Z2dlc3Rpb25zIGJlbG93IGxlc3MgZ29vZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+QW5vdGhlciBpZGVhIGNh bWUgdXA7IHRvIHVzZSBhbnljYXN0IHRvIGFsbG93IGEgV2ViUlRDIGJyb3dzZXIgdG8gZmluZCBh IG5ldHdvcmsgcHJvdmlkZWQgVFVSTiBzZXJ2ZXIgKGJvdGggbG9jYWwgb24gYSBMQU4gb3IgcHJv dmlkZWQgYnkgYSBjYXJyaWVyKS4gKFRoZXJlIGFyZQ0KIHNvbWUgZGlzY3Vzc2lvbiBhcm91bmQg dXNpbmcgYW55Y2FzdCBpbiB0aGUgU1RVTiBhbmQgVFVSTiBSRkNzLikgVGhpcyBhbnljYXN0LXdh eSBzaG91bGQgd29yayBib3RoIGZvciBhIFRVUk4gc2VydmVyIG9uIGEgTEFOIGFuZCBhIFRVUk4g c2VydmVyIG91dHNpZGUgdGhlIE5BVC9GaXJld2FsbCAoYW55IHJvdXRlciBpbiB0aGUgY2hhaW4g Y2FuIHRha2UgY2FyZSBvZiBhbiBhbnljYXN0IGFkZHJlc3MpIGFuZCBieSB0aGUgc2ltcGxlIG1l dGhvZA0KIGJlbG93LCByZXR1cm4gdGhlIGF2YWlsYWJsZSBUVVJOIHNlcnZlciBjbG9zZXN0IHRv IHRoZSBjbGllbnQuIEZpbmRpbmcgYSBUVVJOIHNlcnZlciBjbG9zZSB0byB0aGUgY2xpZW50ICh0 aGUgV2ViUlRDIGJyb3dzZXIpIHdpbGwgYWxzbyBtaW5pbWl6ZSDigJx0aGUgdHVybuKAnSB0aGUg cmVhbC10aW1lIHRyYWZmaWMgaGFzIHRvIHRha2UuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhlIHN1Z2dlc3Rpb24gaXMg dG8gZGVmaW5lIGFuIGFueWNhc3QgSVAgYWRkcmVzcyBmb3IgU1RVTiBzZXJ2ZXJzIGFuZDo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0gVGhlIG5ldHdvcmsgcHJvdmlkZXIsIG9mZmVyaW5nIGEg VFVSTiBzZXJ2ZXIgb24gaGlzIGFjY2VzcywgYWRkcyBhIHJvdXRlIGluIGhpcyBhY2Nlc3Mgcm91 dGVyIChvciBOQVQvRmlyZXdhbGwpIHNvIHRoYXQgdGhlIGFueWNhc3QgYWRkcmVzcyByb3V0ZXMg dG8gaGlzIFRVUk4vU1RVTg0KIHNlcnZlciAoYSBUVVJOIHNlcnZlciBpcyBhbiBleHRlbnNpb24g b2YgU1RVTiBzZXJ2ZXIsIHRodXMgaW5jbHVkZWQgaW4gdGhlIHNhbWUgYm94KS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsdWUiPi0gVGhlIFRVUk4vU1RVTiBzZXJ2ZXIgaXMgY29uZmlndXJlZCB0byBy ZXNwb25kIHRvIGEgYmluZGluZyByZXF1ZXN0IHdpdGggYSDigJwzMDAgVHJ5IGFsdGVybmF0ZSBz ZXJ2ZXLigJ0sIHRoYXQgcG9pbnRzIG91dCB0aGUgc2FtZSBUVVJOL1NUVU4gc2VydmVyIChieSBp dHMgcmVhbCBJUA0KIGFkZHJlc3MsIG5vdCB0aGUgYW55Y2FzdCBhZGRyZXNzKS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhlIFdlYlJU QyBicm93c2VyIGNsaWVudCB3b3VsZCB0aGVuOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LSBJ c3N1ZSBhIFNUVU4gYmluZGluZyByZXF1ZXN0IHRvIHRoZSBhbnljYXN0IGFkZHJlc3M8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPi0gSXNzdWUgYW5vdGhlciBTVFVOIGJpbmRpbmcgcmVxdWVzdCB0 byB0aGUgQUxURVJOQVRFIFNFUlZFUiBJUCBhZGRyZXNzIGluIHRoZSDigJwzMDAgVHJ5IGFsdGVy bmF0ZeKAnSByZXNwb25zZSAoYXMgYW55IGNsaWVudCBzaG91bGQgZG8pLg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj4tIEludGVycHJldCB0aGUgcmVjZWl2ZWQg4oCcMzAwIFRyeSBhbHRlcm5h dGXigJ0gcmVzcG9uc2Ugbm93IGhhdmluZyB0aGUgc2FtZSBBTFRFUk5BVEUgU0VSVkVSIElQIGFk ZHJlc3MgYXMgdGhlIHNvdXJjZSBJUCBhZGRyZXNzIG9mIHRoYXQgcmVzcG9uc2UsIGFzIGFuIGlu ZGljYXRpb24NCiB0byB1c2UgaXRzIFRVUk4gc2VydmVyIChub3QgdGhlIFNUVU4gc2VydmVyKSBh dCB0aGF0IGFkZHJlc3MuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibHVlIj5UaGF0IGlzIHRoZSBUVVJOIHNlcnZlciB0byB1c2UhPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlRoZSBvbmx5 IGFkZGl0aW9uIHRvIGV4aXN0aW5nIHN0YW5kYXJkcyBpcyB0aGUgaW50ZXJwcmV0YXRpb24gYWJv dmUgb2YgdGhlIOKAnDMwMCBUcnkgYWx0ZXJuYXRl4oCdIHJlc3BvbnNlIGluIHRoZSBTVFVOIFJD RiA1NzY2IGhhdmluZyB0aGUgc2FtZSBBTFRFUk5BVEUgU0VSVkVSIElQDQogYWRkcmVzcyBhcyB0 aGUgc291cmNlIElQIGFkZHJlc3Mgb2YgdGhlIHJlc3BvbnNlLiBJdCBtZWFuczogVXNlIHRoZSBU VVJOIHNlcnZlciBhdCB0aGUgc3BlY2lmaWVkIGFkZHJlc3MuIFRoYXQgc2hvdWxkIGJlIGVhc3kg dG8gY2xhcmlmeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPihUaGUgU1RVTiBzZXJ2ZXIgYXQg dGhlIGFueWNhc3QgYWRkcmVzcywgbWF5IG9yIG1heSBub3QgYmUgdGhlIHNhbWUgVFVSTi9TVFVO IHNlcnZlciB1c2VkIGluIHNlY29uZCBiaW5kaW5nIHJlcXVlc3QuKQ0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkF1dGhlbnRpY2F0aW9u IGNvdWxkIHNpbXBseSBiZSB0aGF0IHRoZSBUVVJOL1NUVU4gc2VydmVyIG9ubHkgaXMgcmVhY2hh YmxlIGZyb20gdGhlIElQIGFkZHJlc3NlcyB0aGF0IHRoZSBuZXR3b3JrIHByb3ZpZGVyIHdhbnQg dG8gc3VwcG9ydCB3aXRoIHRoZSBUVVJOIHNlcnZlciAoZWFzeQ0KIGZvciB0aGUgbmV0d29yayBw cm92aWRlciwgc2luY2UgaGUgaXMgaGFuZGluZyBvdXQgdGhvc2UgSVAgYWRkcmVzc2VzKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhp cyBzaG91bGQgYmUgZWFzeSB0byBwcm92aXNpb24gZm9yIGEgY2FycmllciBvciBhIExBTiBhZG1p bmlzdHJhdG9yIGFuZCB0cml2aWFsIHRvIHRyeSBmb3IgdGhlIFdlYlJUQyBicm93c2VyLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5BbiBh ZHZhbnRhZ2UgaXMgdGhhdCB0aGUgdHdvIFNUVU4gYmluZGluZyByZXF1ZXN0cyBkaXJlY3RseSBy ZXR1cm5zIHRoZSBUVVJOIHNlcnZlciBhZGRyZXNzLCB3aGVyZWJ5IHRoZSBmb2xsb3dpbmcgSUNF IHByb2Nlc3Mgc2hvdWxkIGJlIHF1aWNrIGFuZCBlYXN5LiBUaGlzIGNvdWxkDQogYWxzbyBiZSBk b25lIG9ubHkgb25jZSB3aGVuIHRoZSBicm93c2VyIGlzIHN0YXJ0ZWQgb3IgZ2V0IGEgbmV3IElQ IGFkZHJlc3MgYW5kIGNhc2hlZCBmb3IgbGF0ZXIgY2FsbHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi9LYXJsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlBTIElmIHlvdSB3 b25kZXIgd2h5IG5vdCBkZWZpbmUgYW4gYW55Y2FzdCBhZGRyZXNzIGZvciBhIFRVUk4gc2VydmVy IGluc3RlYWQsIHJlYWQgdGhpcyB0aHJlYWQgZnJvbSAyMDA4OiZuYnNwOw0KPC9zcGFuPjxzcGFu IGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvYmVoYXZlL2N1cnJlbnQvbXNnMDM1ODIuaHRtbCI+PHNwYW4g bGFuZz0iRU4tVVMiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9iZWhhdmUv Y3VycmVudC9tc2cwMzU4Mi5odG1sPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Lg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPlRoZXJlLCB0aGUgdXNlIG9mIGFu eWNhc3QgdG8gYSBUVVJOIHNlcnZlciBpcyBkaXNjdXNzZWQsIGJ1dCBmb3VuZCBub3QgdG8gd29y ay4gKEhlcmUgYW55Y2FzdCBpcyBvbmx5IHVzZWQgZm9yIHRoZSBmaXJzdCByZXF1ZXN0IHRvIHRo ZSBTVFVOIHNlcnZlciwgd2hlcmUgYWZ0ZXIgdGhlIHJlYWwgYWRkcmVzcyB0byB0aGUgVFVSTi9T VFVOIHNlcnZlciBpcyB1c2VkLik8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnLDpW46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEp1c3RpbiBVYmVy dGkgWzwvc3Bhbj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9 Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iPjxzcGFuIGxhbmc9IkVOLVVTIj5tYWlsdG86anVi ZXJ0aUBnb29nbGUuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPl0NCjxicj4NCjxiPlNraWNrYXQ6PC9iPiBkZW4gOCBva3RvYmVyIDIwMTMgMDg6MTc8YnI+ DQo8Yj5UaWxsOjwvYj4gS2FybCBTdGFobDxicj4NCjxiPktvcGlhOjwvYj4gQmVybmFyZCBBYm9i YTsgSGFyYWxkIEFsdmVzdHJhbmQ7IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KTsgPC9zcGFuPg0K PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86ZHJh ZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHNAdG9vbHMuaWV0Zi5vcmci PjxzcGFuIGxhbmc9IkVOLVVTIj5kcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVp cmVtZW50c0B0b29scy5pZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij47DQo8L3NwYW4+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+cnRj d2ViQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pjxicj4NCjxiPsOEbW5lOjwvYj4gUmU6IFtydGN3ZWJdIFttbXVzaWNdIFRVUk4gc2VydmVyIGFk ZHJlc3MgdmlhIERIQ1AsIFdHTEMgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1y ZXF1aXJlbWVudHMtMTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgT2N0IDcsIDIwMTMgYXQgNjoyMSBBTSwg S2FybCBTdGFobCAmbHQ7PHNwYW4gbGFuZz0iU1YiPjxhIGhyZWY9Im1haWx0bzprYXJsLnN0YWhs QGludGVydGV4LnNlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmthcmwuc3Rh aGxAaW50ZXJ0ZXguc2U8L3NwYW4+PC9hPjwvc3Bhbj4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Ymx1ZSI+U28gdGhlIFdQQUQtd2F5IG9mIGdldHRpbmcgYSBuZXR3b3Jr IHByb3ZpZGVy4oCZcyBUVVJOIHNlcnZlciBhZGRyZXNzIGZvciB0aGUgcmVhbCAod2hpdGUsIGds b2JhbCkgSVAgYWRkcmVzcw0KIGhlIGhhcyBoYW5kZWQgb3V0IHRvIGEgdXNlciwgdGhlIGJyb3dz ZXIgd291bGQ6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0gVXNlIFNUVU4gdG8gZmluZCB0 aGUgZ2xvYmFsIElQIGFkZHJlc3MgKGRvbmUgYW55d2F5IGluIElDRSk8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93 IGRvZXMgdGhpcyBnZXQgYm9vdHN0cmFwcGVkPyBUaGF0IGlzLCBob3cgaXMgdGhlIFNUVU4gc2Vy dmVyIGZvdW5kPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5bS2FybF0gT29wcywgdGhhdCBnb3QgbG9zdCB3 aGVuIGxlYXZpbmcgdGhlIERIQ1AgdHJhY2ssIGFuZCBpcyBhIHByb2JsZW0gd2hlbiB1c2luZyBE TlMgZGlzY292ZXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi Pi0gRG8gYSByZXZlcnNlIEROUyBsb29rdXAgKGluc3RlYWQgb2YgdGhlIEROUy1CYXNlZCBTZXJ2 aWNlIERpc2NvdmVyeSB0aGF0IGlzIG5vdCB5ZXQgZGVwbG95ZWQpPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPi0gTWFrZSBhIFVSTCBiYXNlZCBvbiB0aGUgaG9zdG5hbWUgZnJvbSB0aGUgcmV2 ZXJzZSBETlMgbG9va3VwLCBlLmcuIGZyb20NCjxhIGhyZWY9Imh0dHA6Ly8xNzkuc3ViLTE3NC0y NTItMzUubXl2encuY29tIiB0YXJnZXQ9Il9ibGFuayI+MTc5LnN1Yi0xNzQtMjUyLTM1Lm15dnp3 LmNvbTwvYT4sIG1ha2UgaCB0dHA6Ly88YSBocmVmPSJodHRwOi8vdHVybmFkLm15dnp3LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnR1cm5hZC5teXZ6dy5jb208L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgd2FzIGhvcGluZyB3ZSBjb3VsZCBkbyBzb21ldGhpbmcgc2ltcGxlciwgc3VjaCBh cyB1c2luZyB0aGUgSVNQJ3MgY29uZmlndXJlZCBkb21haW4gc2VhcmNoIGxpc3QsIHRvIGRldGVy bWluZSB0aGUgZG9tYWluLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PHNwYW4gc3R5bGU9 ImNvbG9yOmJsdWUiPltLYXJsXSBCdXQgY2FycmllcnMgZG9u4oCZdCBwdXNoIG91dCBzdWNoIHRo aW5ncywgZG8gdGhleT8gQW5kIGlmIHRoZXkgY291bGQgZG8gaXQgdmlhIERIQ1Agd2UgYXJlIGJh Y2sgd2l0aCB0aG9zZSBwcm9ibGVtcyBhZ2Fpbi48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0gQW5kIHRoZXJlIGZpbmQgYSBsaXN0IChpbiBKUykgb2Yg VFVSTiBzZXJ2ZXIgYWRkcmVzc2VzIGZvciB0aGUgbmV0d29yayBwcm92aWRlcuKAmXMgSVAgYWRk cmVzc2VzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwO09yIHdvdWxkIGFuIGFsdGVy bmF0aXZlIGJlIHRvIGFkZCB5b3VyIG93biBJUCBhZGRyZXNzIHRvIHRoZSBVUkwgYW5kIGdldCBv bmx5IHlvdXIgc3BlY2lmaWMgVFVSTiBzZXJ2ZXINCiBhZGRyZXNzPzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+RG9pbmcgaXQgYXQg dGhpcyBXZWIgbGV2ZWwsIEkgdGhpbmsgd2UgYWxzbyBzaG91bGQgY29uc2lkZXIgY2xpZW50cyB1 c2luZyBJQ0UvVFVSTiwgYnV0IG5vdCBoYXZpbmcgdGhlDQogbHV4dXJ5IG9mIGEgSlMgZW5naW5l OiBXb3VsZCBlLmcuIGEgU0lQIGNsaWVudCBiZSBhYmxlIHRvIHBhcnNlIGEg4oCcSlMgdGFibGXi gJ0gdG8gZmluZCBoaXMgVFVSTiBzZXJ2ZXIgYWRkcmVzcyBlYXNpbHk/IEFsc28sIGFyZSB0aGVy ZSBsb25nIHRpbWUtb3V0cyB0byBiZSBjb25zaWRlcmVkIHdoZW4gdGhlcmUgaXMgbm8gaCB0dHA6 Ly88YSBocmVmPSJodHRwOi8vdHVybmVkLm15dnp3LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnR1cm5l ZC5teXZ6dy5jb208L2E+DQogdG8gYmUgZm91bmQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsdWUiPlRoaXMgbWV0aG9kIG1heSBiZSBlYXNpZXIgZm9yIGEgbmV0d29yayBw cm92aWRlciB0byBkZXBsb3kgKEkgZG9u4oCZdCBrbm93LCBidXQgZm9yIGxvY2FsIHVzZSBvbiBh IExBTiBJDQogZ3Vlc3MgaXQgaXMpLiBPbiB0aGUgb3RoZXIgaGFuZCwgdGhlIEROUy1CYXNlZCBT ZXJ2aWNlIERpc2NvdmVyeSBtZXRob2QgaXMgcXVpY2sgYW5kIGVhc3kgZm9yIGEgV2ViUlRDIGJy b3dzZXIsIHNvIHRoYXQgbWF5IGJlIHRyaWVkIGFzIHdlbGwuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JbmRlcGVuZGVudCBvZiBo b3cgd2UgZmluZCB0aGUgbmV0d29yayBwcm92aWRlZCBUVVJOIHNlcnZlciwgb25lIGFkdmFudGFn ZSB3aXRoIGl0IGlzIHRoZSBhdXRoZW50aWNhdGlvbjoNCiBUaGUgbmV0d29yayBwcm92aWRlciBz aW1wbHkgc2V0cyB1cCB0aGUgVFVSTiBmb3IgdXNhZ2UgZnJvbSB0aGUgSVAgYWRkcmVzc2VzIGhl IGhhcyBoYW5kZWQgb3V0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Ymx1ZSI+L0thcmw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnLDpW46 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEp1c3RpbiBVYmVydGkgW21h aWx0bzo8L3NwYW4+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVm PSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0i RU4tVVMiPmp1YmVydGlAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5dDQo8YnI+DQo8Yj5Ta2lja2F0OjwvYj4gZGVuIDMgb2t0b2JlciAyMDEz IDIwOjU5PGJyPg0KPGI+VGlsbDo8L2I+IEthcmwgU3RhaGw8YnI+DQo8Yj5Lb3BpYTo8L2I+IEJl cm5hcmQgQWJvYmE7IEhhcmFsZCBBbHZlc3RyYW5kOyBDdWxsZW4gSmVubmluZ3MgKGZsdWZmeSk7 IDwvc3Bhbj4NCjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0i bWFpbHRvOmRyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzQHRvb2xz LmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmRyYWZ0LWlldGYt cnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzQHRvb2xzLmlldGYub3JnPC9zcGFuPjwv YT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsNCjwvc3Bhbj48c3BhbiBsYW5n PSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpydGN3ZWJAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+cnRjd2ViQGlldGYub3JnPC9z cGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxiPsOEbW5l OjwvYj4gUmU6IFtydGN3ZWJdIFttbXVzaWNdIFRVUk4gc2VydmVyIGFkZHJlc3MgdmlhIERIQ1As IFdHTEMgb2YgZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTE8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPldQQUQgYWxyZWFkeSBzdXBwb3J0cyBETlMtYmFzZWQgZGlzY292ZXJ5IChpbiBhZGRp dGlvbiB0byBESENQKS4gSWYgeW91IGhhdmUmbmJzcDs8c3BhbiBsYW5nPSJTViI+PGEgaHJlZj0i aHR0cDovL2hvc3QtOTUtMTk5LTE5Ni02NS5tb2JpbGVvbmxpbmUudGVsaWEuY29tLyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5ob3N0LTk1 LTE5OS0xOTYtNjUubW9iaWxlb25saW5lLnRlbGlhLmNvbTwvc3Bhbj48L2E+PC9zcGFuPiZuYnNw O2FzDQogeW91ciBlbmRwb2ludCBob3N0bmFtZSwgaXQgd2lsbCB0cnkgdG8gZ2V0IGEgUEFDIGZp bGUgZnJvbSA8c3BhbiBsYW5nPSJTViI+PGEgaHJlZj0iaHR0cDovL3dwYWQubW9iaWxlb25saW5l LnRlbGlhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIj53cGFkLm1vYmls ZW9ubGluZS50ZWxpYS5jb208L3NwYW4+PC9hPjwvc3Bhbj4uPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2luY2UgZm9yIGFsbCBwcmFjdGljYWwgcHVy cG9zZXMsIFRVUk4gaXMgYSAmcXVvdDtVRFAgcHJveHkmcXVvdDssIEkgdGhpbmsgaXQgc2hvdWxk IGJlIGhhbmRsZWQgc2ltaWxhciB0byBvdGhlciBwcm94eSBhdXRvY29uZmlnIG1lY2hhbmlzbXMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBN b24sIFNlcCAzMCwgMjAxMyBhdCA1OjEzIFBNLCBLYXJsIFN0YWhsICZsdDs8c3BhbiBsYW5nPSJT ViI+PGEgaHJlZj0ibWFpbHRvOmthcmwuc3RhaGxAaW50ZXJ0ZXguc2UiIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBsYW5nPSJFTi1VUyI+a2FybC5zdGFobEBpbnRlcnRleC5zZTwvc3Bhbj48L2E+PC9z cGFuPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGhhcHBpbHkgd2l0aGRyYXcgbXkgc3VnZ2VzdGlv biB0byB1c2UgREhDUCB0byBmaW5kIGEgbmV0d29yayBwcm92aWRlciBvZmZlcmVkIFRVUk4gc2Vy dmVyIGluIGZhdm9yIG9mIHRoZSBETlMtQmFzZWQgU2VydmljZSBEaXNjb3ZlcnkNCiBtZXRob2Qg KGluc2VydGVkIGxhc3QgYmVsb3cpLiBUaGUgbWFqb3IgcHJvYmxlbSB3aXRoIHRoZSBESENQIHVz YWdlIHdhcyB0aGF0IHlvdSB0aGVuIGFsc28gaGF2ZSB0byBkbyBzb21ldGhpbmcgc2ltaWxhciBm b3I6IFJBIC0gUm91dGVyIEFkdmVydGlzZW1lbnQgLSBpbiBJUHY2LCBhZGRpdGlvbiB0byB0aGUg SVBDUCBwcm90b2NvbCBmb3IgUFBQb0UgYW5kIHNvbWV0aGluZyBmb3IgdGhlIG1vYmlsZSBPVFQg Y2hhbm5lbCDigJMgd2hlcmV2ZXIgREhDUA0KIGlzIE5PVCB0aGUgbWV0aG9kIHRvIGdpdmUgeW91 IGFuIElQIGFkZHJlc3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZ1cnRoZXI6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBPbiBUaHUsIFNl cCAyNywgMjAxMyBKdXN0aW4gVWJlcnRpIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBBZ3JlZS4gSSBzdGlsbCB0aGlu ayB0aGF0IGV4dGVuZGluZyBQQUMgZmlsZXMgdG8gaW5jbHVkZSBUVVJOIGluZm9ybWF0aW9uIGlz IHRoZSByaWdodCB3YXkgdG8gZ28uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7IFBBQyBmaWxlcyBjYW4gYWxyZWFkeSBiZSBkaXNj b3ZlcmVkIHZpYSBESENQIG9yIEROUywgdGhlcmUgaXMgbm8gbmVlZCB0byByZWludmVudCB0aGlz IHdoZWVsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7Jmd0O09uIFRodSwgU2VwIDI2LCAyMDEzIGF0IDQ6NTUgUE0s IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KSAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48YSBocmVmPSJtYWlsdG86Zmx1ZmZ5QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IGxhbmc9IkVOLVVTIj5mbHVmZnlAY2lzY28uY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jmd0Ow0KIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyZndDtJIHRoaW5rIHdlIG5lZWQg dG8gZ2l2ZSBzb21lIGFkdmlzZSB0byB0aGUgYnJvd3NlcnMgdmVuZG9ycyBvbiB3aGF0IHRoZXkg c2hvdWxkIGltcGxlbWVudCB0byBmaW5kIHR1cm4gc2VydmVyczwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkkg R29vZ2xlZCBhIGJpdCBvbiBQQUMgYW5kIFdQQUQgYW5kIHNhdyB0aGF0IGEgSFRUUCBwcm94eSBj b25maWcgSlMgZmlsZSBjYW4gYmUgcGlja2VkIHVwIHRocm91Z2ggYSBVUkwgYmFzZWQgb24gdGhl IGRldmljZSBuYW1lLg0KIFNpbWlsYXIgY291bGQgd29yayBmb3IgZmluZGluZyBhIFRVUk4gc2Vy dmVyIG9uIGEgTEFOLCBidXQgd2hhdCBhYm91dCB0aGUgY2FzZSB3aXRoIGEgbmV0d29yayBwcm92 aWRlciBvZmZlcmVkIFRVUk4gc2VydmVyPyBUaGUgbmV0d29yayBwcm92aWRlciBoYW5kcyBvdXQg YW4gSVAgYWRkcmVzcyBhbmQgd2FudHMgdG8gYW5ub3VuY2UgYSByZWxhdGVkIFRVUk4gc2VydmVy IGFkZHJlc3M6IOKAkyBJcyB0aGVyZSBhIOKAnFBBQy13YXnigJ0gdG8gYW5ub3VuY2UNCiBpdCB0 byBhIGRldmljZSBvbiBhIExBTiAoYmVoaW5kIGEgTkFUL2ZpcmV3YWxsKT8gVGhlIGRldmljZSBt dXN0IGZpbmQgc3VjaCBjb25maWd1cmF0aW9uIGZpbGUgYmFzZWQgb24gaXRzIHB1YmxpYyBJUCBh ZGRyZXNzICh0aGF0IGhlIGNhbiBmaW5kIHVzaW5nIFNUVU4gYXMgaW4gdGhlIHN1Z2dlc3Rpb24g YmVsb3cpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5CdXQgZ2VuZXJhbGx5LCBmaW5kaW5nIGEgVFVSTi1zZXJ2ZXIgaXMg YSBuZXR3b3JrLXRoaW5nLCBJQ0UgKG9yIGV2ZW4gVFVSTiBub3QgdXNpbmcgSUNFKSwgbm90IGEg V2ViLXRoaW5nLCBzbyBmb3IgdGhhdCByZWFzb24gdGhlDQogRE5TLUJhc2VkIFNlcnZpY2UgRGlz Y292ZXJ5IG1ldGhvZCBpcyBhdCBhIGJldHRlciBsZXZlbC4gU3VjaCBtZXRob2QgY291bGQgYWxz byBiZSB1c2VkIGJ5IFNJUCBjbGllbnRzIChldmVuIGEgU2t5cGUgY2xpZW50IGNvdWxkIGltcGxl bWVudCBpdCB0byBiZW5lZml0IGZyb20gYSByZWFsLXRpbWUgcGF0aCB3aXRoIGJldHRlciBxdWFs aXR5LCBpZiB0aGUgbmV0d29yayBwcm92aWRlciBvZmZlcnMgc3VjaCBwYXRoIHRocm91Z2ggaGlz IFRVUk4gc2VydmVyKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIEROUy1CYXNlZCBTZXJ2aWNlIERpc2NvdmVyeSBt ZXRob2Qgc2hvdWxkIGJlIGVhc3kgdG8gaW1wbGVtZW50IGluIGEgV2ViUlRDIGJyb3dzZXIgKGRv aW5nIGNvbXBsZXggSUNFIHRoaW5ncyBhbnl3YXkpLiBUaGUgcXVlc3Rpb24NCiBpcyByYXRoZXIg aG93IGVhc3kgaXQgaXMgZm9yIHRoZSBuZXR3b3JrIHByb3ZpZGVyIHRvIHByb3Zpc2lvbi4gRG8g dGhleSBhbGwgZG8gcmV2ZXJzZSBETlMgbGlrZSB3aXRoIGZvdW5kIHdpdGggbW9iaWxlIG9wZXJh dG9ycyBUZWxpYVNvbmVyYSBhbmQgVGVsZTIgaW4gU3dlZGVuPyBUaGVuIGl0IHNob3VsZCBub3Qg YmUgdG9vIGRpZmZpY3VsdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T3IgaXMgdGhlcmUgeWV0IGFub3RoZXIgYmV0dGVy IG1ldGhvZCB0byBhbm5vdW5jZSBhIFRVUk4gc2VydmVyIGFkZHJlc3Mgd2l0aCB0aGUgSVAgYWRk cmVzcyBvZmZlcmVkPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+L0thcmw8L3NwYW4+PHNwYW4gbGFuZz0i U1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5GcsOlbjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwv YT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5ydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5Gw7ZyIDwvYj5CZXJu YXJkIEFib2JhPGJyPg0KPGI+U2tpY2thdDo8L2I+IGRlbiAyOSBzZXB0ZW1iZXIgMjAxMyAwMjo0 MTxicj4NCjxiPlRpbGw6PC9iPiBIYXJhbGQgQWx2ZXN0cmFuZDxicj4NCjxiPktvcGlhOjwvYj4g PGEgaHJlZj0ibWFpbHRvOnJ0Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBp ZXRmLm9yZzwvYT48L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj48YnI+DQo8L3Nw YW4+PGI+w4RtbmU6PC9iPiBSZTogW3J0Y3dlYl0gVFVSTiBzZXJ2ZXIgYWRkcmVzcyB2aWEgREhD UCwgV0dMQyBvZiBkcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0x MTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPk9uIFNlcCAyNiwgMjAxMyA4OjQ2IFBNLCAmcXVvdDtIYXJhbGQgQWx2 ZXN0cmFuZCZxdW90OyAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJt YWlsdG86aGFyYWxkQGFsdmVzdHJhbmQubm8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJF Ti1VUyI+aGFyYWxkQGFsdmVzdHJhbmQubm88L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m Z3Q7DQogd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxicj4NCiZxdW90O1NvIGZhciwgbmVpdGhlciB0aGUgUE9TSVggc3Rh bmRhcmQgbm9yIGFueSBPUyB2ZW5kb3IgaGFzIG9mZmVyZWQgYSBnZW5lcmljIGZhY2lsaXR5IHRv IGFjY2VzcyBpbmZvcm1hdGlvbiBtYWRlIGF2YWlsYWJsZSBpbiBESENQIHBhY2tldHMuJnF1b3Q7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+W0JBXSBUaGUgV2luZG93cyBESENQIGNs aWVudCBBUEkgZG9lcyBwcm92aWRlIHRoaXM6Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0 cDovL21zZG4ubWljcm9zb2Z0LmNvbS9lbi11cy9saWJyYXJ5L3dpbmRvd3MvZGVza3RvcC9hYTM2 MzM1MSh2PXZzLjg1KS5hc3B4IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0 dHA6Ly9tc2RuLm1pY3Jvc29mdC5jb20vZW4tdXMvbGlicmFyeS93aW5kb3dzL2Rlc2t0b3AvYWEz NjMzNTEodj12cy44NSkuYXNweDwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkluIHBhcnRpY3VsYXIsIHRo ZSBTZW5kUGFyYW1zIGFyZ3VtZW50IHRvIHRoZSBEaGNwUmVxdWVzdFBhcmFtcyBmdW5jdGlvbiZu YnNwO2NhbiBiZSB1c2VkIHRvIHJlcXVlc3QgYSBwYXJ0aWN1bGFyIHBhcmFtZXRlciAoZS5nLiBU VVJODQogc2VydmVyIGFkZHJlc3MpLCB3aGljaCB3aWxsIHRoZW4gYmUgcmV0dXJuZWQgaW4gdGhl IFJlY2RQYXJhbXMgdmFyaWFibGUuICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5OZXZlcnRoZWxlc3MsIEkgc3Rp bGwgdGhpbmsgdGhhdCB1c2luZyBESENQIHRvIGNvbmZpZ3VyZSB0aGUgVFVSTiBzZXJ2ZXIgYWRk cmVzcyBpbiBhIGJyb3dzZXIgaXNuJ3QgYSBnb29kIGlkZWEuICZuYnNwO0ZvciBvbmUgdGhpbmcs DQogc2luY2UgREhDUCBpcyBlZmZlY3RpdmVseSB1bnNlY3VyZWQsIHRoaXMgbWVjaGFuaXNtIGNv dWxkIGJlIHVzZWQgYnkgYSByb2d1ZSBESENQIHNlcnZlciB0byBmb3JjZSB0cmFmZmljIHRvIGEg cm9ndWUgdHVybnNlcnZlci4gJm5ic3A7IEdyZWF0IGZvciBzdXJ2ZWlsbGFuY2UhPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFNlcCAyNywgMjAxMyAxOjI3IEFNLCAmcXVvdDtLYXJs IFN0YWhsJnF1b3Q7ICZsdDs8c3BhbiBsYW5nPSJTViI+PGEgaHJlZj0ibWFpbHRvOmthcmwuc3Rh aGxAaW50ZXJ0ZXguc2UiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyI+a2FybC5z dGFobEBpbnRlcnRleC5zZTwvc3Bhbj48L2E+PC9zcGFuPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkhlcmUg Y29tZXMgdGhlIHN1Z2dlc3Rpb24gSSBnb3QgZnJvbSBteSBkZXZlbG9wZXIgdGhhdCB3b3VsZCBh bGxvdyBhIG5ldHdvcms8YnI+DQpwcm92aWRlciB0byBvZmZlciBoaXMgVFVSTiBzZXJ2ZXIgZm9y IHRoZSBXZWJSVEMgYnJvd3NlciB0byB1c2UuIFRoaXMgd291bGQ8YnI+DQpyZXF1aXJlIE5PIG5l dyBESENQLW9wdGlvbnMgb3Igc2ltaWxhciwgYW5kIE5PIE9TIGNoYW5nZXMgKEkgZG8gcmVhbGl6 ZTxicj4NCnRob3NlIHNob3VsZCBiZSBhdm9pZGVkIGlmIHBvc3NpYmxlLi4uKS48YnI+DQo8YnI+ DQpUaGUgaWRlYSBpcyBzdGlsbCwgdGhhdCB3aG9ldmVyIGlzIHJlc3BvbnNpYmxlIGZvciBnaXZp bmcgYSBkZXZpY2UgYW4gSVA8YnI+DQphZGRyZXNzICh0aGUgbmV0d29yayBwcm92aWRlciBvciBh IExBTiBhZG1pbmlzdHJhdG9yKSBjYW4gYWxzbyBhbm5vdW5jZSBhPGJyPg0KVFVSTiBzZXJ2ZXIg Zm9yIHRoZSBXZWJSVEMgYnJvd3NlciB0byB1c2UuPGJyPg0KPGJyPg0KVGhlIHN1Z2dlc3Rpb24g aXMgdG8gdXNlIFJGQzY3NjMgKEROUy1CYXNlZCBTZXJ2aWNlIERpc2NvdmVyeSwgc2VlIGNoYXB0 ZXI8YnI+DQoxMSkgd2hlcmUgdGhlIG5ldHdvcmsgcHJvdmlkZXIgKHRoZSBvd25lciBvZiB0aGUg SVAgYWRkcmVzcykgaGFzIHNldCB1cCBhPGJyPg0KRE5TIFBUUiByZWNvcmQgZm9yIHRoZSBUVVJO IHNlcnZlciBpbiB0aGUgaW4tYWRkci5hcnBhIGRvbWFpbi48YnI+DQo8YnI+DQpJZiB0aGUgZGV2 aWNlIGdvdCBJUCAxNzMuMTY0LjI1Mi4xNDksIHRoZW4gbWFrZSBhIHF1ZXJ5IGZvciB0aGUgUFRS IHJlY29yZDxicj4NCmZvcjo8YnI+DQpfdHVybi5fdWRwLjE0OS4yNTIuMTY0LjE3My5pbi1hZGRy LmFycGEuPGJyPg0KVGhlbiB0aGUgU1JWIHJlY29yZCB3b3VsZCByZXR1cm4gdGhlIGFjdHVhbCBh ZGRyZXNzIHRvIHRoZSBUVVJOIHNlcnZlciAoYW5kPGJyPg0KeW91IG1heSBmaW5kIHNldmVyYWwg Zm9yIGxvYWQgYmFsYW5jaW5nIGFuZCBmYWlsb3ZlciBJIGd1ZXNzKTxicj4NCjxicj4NCklmIHRo ZSBkZXZpY2UgaXMgb24gYSBMQU4sIHRoZSBJUCAxNzMuMTY0LjI1Mi4xNDkgdG8gcXVlcnkgd291 bGQgYmUgdGhlIFdBTjxicj4NCklQIHlvdSBnZXQgdmlhIFNUVU4gaW4gdGhlIElDRSBwcm9jZXNz LiBCdXQgaWYgdGhlIExBTiBhZG1pbmlzdHJhdG9yPGJyPg0KcHJvdmlkZXMgYSBsb2NhbCBUVVJO IHNlcnZlciwgdGhlbiBoZSBhbHNvIHNob3VsZCBoYXZlIGJsb2NrZWQgU1RVTiBpbiB0aGU8YnI+ DQpmaXJld2FsbCwgYW5kIHRoZSBicm93c2VyIHNob3VsZCBxdWVyeSB0aGUgZGV2aWNlJ3MgbG9j YWwgaG9zdCBhZGRyZXNzIChhczxicj4NCmluIHRoZSBJQ0UgcHJvY2VkdXJlKSBhbmQgdGhlIGxv Y2FsIExBTiBETlMgc2VydmVyIHNob3VsZCBhbnN3ZXIgdGhlIHF1ZXJ5PGJyPg0KdG8gZ2l2ZSB0 aGUgbG9jYWwgVFVSTiBzZXJ2ZXIgYWRkcmVzcyBvbiB0aGUgTEFOLjxicj4NCjxicj4NClNob3Vs ZG4ndCB0aGlzIHdvcmsgdG8gYWxsb3cgbmV0d29yayBwcm92aWRlciB0byBvZmZlciBoaXMgVFVS TiBzZXJ2ZXI8YnI+DQomcXVvdDthdXRvbWF0aWNhbGx5IGFuZCBnZW5lcmFsbHkmcXVvdDs/PGJy Pg0KPGJyPg0KQW5kIHdvdWxkbid0IHRoaXMgd29yayBuaWNlbHkgZm9yIG1vYmlsZSBkZXZpY2Vz LCB3aGVuZXZlciB0aGUgZGV2aWNlIGlzIG9uPGJyPg0KYSAmcXVvdDtXZWJSVEMtcmVhZHkgYWNj ZXNzJnF1b3Q7IChhY3R1YWxseSBnb29kIGZvciBldmVyeXRoaW5nIHVzaW5nIElDRSksIHdoZXRo ZXI8YnI+DQpmaXhlZCwgV2lGaSBvciAzRy80RyBPVFQsIHlvdSBnZXQgYWxzbyBhIFRVUk4gc2Vy dmVyIChhbmQgdGhlIG5ldHdvcms8YnI+DQpwcm92aWRlciBob3BlZnVsbHkgb2ZmZXJzIGEgcHJp b3JpdGl6ZWQgcGlwZSB0aGVyZSBhcyBvbmUgdXNhZ2Ugb2YgdGhpczxicj4NCm1lY2hhbmlzbSku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ Tm90IHRvIHNsb3cgZG93biBldmVyeSBjYWxsIHNldHVwIGJ5IGRvaW5nIHRoaXMgaW4gdGhlIElD RSBwcm9jZXNzLCBJIGd1ZXNzPGJyPg0KdGhpcyBjb3VsZCBiZSBkb25lIHdoZW4gc3RhcnRpbmcg dGhlIGJyb3dzZXIgYW5kIHdoZW4gdGhlIGRldmljZSBnZXRzIGEgbmV3PGJyPg0KSVAgYWRkcmVz cywgdG8gaGF2ZSB0aGUgVFVSTiBzZXJ2ZXIgYWRkcmVzcyByZWFkeSBmb3IgbGF0ZXIgdXNlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+L0thcmw8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1YiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF17CED9A9MCHP04MSXglobal_-- From tireddy@cisco.com Mon Feb 10 04:09:44 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F07B1A05EC; Mon, 10 Feb 2014 04:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 jQoJ3cdb6tpK; Mon, 10 Feb 2014 04:09:40 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8531A1A05E0; Mon, 10 Feb 2014 04:09:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15848; q=dns/txt; s=iport; t=1392034181; x=1393243781; h=from:to:cc:subject:date:message-id:mime-version; bh=3lBB0HPG+uBx7YJqACUmbZ3vZ170xRjB+EsUktuZ+pg=; b=nIwinLBNIYMBX/CICnbhcwOPAgKAnhkzUECwGR3qJBBxRXuQD4WXdh7j GwnXx9K+FdKnlmLLbZexL9NqlDj3BRI83E8xG11LO3fsYzPO/kkAfD0l2 NCUGzA5Gsxyz3z8oLjK0Mz0hDXwtwYYTlukvpf/4WCKCnN3vBW921m1zu g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwGAN7A+FKtJXG9/2dsb2JhbABZgkhEOFEGtmmIVIEQFnSCJQEBAQQBAQEqQQkCDAYBCA4DBAEBCx0oBgsUCAEJAQQOBQgBh2gDEQgFwDsNiEYXjGaBUhQtBAYHA4MbgRQElj+DHosshUOBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,817,1384300800"; d="scan'208,217";a="302998123" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 10 Feb 2014 12:09:37 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1AC9bk9028535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 12:09:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 06:09:37 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt Thread-Index: Ac8mWNViMg/7N+Z1Q/WK9XyLWsNjfA== Date: Mon, 10 Feb 2014 12:09:36 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242AB165@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.13] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242AB165xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "mmusic@ietf.org" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 12:09:44 -0000 --_000_913383AAA69FF945B8F946018B75898A242AB165xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Oleg, Inline [TR] From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Thursday, February 06, 2014 10:43 PM To: Tirumaleswar Reddy (tireddy) Cc: mmusic@ietf.org; tram@ietf.org Subject: Re: [tram] FW: New Version Notification for draft-wing-mmusic-ice-= mobility-06.txt I have comments regarding the new Error Code "Mobility Forbidden". 1) Section 5.1.4: Comment: remove two TBDs, if the error code has been already determined. [TR] Removed 2) Section 7: and to add a new STUN error code "Mobility Forbidden" with the value 501 to the STUN Error Codes registry [iana-stun]. Comment: I am not sure that 501 is the right code to be used. In SIP and HT= TP, 5xx errors are usually about a server code problem of some sort; 501 me= ans "not implemented". That may be not exactly accurate. A mobility-aware T= URN server may reject the request simply because the administrator does not= allow it., and the server did not encounter an error. The reason why the s= erver reject the request is rather "not allowed" (which is the error code 4= 05). [TR] we can replace 501 error code with 403 May be be, the right approach would be to introduce two separate error code= s here: 405 "not allowed" (the server implements mobility but the administr= ator forbade it) or 501 "not implemented" (the server knows about mobility = but it has no implementation for that). [TR] Not sure if "not implemented" error will be of any help. TURN server i= f it knows about mobility but has not implemented the functionality then it= can continue to ignore MOBILITY-TICKET in the request and not send MOBILIT= Y-TICKET in the response. -Tiru. If the server truly is not aware about mobility at all, the server will sen= d no MOBILITY-TICKET in the server response. Those are three distinct use c= ases: 405, 501 and an "ignorant" server. Thanks Oleg On Wed, Feb 5, 2014 at 6:17 AM, Tirumaleswar Reddy (tireddy) > wrote: Revised draft-wing-mmusic-ice-mobility-06 has been published. It addresses = the comments received for Mobility using TURN and a new section with implem= entation details. Further comments and suggestions are welcome. Thanks and Regards, -Authors. -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Wednesday, February 05, 2014 7:44 PM To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth Pat= il (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal Martinse= n (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti) Subject: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository. Name: draft-wing-mmusic-ice-mobility Revision: 06 Title: Mobility with ICE (MICE) Document date: 2014-02-05 Group: Individual Submission Pages: 21 URL: http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-m= obility-06.txt Status: https://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobi= lity/ Htmlized: http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-0= 6 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-mmusic-ice-mo= bility-06 Abstract: This specification describes how endpoint mobility can be achieved using ICE. Two mechanisms are shown, one where both endpoints support MICE and another where only one endpoint supports MICE. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_913383AAA69FF945B8F946018B75898A242AB165xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Oleg,

 <= /p>

Inline [TR]

 <= /p>

From: Oleg Mos= kalenko [mailto:m= om040267@gmail.com]
Sent: Thursday, February 06, 2014 10:43 PM
To: Tirumaleswar Reddy (tireddy)
Cc: mmusic@iet= f.org; tram@ietf.org
Subject: Re: [tram] FW: New Version Notification for draft-wing-mmus= ic-ice-mobility-06.txt

 

I have comments regar= ding the new Error Code "Mobility Forbidden".

1) Section 5.1.4:
Comment: remove two TBDs, if the error code has been already determined.

[TR] Removed

2) Section 7:

and to add a new STUN error code "Mobility Forbidden" with t=
he value
501 to the STUN Error Codes registry [iana-stun].

 

Comment: I am not sur= e that 501 is the right code to be used. In SIP and HTTP, 5xx errors are us= ually about a server code problem of some sort; 501 means "not impleme= nted". That may be not exactly accurate. A mobility-aware TURN server may reject the request simply because the adm= inistrator does not allow it., and the server did not encounter an error. T= he reason why the server reject the request is rather "not allowed&quo= t; (which is the error code 405).

[TR] we can replace 501 error code with 403

May be be, the right = approach would be to introduce two separate error codes here: 405 "not= allowed" (the server implements mobility but the administrator forbad= e it) or 501 "not implemented" (the server knows about mobility but it has no implementation for that).

[TR] Not sure if “not implemented” error will be of any h= elp. TURN server if it knows about mobility but has not implemented the functionality then it can continue to ignore MOBILITY-TICKET in the reques= t and not send MOBILITY-TICKET in the response.

-Tiru.

If the server truly i= s not aware about mobility at all, the server will send no MOBILITY-TICKET = in the server response. Those are three distinct use cases: 405, 501 and an= "ignorant" server.

Thanks
Oleg

 

On Wed, Feb 5, 2014 at 6:17 AM, Tirumaleswar Reddy (= tireddy) <tireddy= @cisco.com> wrote:

Revised draft-wing-mmusic-ice-mobility-06 has been p= ublished. It addresses the comments received for Mobility using TURN and a = new section with implementation details. Further comments and suggestions a= re welcome.

Thanks and Regards,
-Authors.

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Wednesday, February 05, 2014 7:44 PM
To: Prashanth Patil (praspati); Tirumaleswar Reddy (tireddy); Prashanth Pat= il (praspati); Dan Wing (dwing); Tirumaleswar Reddy (tireddy); Pal Martinse= n (palmarti); Dan Wing (dwing); Pal Martinsen (palmarti)
Subject: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt=


A new version of I-D, draft-wing-mmusic-ice-mobility-06.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name:           draft-wing-mmusic-ice-mobility
Revision:       06
Title:          Mobility with ICE (MICE)
Document date:  2014-02-05
Group:          Individual Submission
Pages:          21
URL:            = http://www.ietf.org/internet-drafts/draft-wing-mmusic-ice-mobility-06.txt
Status:         https://datatracker.ietf.org/doc/draft-wing-mmusic-ice-mobility/
Htmlized:       http://tools.ietf.org/html/draft-wing-mmusic-ice-mobility-06
Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-wing-mmusic-ice-mobility-06
Abstract:
   This specification describes how endpoint mobility can be achi= eved
   using ICE.  Two mechanisms are shown, one where both endp= oints
   support MICE and another where only one endpoint supports MICE= .




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

The IETF Secretariat

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

 

--_000_913383AAA69FF945B8F946018B75898A242AB165xmbrcdx10ciscoc_-- From simon.perreault@viagenie.ca Mon Feb 10 06:16:05 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C581A084A for ; Mon, 10 Feb 2014 06:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 HVLXIMSAXyWc for ; Mon, 10 Feb 2014 06:16:02 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id DFC721A0889 for ; Mon, 10 Feb 2014 06:16:01 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8859040213; Mon, 10 Feb 2014 09:16:01 -0500 (EST) Message-ID: <52F8DF21.2080303@viagenie.ca> Date: Mon, 10 Feb 2014 09:16:01 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Karl Stahl , tram@ietf.org, tireddy@icisco.com References: <082c01cf17d4$393d7bb0$abb87310$@stahl@intertex.se> <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se> In-Reply-To: <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:16:05 -0000 Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a écrit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, “automatically†does this.) I understand the STUN vs TURN priority issue. But I don't see how anycast affects it in any way. Can you please explain? > - 3^rd The Anycast method below – I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the WAN > side. (Current volume deployed, low cost NSP triple play modems usually > have a quality assured level 2 or level 3 WAN pipe for just voice (and > another for IPTV) – The anycast discovered TURN-server can be the access > gateway to such quality pipe for WebRTC media, in a single NSP provided > CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would this not be subject to the same service quality issues that plagued 6to4? That is, anyone could set up a badly-maintained, under-provisioned TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can we prevent triangle routing? There is nothing guaranteeing that the anycast server you see is being provided to you by your ISP, rather than a server sitting on the other side of the planet. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Mon Feb 10 06:21:32 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292D11A02FA for ; Mon, 10 Feb 2014 06:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 hjLNn6wb1esn for ; Mon, 10 Feb 2014 06:21:30 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 94C7E1A02CC for ; Mon, 10 Feb 2014 06:21:26 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5F42C4040F for ; Mon, 10 Feb 2014 09:21:26 -0500 (EST) Message-ID: <52F8E066.9060309@viagenie.ca> Date: Mon, 10 Feb 2014 09:21:26 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <52F54CDC.1040502@viagenie.ca> <52F5550D.3020203@viagenie.ca> <52F7C7E7.7050005@alum.mit.edu> In-Reply-To: <52F7C7E7.7050005@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:21:32 -0000 Le 2014-02-09 13:24, Paul Kyzivat a écrit : > Shouldn't backward compatibility of TURN-bis servers with TURN clients > be *mandatory*, rather than optional? In my experience that's not how I've see IETF specs handle backward compatibility. See STUNv1 vs STUNv2 for an example. Now, what I do feel strongly about is that TURN-bis should not make it impossible for a server to be backward-compatible if it wants to. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Mon Feb 10 06:27:52 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F154B1A07DF for ; Mon, 10 Feb 2014 06:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 EDx1etmtyxZ6 for ; Mon, 10 Feb 2014 06:27:50 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3DFBB1A080D for ; Mon, 10 Feb 2014 06:27:50 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 108A24040F for ; Mon, 10 Feb 2014 09:27:49 -0500 (EST) Message-ID: <52F8E1E4.3030406@viagenie.ca> Date: Mon, 10 Feb 2014 09:27:48 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <52F54CDC.1040502@viagenie.ca> <52F5550D.3020203@viagenie.ca> <52F7C7E7.7050005@alum.mit.edu> <52F83D0F.2090301@alum.mit.edu> In-Reply-To: <52F83D0F.2090301@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:27:52 -0000 Le 2014-02-09 21:44, Paul Kyzivat a écrit : > IMO only (1) makes sense. With the others, migration becomes a > nightmare. No flag days! Option 1 means there is no migration at all. You're stuck with the past forever. Option 3 means you don't have to keep backward compatibility around forever. Practically, all TURN-bis servers would be backward compatible from day 1. Then as time passes the client population would gradually migrate to TURN-bis. When the non-TURN-bis client population becomes too small to justify the cost of backward compatibility, you can throw compat away. For example, if you start a new implementation of STUN today, it could be possible to ignore STUNv1 (depending on your target market), and thus make the implementation smaller, simpler, easier to test, and faster to develop. Simon >> 1) Keep the 1st way (as in current TURN) as backward-compatible solution; >> 2) Require that the client always includes that attribute and the TURN >> server rejects the request if not; >> 3) Make the behavior undefined (as Simon suggests). >> 4) Make the behavior configurable. -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Mon Feb 10 07:04:35 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986381A086C for ; Mon, 10 Feb 2014 07:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 Mwm8s4kJLDsW for ; Mon, 10 Feb 2014 07:04:33 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 805F51A02FF for ; Mon, 10 Feb 2014 07:04:33 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 32DD74040F for ; Mon, 10 Feb 2014 10:04:33 -0500 (EST) Message-ID: <52F8EA80.8000104@viagenie.ca> Date: Mon, 10 Feb 2014 10:04:32 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [tram] Agenda for London X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:04:35 -0000 Folks, This working group is still forming, but it's less than a month until IETF 89 in London, so we need to work out our agenda. I've already asked the "candidate draft" authors for a BoF-type presentation focusing on the problem statement. However if our chartering is accepted, an I am personally optimistic about that, then that means we're done with stating problems, and we can start the real work. The first order of business would then be discussing the potential adoption of candidate drafts. So that's what I think we should be planning for. We have a one hour slot. It will be packed. How about this? 0. T + 00:00: Administrativia 1. T + 00:05: draft-petithuguenin-tram-turn-dtls-00 (?) 2. T + 00:15: draft-reddy-behave-turn-auth (Tirumaleswar Reddy) 3. T + 00:25: draft-johnston-tram-stun-origin (Alan Johnston) 4. T + 00:35: "TURN Extension for Third Party Authorization" (draft to be published) (Alan Johnston) 5. T + 00:50: TURN server auto-discovery mechanism (draft to be published) (?) 6. T + 01:00: EOF Please voice your opinion, suggest changes, etc. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From pkyzivat@alum.mit.edu Mon Feb 10 07:18:30 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5A51A084A for ; Mon, 10 Feb 2014 07:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 0oj1ZXQB3aVR for ; Mon, 10 Feb 2014 07:18:29 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 27C5A1A031A for ; Mon, 10 Feb 2014 07:18:29 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta04.westchester.pa.mail.comcast.net with comcast id QcfS1n0061YDfWL54fJU1U; Mon, 10 Feb 2014 15:18:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id QfJU1n00m3ZTu2S3gfJUWV; Mon, 10 Feb 2014 15:18:28 +0000 Message-ID: <52F8EDC4.8040101@alum.mit.edu> Date: Mon, 10 Feb 2014 10:18:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <52F54CDC.1040502@viagenie.ca> <52F5550D.3020203@viagenie.ca> <52F7C7E7.7050005@alum.mit.edu> <52F83D0F.2090301@alum.mit.edu> <52F8E1E4.3030406@viagenie.ca> In-Reply-To: <52F8E1E4.3030406@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392045508; bh=kLMDNjc26EtEIOIlrp4oOFD2wTAvF4Un7IRPTG4c9Xk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JbMp4KjPu76FQCfajbImWOTziGasanqzhtjO25bg3eYCgPR6lt1XuY8oFJrjGgTyz kYEOABFSXXDI6p2oKRyXm60xsMpMVPF91QEr1fo/y7ftVtqR+7xTHmU+N55hNjDqqB gRviC/OPQ2jF+V3Bw2NZZ58xngcUtbTt7lGwxpv3J+LCTuhjKaj5LnWDxC0kad+F+h 3odxTr9A7Oyuh/FbIVGa/3LihX+/nweWHXbWcpv8CpJGWWydxEXK1AVBPU136xtPc7 0MWBFnCvdqZxsE9u5YS7nKjr/P0V9zOp3i1v8bmSogt58b7bu3JlAb6S/Lwi8bmSdG ZqgQQR/dWe6nw== Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:18:30 -0000 On 2/10/14 9:27 AM, Simon Perreault wrote: > Le 2014-02-09 21:44, Paul Kyzivat a écrit : >> IMO only (1) makes sense. With the others, migration becomes a >> nightmare. No flag days! > > Option 1 means there is no migration at all. You're stuck with the past > forever. > > Option 3 means you don't have to keep backward compatibility around > forever. Practically, all TURN-bis servers would be backward compatible > from day 1. Then as time passes the client population would gradually > migrate to TURN-bis. When the non-TURN-bis client population becomes too > small to justify the cost of backward compatibility, you can throw > compat away. For example, if you start a new implementation of STUN > today, it could be possible to ignore STUNv1 (depending on your target > market), and thus make the implementation smaller, simpler, easier to > test, and faster to develop. It would be more of an issue of there was a real issue if there was a significant cost to supporting backward compatibility. But IIRC, the only cost for backward compatibility here is filling in a standard default if the parameter is missing. The consequence of not requiring backward compatibility is that a developer does exactly as you describe above - ignore STUNv1 compatibility in his server because he thinks his target market won't need it. Then it turns out that there is a STUNv1 client. And that client just fails because of this. Thanks, Paul From fanpeng@chinamobile.com Mon Feb 10 07:26:16 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFAF1A0860 for ; Mon, 10 Feb 2014 07:26:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.548] autolearn=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 OoJxB9tvDiPw for ; Mon, 10 Feb 2014 07:26:14 -0800 (PST) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id C40011A032C for ; Mon, 10 Feb 2014 07:26:13 -0800 (PST) Received: from spf.mail.chinamobile.com (unknown[172.16.20.21]) by rmmx-oa_allagent02-12002 (RichMail) with SMTP id 2ee252f8ef0c276-a8276; Mon, 10 Feb 2014 23:23:57 +0800 (CST) X-RM-TRANSID: 2ee252f8ef0c276-a8276 Received: from X6X8D79D8F49E2 (unknown[125.97.241.254]) by rmsmtp-oa_rmapp03-12003 (RichMail) with SMTP id 2ee352f8ef0c1ce-3c3b7; Mon, 10 Feb 2014 23:23:57 +0800 (CST) X-RM-TRANSID: 2ee352f8ef0c1ce-3c3b7 From: "Fan, Peng" To: "'Simon Perreault'" , References: <52F8EA80.8000104@viagenie.ca> In-Reply-To: <52F8EA80.8000104@viagenie.ca> Date: Mon, 10 Feb 2014 23:26:02 +0800 Message-ID: <003c01cf2674$691d8d80$3b58a880$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMEOB+v9mAzmBveZ3nk3az9VfKxqJhEdwzg Content-Language: zh-cn Cc: denglingli@chinamobile.com, denghui@chinamobile.com Subject: Re: [tram] Agenda for London X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:26:17 -0000 Dear Simon, We are working on a draft relating TRUN server auto-discovery to catch up with the submission deadline. Regards, -Peng > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Monday, February 10, 2014 11:05 PM > To: tram@ietf.org > Subject: [tram] Agenda for London > > Folks, > > This working group is still forming, but it's less than a month until IETF 89 in > London, so we need to work out our agenda. > > I've already asked the "candidate draft" authors for a BoF-type presentation > focusing on the problem statement. However if our chartering is accepted, an I > am personally optimistic about that, then that means we're done with stating > problems, and we can start the real work. The first order of business would then > be discussing the potential adoption of candidate drafts. So that's what I think we > should be planning for. > > We have a one hour slot. It will be packed. How about this? > > 0. T + 00:00: Administrativia > 1. T + 00:05: draft-petithuguenin-tram-turn-dtls-00 (?) 2. T + 00:15: > draft-reddy-behave-turn-auth (Tirumaleswar Reddy) 3. T + 00:25: > draft-johnston-tram-stun-origin (Alan Johnston) 4. T + 00:35: "TURN Extension > for Third Party Authorization" (draft to be published) (Alan Johnston) 5. T + 00:50: > TURN server auto-discovery mechanism (draft to be > published) (?) > 6. T + 01:00: EOF > > Please voice your opinion, suggest changes, etc. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From simon.perreault@viagenie.ca Mon Feb 10 07:34:54 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4855C1A0864 for ; Mon, 10 Feb 2014 07:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 9zYg-372KPNk for ; Mon, 10 Feb 2014 07:34:52 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 46F651A031B for ; Mon, 10 Feb 2014 07:34:52 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C577E4040F for ; Mon, 10 Feb 2014 10:34:51 -0500 (EST) Message-ID: <52F8F19B.3080205@viagenie.ca> Date: Mon, 10 Feb 2014 10:34:51 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <52F8EA80.8000104@viagenie.ca> In-Reply-To: <52F8EA80.8000104@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [tram] Agenda for London X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:34:54 -0000 I've already received several corrections/suggestions/etc. Since we're not officially a WG yet we don't have an official place to put the agenda, so I'm going to put it here: http://www.viagenie.ca/simon.perreault/tram-agenda-ietf89-london.txt This way you can find the latest version easily, and I don't have to spam you all every time I make adjustments. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From jonathan@vidyo.com Mon Feb 10 08:19:19 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CED21A086D for ; Mon, 10 Feb 2014 08:19:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 0TJvWLkadxvS for ; Mon, 10 Feb 2014 08:19:17 -0800 (PST) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id E3DAC1A06F6 for ; Mon, 10 Feb 2014 08:19:16 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/10/2014 11:19:14 AM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-126/SG:2 2/10/2014 11:18:26 AM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.76028 p=-0.97375 Source White X-Signature-Violations: 0-0-0-11844-c X-Note-419: 31.2006 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/10/2014 11:19:02 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 70826734; Mon, 10 Feb 2014 11:19:14 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Mon, 10 Feb 2014 10:19:13 -0600 From: Jonathan Lennox To: Paul Kyzivat Thread-Topic: [tram] Points that should be clarified in STUN-bis and TURN-bis Thread-Index: AQHPJgoGGQ3sy9nOWEKxY05M7kNz7JqvEDGA Date: Mon, 10 Feb 2014 16:19:12 +0000 Message-ID: References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <52F54CDC.1040502@viagenie.ca> <52F5550D.3020203@viagenie.ca> <52F7C7E7.7050005@alum.mit.edu> <52F83D0F.2090301@alum.mit.edu> In-Reply-To: <52F83D0F.2090301@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <94B6E9760FB6114187039BCD1DCDACD1@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:19:19 -0000 I agree with Paul. That said, I could potentially see a use case for allowing servers to selec= t option (3) -- but if we want to support that, we should define a *new* TU= RN attribute that indicates that the client is giving the server the freedo= m to pick the relay's address family. On Feb 9, 2014, at 9:44 PM, Paul Kyzivat wrote: > IMO only (1) makes sense. With the others, migration becomes a nightmare.= No flag days! >=20 > Thanks, > Paul >=20 > On 2/9/14 7:15 PM, Oleg Moskalenko wrote: >> I am not sure whether we want a very strict language here. >>=20 >> This is about how the TURN server will react in case of missed >> REQUESTED-TRANSPORT attribute. There may be three ways to react: >>=20 >> 1) Respond with IPv4 relay endpoint (the current TURN way of doing thing= s); >> 2) Reject the request (strict enforcement of REQUESTED-TRANSPORT attribu= te); >> 3) Respond with IPv6 relay endpoint (may make sense in some networks >> with heavy IPv6 infestation, like mobile networks). >>=20 >> The new standard (TURN-bis) may have three options for the TURN server: >>=20 >> 1) Keep the 1st way (as in current TURN) as backward-compatible solution= ; >> 2) Require that the client always includes that attribute and the TURN >> server rejects the request if not; >> 3) Make the behavior undefined (as Simon suggests). >> 4) Make the behavior configurable. >>=20 >> I can see a sense in options 1 and 3. The first option is 100% >> backward-compatible and that's good. The third option allows legacy TURN >> clients in networks where IPv6 is the default protocol (if the legacy >> client is IPv6 - aware) and leaves the decision to the TURN server >> administrator or implementation. I am not sure about the fourth option - >> it may impose unnecessary complication on the implementation. >>=20 >> But I am against the option 2. It is too harsh and it introduces >> mandatory backward incompatibility. >>=20 >> Oleg >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Sun, Feb 9, 2014 at 10:24 AM, Paul Kyzivat > > wrote: >>=20 >> Shouldn't backward compatibility of TURN-bis servers with TURN >> clients be *mandatory*, rather than optional? >>=20 >> Thanks, >> Paul >>=20 >>=20 >> On 2/7/14 5:08 PM, Oleg Moskalenko wrote: >>=20 >> OK, that's fine. >>=20 >> Oleg >>=20 >>=20 >> On Fri, Feb 7, 2014 at 1:50 PM, Simon Perreault >> > >> > >> wrote: >>=20 >> Le 2014-02-07 16:19, Oleg Moskalenko a =E9crit : >> > Well... OK. If we want the client always to send the >> address-family - >> > but we do not enforce that on the receiving side... that >> sounds >> > awkward, like a speed limit without cops. It is great - >> but does >> that >> > strict requirement make sense without enforcement ? We >> can always say >> > that TURN client SHOULD send the address-family, but MUST >> probably would >> > be too strict... I guess. >>=20 >> The idea is: first, we specify that TURN bis clients MUST se= nd >> REQUESTED-ADDRESS-FAMILY. Then we specify TURN bis server >> behaviour >> depending on the value of REQUESTED-ADDRESS-FAMILY. We do >> *not* specify >> TURN bis server behaviour when that parameter is absent. If = the >> parameter is absent, the client is not following the TURN >> bis spec, and >> the server is free to behave however it wants. That >> includes *wink wink* >> being backward-compatible with TURN. >>=20 >> This is exactly like the STUNv2 magic cookie: STUNv2 >> clients MUST send >> the magic cookie, and STUNv2 server behaviour is defined >> when the cookie >> is present. But STUNv2 does not specify server behaviour >> when the cookie >> is absent. The cookie being absent means the client is not >> a STUNv2 >> client. The server is free to behave however it wishes. >> That includes >> *wink wink* being backward-compatible with STUNv1. >>=20 >> Simon >> -- >> DTN made easy, lean, and smart --> >> http://postellation.viagenie.__ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.c= a >> STUN/TURN server --> http://numb.viagenie.ca >> _________________________________________________ >> tram mailing list >> tram@ietf.org > > >> https://www.ietf.org/mailman/__listinfo/tram >> >>=20 >>=20 >>=20 >>=20 >>=20 >> _________________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/__listinfo/tram >> >>=20 >>=20 >> _________________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/__listinfo/tram >> >>=20 >>=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 From simon.perreault@viagenie.ca Mon Feb 10 08:37:16 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80E61A07EE for ; Mon, 10 Feb 2014 08:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 q6ikjKT5QVAa for ; Mon, 10 Feb 2014 08:37:14 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id A839C1A06F2 for ; Mon, 10 Feb 2014 08:37:14 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3DB814690D for ; Mon, 10 Feb 2014 11:37:14 -0500 (EST) Message-ID: <52F90039.9040901@viagenie.ca> Date: Mon, 10 Feb 2014 11:37:13 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <52F54CDC.1040502@viagenie.ca> <52F5550D.3020203@viagenie.ca> <52F7C7E7.7050005@alum.mit.edu> <52F83D0F.2090301@alum.mit.edu> <52F8E1E4.3030406@viagenie.ca> <52F8EDC4.8040101@alum.mit.edu> In-Reply-To: <52F8EDC4.8040101@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:37:17 -0000 Le 2014-02-10 10:18, Paul Kyzivat a écrit : >> Option 3 means you don't have to keep backward compatibility around >> forever. Practically, all TURN-bis servers would be backward compatible >> from day 1. Then as time passes the client population would gradually >> migrate to TURN-bis. When the non-TURN-bis client population becomes too >> small to justify the cost of backward compatibility, you can throw >> compat away. For example, if you start a new implementation of STUN >> today, it could be possible to ignore STUNv1 (depending on your target >> market), and thus make the implementation smaller, simpler, easier to >> test, and faster to develop. > > It would be more of an issue of there was a real issue if there was a > significant cost to supporting backward compatibility. But IIRC, the > only cost for backward compatibility here is filling in a standard > default if the parameter is missing. You are correct in this particular instance, of course. In general, things may be different. > The consequence of not requiring backward compatibility is that a > developer does exactly as you describe above - ignore STUNv1 > compatibility in his server because he thinks his target market won't > need it. Then it turns out that there is a STUNv1 client. And that > client just fails because of this. Correct. And then either 1) the developer realizes that this STUNv1 client is important enough to warrant additional development, or 2) the developer says "tough luck" to the client, and the client's only recourse it to upgrade to STUNv2. IMHO, that's exactly the kind of thinking that we want to encourage! :) Anyway, we're just philosophizing, this has no practical impact on anything at this point. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From pkyzivat@alum.mit.edu Mon Feb 10 08:54:44 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397271A06E4 for ; Mon, 10 Feb 2014 08:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 RHEFZFBkM91G for ; Mon, 10 Feb 2014 08:54:42 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id ADF3A1A06DC for ; Mon, 10 Feb 2014 08:54:42 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta09.westchester.pa.mail.comcast.net with comcast id QdK81n0040bG4ec59guiBZ; Mon, 10 Feb 2014 16:54:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id Qgui1n00D3ZTu2S3PguisY; Mon, 10 Feb 2014 16:54:42 +0000 Message-ID: <52F90452.3090401@alum.mit.edu> Date: Mon, 10 Feb 2014 11:54:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <16037E0F-62BC-484C-87C0-0C4190ED4D66@vidyo.com> <52F53C98.1070202@viagenie.ca> <52F54CDC.1040502@viagenie.ca> <52F5550D.3020203@viagenie.ca> <52F7C7E7.7050005@alum.mit.edu> <52F83D0F.2090301@alum.mit.edu> <52F8E1E4.3030406@viagenie.ca> <52F8EDC4.8040101@alum.mit.edu> <52F90039.9040901@viagenie.ca> In-Reply-To: <52F90039.9040901@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392051282; bh=ZInw5qqeMClKKuYQHcn5j8ei2CMkYgNEejhE18ZSs50=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=V/TZyKs5HXGiX4+rNiMYeLt71cPpdmwiDrkLLAlJGNsh/mQV5pTBb/nd3uC+EgZdl 7g/WrI5MlOfZOUwODqj3qkgDqLqqV+LO/JxCipthNwc3bAxMRoWS2LEAi3CXXM/2PO AWiTr2W4PD0SMiByiilBe2H9135/cnvsVnImcObU+Bk7ZW2HYLsHtukJhl5r4+KNBg O75+6eYo4+2W0A2QE5Pv9zgfwWbRoeeyM7KZoDraq6jnpPKhrmhY3L6yIquMj9ldeV zksrL+gST1L/sN1TEsFGz1ERAg2Pt7hJxr64dv+VRjZL6Gnjsq585/PMzda0YbCCYp cyYaQFRuSQWww== Subject: Re: [tram] Points that should be clarified in STUN-bis and TURN-bis X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:54:44 -0000 On 2/10/14 11:37 AM, Simon Perreault wrote: > Le 2014-02-10 10:18, Paul Kyzivat a écrit : >>> Option 3 means you don't have to keep backward compatibility around >>> forever. Practically, all TURN-bis servers would be backward compatible >>> from day 1. Then as time passes the client population would gradually >>> migrate to TURN-bis. When the non-TURN-bis client population becomes too >>> small to justify the cost of backward compatibility, you can throw >>> compat away. For example, if you start a new implementation of STUN >>> today, it could be possible to ignore STUNv1 (depending on your target >>> market), and thus make the implementation smaller, simpler, easier to >>> test, and faster to develop. >> >> It would be more of an issue of there was a real issue if there was a >> significant cost to supporting backward compatibility. But IIRC, the >> only cost for backward compatibility here is filling in a standard >> default if the parameter is missing. > > You are correct in this particular instance, of course. In general, > things may be different. My philosophy is to start out assuming backward compatibility. If something is found that makes that much of a burden, then discuss what to do about it. >> The consequence of not requiring backward compatibility is that a >> developer does exactly as you describe above - ignore STUNv1 >> compatibility in his server because he thinks his target market won't >> need it. Then it turns out that there is a STUNv1 client. And that >> client just fails because of this. > > Correct. And then either 1) the developer realizes that this STUNv1 > client is important enough to warrant additional development, or 2) the > developer says "tough luck" to the client, and the client's only > recourse it to upgrade to STUNv2. IMHO, that's exactly the kind of > thinking that we want to encourage! :) If the new thing isn't compatible with TURNv1 then call it something different, so that the process of discovering a TURN server only gets the appropriate kind. > Anyway, we're just philosophizing, this has no practical impact on > anything at this point. Sure. Thanks, Paul From mom040267@gmail.com Mon Feb 10 09:57:21 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDB81A0402; Mon, 10 Feb 2014 09:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 tPHi2fmkJEKH; Mon, 10 Feb 2014 09:57:19 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEE11A0326; Mon, 10 Feb 2014 09:57:19 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so5983231pdb.24 for ; Mon, 10 Feb 2014 09:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OGJYLjCJJ/5iTPNmAQBVdX7Dub/K/s8FqrKXMPX9v5I=; b=fPAo8h2+JTxDEKlNKdIHREyezdxD+bB7gqjNz2V3cmmrNO0HvvWpnGtY8+cxoHW5ij wcxyee1UpeUvrtLPtWqf5YQxBkp/RSOtDSqu4EAmgDAMyZ5oNcxzP2Z06wr9IDtLXOB1 9+cG4nN7f6rLLqcFY5LPcfQdG8RTMwYbOY4R1+gZX2C4j1HNA4soJnwd7PM8oOfJ4R0J 1N+R8vewOW1DrMJTXgB+yhVGXF8DlyaS96FgvapTv9mCAaNtD301nDFDcF83dF63QKA5 zj3WfFjTNSEieTjvq10+WevoGbts4Cp/UGn1QkC8gBIXPjcbvyA8ART8fylbXjDwoRMf ogRg== MIME-Version: 1.0 X-Received: by 10.68.139.100 with SMTP id qx4mr10528421pbb.144.1392055039260; Mon, 10 Feb 2014 09:57:19 -0800 (PST) Received: by 10.68.147.131 with HTTP; Mon, 10 Feb 2014 09:57:19 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A242AB165@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242AB165@xmb-rcd-x10.cisco.com> Date: Mon, 10 Feb 2014 09:57:19 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=001a11c361d21f7f0a04f21112d9 Cc: "mmusic@ietf.org" , "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-wing-mmusic-ice-mobility-06.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 17:57:21 -0000 --001a11c361d21f7f0a04f21112d9 Content-Type: text/plain; charset=ISO-8859-1 Hi Tiru I agree. Thanks Oleg On Mon, Feb 10, 2014 at 4:09 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Comment: I am not sure that 501 is the right code to be used. In SIP > and HTTP, 5xx errors are usually about a server code problem of some sort; > 501 means "not implemented". That may be not exactly accurate. A > mobility-aware TURN server may reject the request simply because the > administrator does not allow it., and the server did not encounter an > error. The reason why the server reject the request is rather "not allowed" > (which is the error code 405). > > [TR] we can replace 501 error code with 403 > > May be be, the right approach would be to introduce two separate error > codes here: 405 "not allowed" (the server implements mobility but the > administrator forbade it) or 501 "not implemented" (the server knows about > mobility but it has no implementation for that). > > [TR] Not sure if "not implemented" error will be of any help. TURN server > if it knows about mobility but has not implemented the functionality then > it can continue to ignore MOBILITY-TICKET in the request and not send > MOBILITY-TICKET in the response. > > --001a11c361d21f7f0a04f21112d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Tiru

I agree.

Thank= s
Oleg

On Mon, Feb 10, 2014 at 4:09 AM, Tirumaleswar Reddy (tireddy) <tireddy= @cisco.com> wrote:

Comment: I am not sur= e that 501 is the right code to be used. In SIP and HTTP, 5xx errors are us= ually about a server code problem of some sort; 501 means "not impleme= nted". That may be not exactly accurate. A mobility-aware TURN server may reject the request simply because the adm= inistrator does not allow it., and the server did not encounter an error. T= he reason why the server reject the request is rather "not allowed&quo= t; (which is the error code 405).

[TR] we can replace 501 error code with 403

May be be, the right = approach would be to introduce two separate error codes here: 405 "not= allowed" (the server implements mobility but the administrator forbad= e it) or 501 "not implemented" (the server knows about mobility but it has no implementation for that).

[TR] Not sure if “not implemented” error will be of= any help. TURN server if it knows about mobility but has not implemented t= he functionality then it can continue to ignore MOBILITY-TICKET in the reques= t and not send MOBILITY-TICKET in the response.



--001a11c361d21f7f0a04f21112d9-- From karl.stahl@intertex.se Mon Feb 10 15:18:16 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BD11A06EF for ; Mon, 10 Feb 2014 15:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1] autolearn=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 ZLP6tTg1aJQs for ; Mon, 10 Feb 2014 15:18:13 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 64BCA1A06E2 for ; Mon, 10 Feb 2014 15:18:11 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402110018077151; Tue, 11 Feb 2014 00:18:07 +0100 From: "Karl Stahl" To: "'Simon Perreault'" , , References: <082c01cf17d4$393d7bb0$abb87310$@stahl@intertex.se> <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se> <52F8DF21.2080303@viagenie.ca> In-Reply-To: <52F8DF21.2080303@viagenie.ca> Date: Tue, 11 Feb 2014 00:18:05 +0100 Message-ID: <049801cf26b6$5a87db30$0f979190$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8maqcqnZhwFrJjTOa0ogBhh2GzagAK7h1Q Content-Language: sv Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 23:18:17 -0000 Simon, Good questions - see inline below --> .=20 Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > - Note that to achieve some of the above points, TURN must be favored=20 > over STUN to enforce that the TURN-path actually is used. (The Anycast = > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =E2=80=9Cautomatically=E2=80=9D within quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) =20 > - 3^rd The Anycast method below =E2=80=93 I see no problem >=20 > It also has the advantage of encouraging (but not requiring) the=20 > STUN/TURN to be built in the default gateway or NAT/firewall/access=20 > router itself, with a second interface to a public IP address on the=20 > WAN side. (Current volume deployed, low cost NSP triple play modems=20 > usually have a quality assured level 2 or level 3 WAN pipe for just=20 > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server can=20 > be the access gateway to such quality pipe for WebRTC media, in a=20 > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready = answer... An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From juberti@google.com Mon Feb 10 17:30:55 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF201A0647 for ; Mon, 10 Feb 2014 17:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 EbWcsYRCzcDZ for ; Mon, 10 Feb 2014 17:30:52 -0800 (PST) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 39A111A0635 for ; Mon, 10 Feb 2014 17:30:52 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id 11so5295415vbe.24 for ; Mon, 10 Feb 2014 17:30:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mArA3p5GoKYALUPpNTevQmAgdNkE48A1yTT2UuWfxp8=; b=bZY2xBsqd0D3r0iHUDaOf/EDzwY4G3nUTBwICxSyvrs3jbQW8MM8dbmHBwY2VSdjrx svfHagx+s7sPZr+PojOBV3YWiKJNNLrEFC+w59E0zBM8GWTb1u1Cx5/Ko0vG+KSz4I7L LpdMCMEKbyikrNLldxoDWB1Xo+hJy/M3FZBz98ofGK9j2qZAHE3y9q1o6xzCk2Y3I9/+ 1bZHHA2ajCeHEIY9Tq5G9d667sSeIru8ULADbZEGZQOdRK7oVxwH5oUbB2Zhw89VxGpc 6YBBah3exbv5CE8SUf5TjeJGxRFJxH92PDJmLrIuu8pfq/xoxNQSl7dca7xTQMUV2RkF zR2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mArA3p5GoKYALUPpNTevQmAgdNkE48A1yTT2UuWfxp8=; b=L/5Xpl8iJDUrZoYva38kTTS5dqde913VYPqBQodr3CTOs6L5P+yqSFmxmNxG5WL0yg f4TFUFQ2A5vLcDTpqsa4sASerT4tiUM1VfVXi9oyRNDJBWMj/vfckDsSKpdPVryBsCbE ovcyghLvGCPo7FiSbVl2vBKdWUAImjkacKowYWKcgByjhxFaS81Xn7u4YP0NUZoEzsgx DWhGhfMOWzKaxRKvbQA1hzBTq+AavV4lSvKlAUA3ahCkgFCUu48u3iy+k10wiHBBQNR7 FWTUPEO/tJEXBHcx//eJt7A8ghjWwJKN8LrWyLoanMUCobypp0Eha2yrdEUEIr0oIfLa ATkQ== X-Gm-Message-State: ALoCoQnXdTsxX1yjy1wJn2jud4oi8NrDBxuMDH+jhDvAYDOokJf+DDX+htNJcj6YQRq1o5w9Dse9uUlD1QkttuZbMgt11cV6n9/129hXvisum7KjfhXUVP791KcvVClXt1eLZ+OXdoHmJ3+EGCwWR4RYKnL/XDs6eRyb8AOruIhfS1q+sJ1QbDJXZ34EdsJr2D9VL10LyBLL X-Received: by 10.52.121.113 with SMTP id lj17mr22304233vdb.21.1392082251512; Mon, 10 Feb 2014 17:30:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Mon, 10 Feb 2014 17:30:31 -0800 (PST) In-Reply-To: <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> From: Justin Uberti Date: Mon, 10 Feb 2014 17:30:31 -0800 Message-ID: To: Karl Stahl Content-Type: multipart/alternative; boundary=089e0122f1ca1992d704f21768e1 Cc: tireddy@icisco.com, Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 01:30:55 -0000 --089e0122f1ca1992d704f21768e1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good to see there is a lot of interest for this milestone. But based on the description here, it seems like we want to use TURN primarily to identify WebRTC flows, as opposed to using it as a NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem. On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl wrote: > Simon, > > Good questions - see inline below --> . > Some more thought is required! > > /Karl > > -----Ursprungligt meddelande----- > Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault > Skickat: den 10 februari 2014 15:16 > Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com > =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism f= or > enterprise and ISPs > > Karl, > > It is great to see such enthusiasm! Thanks! > > I have a couple technical questions... > > Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > > - Note that to achieve some of the above points, TURN must be favored > > over STUN to enforce that the TURN-path actually is used. (The Anycast > > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) > > I understand the STUN vs TURN priority issue. But I don't see how anycast > affects it in any way. Can you please explain? > > --- Good point - I was a bit quick here (maybe too quick) > We have given this quite bit of thought, since even if a TURN server is > provided and discovered, CURRENT usage of ICE may suggest a candidate fro= m > the remote party that will make a connection without the need/usage of th= e > TURN server (that we wanted to be used for the good purposes listed). > > The only way we found around this, was to stop STUN through the IP defaul= t > gateway (like a restrictive Enterprise firewall does inhibiting ICE > connectivity, which others are concerned about...). Since the provisionin= g > of auto-discovery using the anycast mechanism, would be adding a route in= a > default gateway, adding a firewall rule to eat STUN packets would assure > that the provisioned TURN server actually becomes used (and not bypassed > "by accident"). (That was the thought behind the =E2=80=9Cautomatically= =E2=80=9D within > quotes.) > > BUT, since you brought up the question, assuming that we have the power t= o > enforce WebRTC usage of ICE, I believe a MUST requirement to use an > auto-discovered TURN server instead of STUN, would solve the same problem= . > However, thinking further (in relation to your next question - "anyone > could set up a badly-maintained" - enforcing such ICE usage may not be > good.) > > > > - 3^rd The Anycast method below =E2=80=93 I see no problem > > > > It also has the advantage of encouraging (but not requiring) the > > STUN/TURN to be built in the default gateway or NAT/firewall/access > > router itself, with a second interface to a public IP address on the > > WAN side. (Current volume deployed, low cost NSP triple play modems > > usually have a quality assured level 2 or level 3 WAN pipe for just > > voice (and another for IPTV) =E2=80=93 The anycast discovered TURN-serv= er can > > be the access gateway to such quality pipe for WebRTC media, in a > > single NSP provided CPE, scaling from residential and up.) > > Suppose we define well-known anycast TURN server addresses. How would thi= s > not be subject to the same service quality issues that plagued 6to4? That > is, anyone could set up a badly-maintained, under-provisioned TURN server > and announce it over BGP to the world, as it was done for > 6to4 relays. Or just bad BGP outbound filter configuration. And how can w= e > prevent triangle routing? There is nothing guaranteeing that the anycast > server you see is being provided to you by your ISP, rather than a server > sitting on the other side of the planet. > > --- Good point - needs to be resolved. For this I don't have a ready > answer... > An auto-discovered TURN server must be trusted (whatever method it is > discovered by). We are trusting the one providing us with an IP address a= nd > default gateway anyway. It would be easy if we could reuse that trust, > instead of another mechanisms. > > Is there a good way for the browser to check that the anycast address is > not handled beyond the network service provider's default gateway? Ideas? > > > > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --089e0122f1ca1992d704f21768e1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good to see there is a lot of interest for this milestone.= But based on the description here, it seems like we want to use TURN prima= rily to identify WebRTC flows, as opposed to using it as a NAT traversal to= ol. This makes me concerned that we may be using the wrong technology to so= lve the problem.


On Mon, Feb 1= 0, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se>= wrote:
Simon,

Good questions - see inline below --> .
Some more thought is required!

/Karl

-----Ursprungligt meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounc= es@ietf.org] F=C3=B6r Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com
=C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for= enterprise and ISPs

Karl,

It is great to see such enthusiasm! Thanks!

I have a couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit :
> - Note that to achieve some of the above points, TURN must be favored<= br> > over STUN to enforce that the TURN-path actually is used. (The Anycast=
> method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.)
I understand the STUN vs TURN priority issue. But I don't see how anyca= st affects it in any way. Can you please explain?

--- Good point - I was a bit quick here (maybe too quick)
We have given this quite bit of thought, since even if a TURN server is pro= vided and discovered, CURRENT usage of ICE may suggest a candidate from the= remote party that will make a connection without the need/usage of the TUR= N server (that we wanted to be used for the good purposes listed).

The only way we found around this, was to stop STUN through the IP default = gateway (like a restrictive Enterprise firewall does inhibiting ICE connect= ivity, which others are concerned about...). Since the provisioning of auto= -discovery using the anycast mechanism, would be adding a route in a defaul= t gateway, adding a firewall rule to eat STUN packets would assure that the= provisioned TURN server actually becomes used (and not bypassed "by a= ccident"). (That was the thought behind the =E2=80=9Cautomatically=E2= =80=9D within quotes.)

BUT, since you brought up the question, assuming that we have the power to = enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-di= scovered TURN server instead of STUN, would solve the same problem. However= , thinking further (in relation to your next question - "anyone could = set up a badly-maintained" - enforcing such ICE usage may not be good.= )


> - 3^rd The Anycast method below =E2=80=93 I see no problem
>
> It also has the advantage of encouraging (but not requiring) the
> STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered TURN-ser= ver can
> be the access gateway to such quality pipe for WebRTC media, in a
> single NSP provided CPE, scaling from residential and up.)

Suppose we define well-known anycast TURN server addresses. How would this = not be subject to the same service quality issues that plagued 6to4? That i= s, anyone could set up a badly-maintained, under-provisioned TURN server an= d announce it over BGP to the world, as it was done for
6to4 relays. Or just bad BGP outbound filter configuration. And how can we = prevent triangle routing? There is nothing guaranteeing that the anycast se= rver you see is being provided to you by your ISP, rather than a server sit= ting on the other side of the planet.

--- Good point - needs to be resolved. For this I don't have a re= ady answer...
An auto-discovered TURN server must be trusted (whatever method it is disco= vered by). We are trusting the one providing us with an IP address and defa= ult gateway anyway. It would be easy if we could reuse that trust, instead = of another mechanisms.

Is there a good way for the browser to check that the anycast address is no= t handled beyond the network service provider's default gateway? Ideas?=



Thanks,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://numb.viagenie.ca=
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--089e0122f1ca1992d704f21768e1-- From tireddy@cisco.com Mon Feb 10 18:39:37 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863001A05E1 for ; Mon, 10 Feb 2014 18:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 fvJeAwYgs3dM for ; Mon, 10 Feb 2014 18:39:35 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D93F71A0724 for ; Mon, 10 Feb 2014 18:39:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7928; q=dns/txt; s=iport; t=1392086375; x=1393295975; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rJWwHqpaJ5csqp/osRYgeAPfp5Cu8+nXtiBo6kujc18=; b=XL2vpPnn3vpb94GFPqoJvgc26k6yDq23PuwvGDBh7cBM9ukMPaTG83se s9sxrxr9+D2b95U1B2M9WexaY5XCODLtUZIcDGiFnEAGsk9HUme1wBBxX w0kXjp/G3nQL/4BCo3aHuaoevIwYZLP0CefRfUW5IY0EalpBFXZ03F27s c=; X-IronPort-AV: E=Sophos;i="4.95,822,1384300800"; d="scan'208";a="303131504" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 11 Feb 2014 02:39:34 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1B2dYta026384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 02:39:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 20:39:34 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Karl Stahl , "'Simon Perreault'" , "tram@ietf.org" , "tireddy@icisco.com" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPJrZnSgUY4V56JE+wy6rTjZeHIZqvVbIw Date: Tue, 11 Feb 2014 02:39:33 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242ABA2D@xmb-rcd-x10.cisco.com> References: <082c01cf17d4$393d7bb0$abb87310$@stahl@intertex.se> <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se> <52F8DF21.2080303@viagenie.ca> <049801cf26b6$5a87db30$0f979190$@stahl@intertex.se> In-Reply-To: <049801cf26b6$5a87db30$0f979190$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.70.251] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 02:39:37 -0000 PiBUaGUgb25seSB3YXkgd2UgZm91bmQgYXJvdW5kIHRoaXMsIHdhcyB0byBzdG9wIFNUVU4gdGhy b3VnaCB0aGUgSVAgZGVmYXVsdA0KPiBnYXRld2F5IChsaWtlIGEgcmVzdHJpY3RpdmUgRW50ZXJw cmlzZSBmaXJld2FsbCBkb2VzIGluaGliaXRpbmcgSUNFIGNvbm5lY3Rpdml0eSwNCj4gd2hpY2gg b3RoZXJzIGFyZSBjb25jZXJuZWQgYWJvdXQuLi4pLiBTaW5jZSB0aGUgcHJvdmlzaW9uaW5nIG9m IGF1dG8tDQo+IGRpc2NvdmVyeSB1c2luZyB0aGUgYW55Y2FzdCBtZWNoYW5pc20sIHdvdWxkIGJl IGFkZGluZyBhIHJvdXRlIGluIGEgZGVmYXVsdA0KPiBnYXRld2F5LCBhZGRpbmcgYSBmaXJld2Fs bCBydWxlIHRvIGVhdCBTVFVOIHBhY2tldHMgd291bGQgYXNzdXJlIHRoYXQgdGhlDQo+IHByb3Zp c2lvbmVkIFRVUk4gc2VydmVyIGFjdHVhbGx5IGJlY29tZXMgdXNlZCAoYW5kIG5vdCBieXBhc3Nl ZCAiYnkNCj4gYWNjaWRlbnQiKS4gKFRoYXQgd2FzIHRoZSB0aG91Z2h0IGJlaGluZCB0aGUg4oCc YXV0b21hdGljYWxseeKAnSB3aXRoaW4gcXVvdGVzLikNCg0KVGhlcmUgYXJlIHZhcmlvdXMgd2F5 cyB0byBwcmlvcml0aXplIFdlYlJUQyBtZWRpYSBzdHJlYW1zIGFuZCBJIGRvbid0IHNlZSBhIG5l ZWQgdG8gYmxvY2sgUDJQIGNvbm5lY3Rpdml0eS4gIFVzaW5nIFRVUk4gc2VydmVyIGl0c2VsZiBl bmRwb2ludCBjYW4gbGVhcm4gc2VydmVyLXJlZmxleGl2ZSBjYW5kaWRhdGVzLiBJZiB0aGVyZSBp cyBhIHJlc3RyaWN0aXZlIGZpcmV3YWxsIHRoYXQgYmxvY2tzIFAyUCBjb25uZWN0aXZpdHkgdGhl biByZWxheWVkIGNhbmRpZGF0ZSB3b3VsZCBldmVudHVhbGx5IGJlIG5vbWluYXRlZCBiZWNhdXNl IElDRSBjb25uZWN0aXZpdHkgY2hlY2sgZmFpbHMgd2l0aCBvdGhlciBjYW5kaWRhdGUgdHlwZXMu IA0KDQpJIGRvbid0IHNlZSBhbnkgbmVlZCB0byBhZHZlcnRpc2Ugb25seSByZWxheWVkIGNhbmRp ZGF0ZXMgaW4gdGhlIG9mZmVyL2Fuc3dlciBvdGhlciB0aGFuIGZvciBwcml2YWN5IHJlYXNvbnMu DQoNCi1UaXJ1Lg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHRyYW0g W21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLYXJsIFN0YWhsDQo+ IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDQ6NDggQU0NCj4gVG86ICdTaW1vbiBQ ZXJyZWF1bHQnOyB0cmFtQGlldGYub3JnOyB0aXJlZGR5QGljaXNjby5jb20NCj4gU3ViamVjdDog UmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFu aXNtIGZvcg0KPiBlbnRlcnByaXNlIGFuZCBJU1BzDQo+IA0KPiBTaW1vbiwNCj4gDQo+IEdvb2Qg cXVlc3Rpb25zIC0gc2VlIGlubGluZSBiZWxvdyAtLT4gLg0KPiBTb21lIG1vcmUgdGhvdWdodCBp cyByZXF1aXJlZCENCj4gDQo+IC9LYXJsDQo+IA0KPiAtLS0tLVVyc3BydW5nbGlndCBtZWRkZWxh bmRlLS0tLS0NCj4gRnLDpW46IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIEbD tnIgU2ltb24gUGVycmVhdWx0DQo+IFNraWNrYXQ6IGRlbiAxMCBmZWJydWFyaSAyMDE0IDE1OjE2 DQo+IFRpbGw6IEthcmwgU3RhaGw7IHRyYW1AaWV0Zi5vcmc7IHRpcmVkZHlAaWNpc2NvLmNvbQ0K PiDDhG1uZTogUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3Zl cnkgbWVjaGFuaXNtIGZvcg0KPiBlbnRlcnByaXNlIGFuZCBJU1BzDQo+IA0KPiBLYXJsLA0KPiAN Cj4gSXQgaXMgZ3JlYXQgdG8gc2VlIHN1Y2ggZW50aHVzaWFzbSEgVGhhbmtzIQ0KPiANCj4gSSBo YXZlIGEgY291cGxlIHRlY2huaWNhbCBxdWVzdGlvbnMuLi4NCj4gDQo+IExlIDIwMTQtMDItMDgg MDg6MTEsIEthcmwgU3RhaGwgYSDDqWNyaXQgOg0KPiA+IC0gTm90ZSB0aGF0IHRvIGFjaGlldmUg c29tZSBvZiB0aGUgYWJvdmUgcG9pbnRzLCBUVVJOIG11c3QgYmUgZmF2b3JlZA0KPiA+IG92ZXIg U1RVTiB0byBlbmZvcmNlIHRoYXQgdGhlIFRVUk4tcGF0aCBhY3R1YWxseSBpcyB1c2VkLiAoVGhl IEFueWNhc3QNCj4gPiBtZXRob2Qgc3VnZ2VzdGVkIGJlbG93LCDigJxhdXRvbWF0aWNhbGx54oCd IGRvZXMgdGhpcy4pDQo+IA0KPiBJIHVuZGVyc3RhbmQgdGhlIFNUVU4gdnMgVFVSTiBwcmlvcml0 eSBpc3N1ZS4gQnV0IEkgZG9uJ3Qgc2VlIGhvdyBhbnljYXN0DQo+IGFmZmVjdHMgaXQgaW4gYW55 IHdheS4gQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbj8NCj4gDQo+IC0tLSBHb29kIHBvaW50IC0gSSB3 YXMgYSBiaXQgcXVpY2sgaGVyZSAobWF5YmUgdG9vIHF1aWNrKSBXZSBoYXZlIGdpdmVuIHRoaXMN Cj4gcXVpdGUgYml0IG9mIHRob3VnaHQsIHNpbmNlIGV2ZW4gaWYgYSBUVVJOIHNlcnZlciBpcyBw cm92aWRlZCBhbmQgZGlzY292ZXJlZCwNCj4gQ1VSUkVOVCB1c2FnZSBvZiBJQ0UgbWF5IHN1Z2dl c3QgYSBjYW5kaWRhdGUgZnJvbSB0aGUgcmVtb3RlIHBhcnR5IHRoYXQNCj4gd2lsbCBtYWtlIGEg Y29ubmVjdGlvbiB3aXRob3V0IHRoZSBuZWVkL3VzYWdlIG9mIHRoZSBUVVJOIHNlcnZlciAodGhh dCB3ZQ0KPiB3YW50ZWQgdG8gYmUgdXNlZCBmb3IgdGhlIGdvb2QgcHVycG9zZXMgbGlzdGVkKS4N Cj4gDQo+IFRoZSBvbmx5IHdheSB3ZSBmb3VuZCBhcm91bmQgdGhpcywgd2FzIHRvIHN0b3AgU1RV TiB0aHJvdWdoIHRoZSBJUCBkZWZhdWx0DQo+IGdhdGV3YXkgKGxpa2UgYSByZXN0cmljdGl2ZSBF bnRlcnByaXNlIGZpcmV3YWxsIGRvZXMgaW5oaWJpdGluZyBJQ0UgY29ubmVjdGl2aXR5LA0KPiB3 aGljaCBvdGhlcnMgYXJlIGNvbmNlcm5lZCBhYm91dC4uLikuIFNpbmNlIHRoZSBwcm92aXNpb25p bmcgb2YgYXV0by0NCj4gZGlzY292ZXJ5IHVzaW5nIHRoZSBhbnljYXN0IG1lY2hhbmlzbSwgd291 bGQgYmUgYWRkaW5nIGEgcm91dGUgaW4gYSBkZWZhdWx0DQo+IGdhdGV3YXksIGFkZGluZyBhIGZp cmV3YWxsIHJ1bGUgdG8gZWF0IFNUVU4gcGFja2V0cyB3b3VsZCBhc3N1cmUgdGhhdCB0aGUNCj4g cHJvdmlzaW9uZWQgVFVSTiBzZXJ2ZXIgYWN0dWFsbHkgYmVjb21lcyB1c2VkIChhbmQgbm90IGJ5 cGFzc2VkICJieQ0KPiBhY2NpZGVudCIpLiAoVGhhdCB3YXMgdGhlIHRob3VnaHQgYmVoaW5kIHRo ZSDigJxhdXRvbWF0aWNhbGx54oCdIHdpdGhpbiBxdW90ZXMuKQ0KPiANCj4gQlVULCBzaW5jZSB5 b3UgYnJvdWdodCB1cCB0aGUgcXVlc3Rpb24sIGFzc3VtaW5nIHRoYXQgd2UgaGF2ZSB0aGUgcG93 ZXIgdG8NCj4gZW5mb3JjZSBXZWJSVEMgdXNhZ2Ugb2YgSUNFLCBJIGJlbGlldmUgYSBNVVNUIHJl cXVpcmVtZW50IHRvIHVzZSBhbiBhdXRvLQ0KPiBkaXNjb3ZlcmVkIFRVUk4gc2VydmVyIGluc3Rl YWQgb2YgU1RVTiwgd291bGQgc29sdmUgdGhlIHNhbWUgcHJvYmxlbS4NCj4gSG93ZXZlciwgdGhp bmtpbmcgZnVydGhlciAoaW4gcmVsYXRpb24gdG8geW91ciBuZXh0IHF1ZXN0aW9uIC0gImFueW9u ZSBjb3VsZA0KPiBzZXQgdXAgYSBiYWRseS1tYWludGFpbmVkIiAtIGVuZm9yY2luZyBzdWNoIElD RSB1c2FnZSBtYXkgbm90IGJlIGdvb2QuKQ0KPiANCj4gDQo+ID4gLSAzXnJkIFRoZSBBbnljYXN0 IG1ldGhvZCBiZWxvdyDigJMgSSBzZWUgbm8gcHJvYmxlbQ0KPiA+DQo+ID4gSXQgYWxzbyBoYXMg dGhlIGFkdmFudGFnZSBvZiBlbmNvdXJhZ2luZyAoYnV0IG5vdCByZXF1aXJpbmcpIHRoZQ0KPiA+ IFNUVU4vVFVSTiB0byBiZSBidWlsdCBpbiB0aGUgZGVmYXVsdCBnYXRld2F5IG9yIE5BVC9maXJl d2FsbC9hY2Nlc3MNCj4gPiByb3V0ZXIgaXRzZWxmLCB3aXRoIGEgc2Vjb25kIGludGVyZmFjZSB0 byBhIHB1YmxpYyBJUCBhZGRyZXNzIG9uIHRoZQ0KPiA+IFdBTiBzaWRlLiAoQ3VycmVudCB2b2x1 bWUgZGVwbG95ZWQsIGxvdyBjb3N0IE5TUCB0cmlwbGUgcGxheSBtb2RlbXMNCj4gPiB1c3VhbGx5 IGhhdmUgYSBxdWFsaXR5IGFzc3VyZWQgbGV2ZWwgMiBvciBsZXZlbCAzIFdBTiBwaXBlIGZvciBq dXN0DQo+ID4gdm9pY2UgKGFuZCBhbm90aGVyIGZvciBJUFRWKSDigJMgVGhlIGFueWNhc3QgZGlz Y292ZXJlZCBUVVJOLXNlcnZlciBjYW4NCj4gPiBiZSB0aGUgYWNjZXNzIGdhdGV3YXkgdG8gc3Vj aCBxdWFsaXR5IHBpcGUgZm9yIFdlYlJUQyBtZWRpYSwgaW4gYQ0KPiA+IHNpbmdsZSBOU1AgcHJv dmlkZWQgQ1BFLCBzY2FsaW5nIGZyb20gcmVzaWRlbnRpYWwgYW5kIHVwLikNCj4gDQo+IFN1cHBv c2Ugd2UgZGVmaW5lIHdlbGwta25vd24gYW55Y2FzdCBUVVJOIHNlcnZlciBhZGRyZXNzZXMuIEhv dyB3b3VsZA0KPiB0aGlzIG5vdCBiZSBzdWJqZWN0IHRvIHRoZSBzYW1lIHNlcnZpY2UgcXVhbGl0 eSBpc3N1ZXMgdGhhdCBwbGFndWVkIDZ0bzQ/IFRoYXQNCj4gaXMsIGFueW9uZSBjb3VsZCBzZXQg dXAgYSBiYWRseS1tYWludGFpbmVkLCB1bmRlci1wcm92aXNpb25lZCBUVVJOIHNlcnZlcg0KPiBh bmQgYW5ub3VuY2UgaXQgb3ZlciBCR1AgdG8gdGhlIHdvcmxkLCBhcyBpdCB3YXMgZG9uZSBmb3IN Cj4gNnRvNCByZWxheXMuIE9yIGp1c3QgYmFkIEJHUCBvdXRib3VuZCBmaWx0ZXIgY29uZmlndXJh dGlvbi4gQW5kIGhvdyBjYW4gd2UNCj4gcHJldmVudCB0cmlhbmdsZSByb3V0aW5nPyBUaGVyZSBp cyBub3RoaW5nIGd1YXJhbnRlZWluZyB0aGF0IHRoZSBhbnljYXN0DQo+IHNlcnZlciB5b3Ugc2Vl IGlzIGJlaW5nIHByb3ZpZGVkIHRvIHlvdSBieSB5b3VyIElTUCwgcmF0aGVyIHRoYW4gYSBzZXJ2 ZXINCj4gc2l0dGluZyBvbiB0aGUgb3RoZXIgc2lkZSBvZiB0aGUgcGxhbmV0Lg0KPiANCj4gLS0t IEdvb2QgcG9pbnQgLSBuZWVkcyB0byBiZSByZXNvbHZlZC4gRm9yIHRoaXMgSSBkb24ndCBoYXZl IGEgcmVhZHkgYW5zd2VyLi4uDQo+IEFuIGF1dG8tZGlzY292ZXJlZCBUVVJOIHNlcnZlciBtdXN0 IGJlIHRydXN0ZWQgKHdoYXRldmVyIG1ldGhvZCBpdCBpcw0KPiBkaXNjb3ZlcmVkIGJ5KS4gV2Ug YXJlIHRydXN0aW5nIHRoZSBvbmUgcHJvdmlkaW5nIHVzIHdpdGggYW4gSVAgYWRkcmVzcyBhbmQN Cj4gZGVmYXVsdCBnYXRld2F5IGFueXdheS4gSXQgd291bGQgYmUgZWFzeSBpZiB3ZSBjb3VsZCBy ZXVzZSB0aGF0IHRydXN0LA0KPiBpbnN0ZWFkIG9mIGFub3RoZXIgbWVjaGFuaXNtcy4NCj4gDQo+ IElzIHRoZXJlIGEgZ29vZCB3YXkgZm9yIHRoZSBicm93c2VyIHRvIGNoZWNrIHRoYXQgdGhlIGFu eWNhc3QgYWRkcmVzcyBpcyBub3QNCj4gaGFuZGxlZCBiZXlvbmQgdGhlIG5ldHdvcmsgc2Vydmlj ZSBwcm92aWRlcidzIGRlZmF1bHQgZ2F0ZXdheT8gSWRlYXM/DQo+IA0KPiANCj4gDQo+IFRoYW5r cywNCj4gU2ltb24NCj4gLS0NCj4gRFROIG1hZGUgZWFzeSwgbGVhbiwgYW5kIHNtYXJ0IC0tPiBo dHRwOi8vcG9zdGVsbGF0aW9uLnZpYWdlbmllLmNhDQo+IE5BVDY0L0ROUzY0IG9wZW4tc291cmNl ICAgICAgICAtLT4gaHR0cDovL2VjZHlzaXMudmlhZ2VuaWUuY2ENCj4gU1RVTi9UVVJOIHNlcnZl ciAgICAgICAgICAgICAgIC0tPiBodHRwOi8vbnVtYi52aWFnZW5pZS5jYQ0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB0cmFtIG1haWxpbmcgbGlz dA0KPiB0cmFtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdHJhbQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gdHJhbUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg== From tireddy@cisco.com Mon Feb 10 21:26:52 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE311A08BB for ; Mon, 10 Feb 2014 21:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 lvuC_9TrSlEz for ; Mon, 10 Feb 2014 21:26:50 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id F147C1A08B7 for ; Mon, 10 Feb 2014 21:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2644; q=dns/txt; s=iport; t=1392096410; x=1393306010; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=P9QUO5a4xPJDWNk1uU5uI00m+9rsiiVR3bzJ264hwSE=; b=SIqeT1M8g7cWJFkXsQdNOV3sqNsnsvLQoJ2LjbFQWs98K+ZhlzP0IUpO IBaqbx4jdYCOOUzINdAc2712XX2C/Z/ET34RFv4Jk5INeTDLjE7m7dcq7 TIGDN3a9LEJClje+Xcv8VTjsa4Be+fHxusKDj72nhZ1WOrEFL9pkJZdtv s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAOSz+VKtJXHA/2dsb2JhbABZgww4V4MBu2MYdxZ0giUBAQEEIxFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgBh3wNqUqgGxeBKYxvJxYiBoJpNYEUBJlckG6DLYFoQg X-IronPort-AV: E=Sophos;i="4.95,823,1384300800"; d="scan'208";a="303191652" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 11 Feb 2014 05:26:49 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1B5QnwI007980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Feb 2014 05:26:49 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 23:26:49 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-patil-tram-turn-serv-disc-00.txt Thread-Index: AQHPJujloEi2N4/0QE+ZEdv7QDaebJqvhP0Q Date: Tue, 11 Feb 2014 05:26:48 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242ABB49@xmb-rcd-x10.cisco.com> References: <20140211051944.2479.50189.idtracker@ietfa.amsl.com> In-Reply-To: <20140211051944.2479.50189.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.62.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 05:26:52 -0000 VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdHdvIG1lY2hhbmlzbXMgdG8gYXV0byBkaXNjb3ZlciBU VVJOIHNlcnZlci4gUGxlYXNlIHJldmlldyBhbmQgcHJvdmlkZSB5b3VyIHZhbHVhYmxlIGNvbW1l bnRzLg0KDQotQXV0aG9ycy4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10g DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxMSwgMjAxNCAxMDo1MCBBTQ0KVG86IFByYXNoYW50 aCBQYXRpbCAocHJhc3BhdGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyBEYW4gV2luZyAoZHdpbmcpOyBEYW4gV2luZyAoZHdpbmcp OyBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1wYXRpbC10cmFtLXR1cm4tc2Vydi1kaXNjLTAwLnR4dA0KDQoNCkEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1wYXRpbC10cmFtLXR1cm4tc2Vydi1kaXNjLTAwLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkg YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtcGF0aWwt dHJhbS10dXJuLXNlcnYtZGlzYw0KUmV2aXNpb246CTAwDQpUaXRsZToJCVRVUk4gU2VydmVyIEF1 dG8gRGlzY292ZXJ5DQpEb2N1bWVudCBkYXRlOgkyMDE0LTAyLTExDQpHcm91cDoJCUluZGl2aWR1 YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk5DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGF0aWwtdHJhbS10dXJuLXNlcnYtZGlzYy0wMC50 eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1wYXRpbC10cmFtLXR1cm4tc2Vydi1kaXNjLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhdGlsLXRyYW0tdHVybi1zZXJ2LWRpc2MtMDANCg0KDQpB YnN0cmFjdDoNCiAgIEN1cnJlbnQgVHJhdmVyc2FsIFVzaW5nIFJlbGF5cyBhcm91bmQgTkFUIChU VVJOKSBzZXJ2ZXIgZGlzY292ZXJ5DQogICBtZWNoYW5pc21zIGFyZSByZWxhdGl2ZWx5IHN0YXRp YyBhbmQgbGltaXRlZCB0byBleHBsaWNpdA0KICAgY29uZmlndXJhdGlvbi4gIFRoZXNlIGFyZSB1 c3VhbGx5IHVuZGVyIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb250cm9sIG9mDQogICB0aGUgYXBwbGlj YXRpb24gb3IgVFVSTiBzZXJ2aWNlIHByb3ZpZGVyLCBhbmQgbm90IHRoZSBlbnRlcnByaXNlIG9y DQogICB0aGUgSVNQIG9uIHdob3NlIG5ldHdvcmsgdGhlIGNsaWVudCBpcyBsb2NhdGVkLiAgRW50 ZXJwcmlzZXMgYW5kIElTUHMNCiAgIHdpc2hpbmcgdG8gcHJvdmlkZSB0aGVpciBvd24gVFVSTiBz ZXJ2ZXJzIG5lZWQgYXV0byBkaXNjb3ZlcnkNCiAgIG1lY2hhbmlzbXMgdGhhdCBhIFRVUk4gY2xp ZW50IGNvdWxkIHVzZSB3aXRoIG5vIG9yIG1pbmltYWwNCiAgIGNvbmZpZ3VyYXRpb24uICBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyB0d28gc3VjaCBtZWNoYW5pc21zIGZvciBUVVJODQogICBzZXJ2 ZXIgZGlzY292ZXJ5Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg c3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxh YmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From simon.perreault@viagenie.ca Tue Feb 11 06:17:39 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844CE1A0381 for ; Tue, 11 Feb 2014 06:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 JN8wtx8IrUuL for ; Tue, 11 Feb 2014 06:17:38 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 08D281A032D for ; Tue, 11 Feb 2014 06:17:37 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 290D240447 for ; Tue, 11 Feb 2014 09:17:37 -0500 (EST) Message-ID: <52FA3100.60906@viagenie.ca> Date: Tue, 11 Feb 2014 09:17:36 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140211051944.2479.50189.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A242ABB49@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242ABB49@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 14:17:39 -0000 Le 2014-02-11 00:26, Tirumaleswar Reddy (tireddy) a écrit : > This document describes two mechanisms to auto discover TURN server. Please review and provide your valuable comments. Nice. A few comments/questions... 1. Does WPAD play any role in this? Why/why not? (DHCP options are often inaccessible/very hard to get to from end-user applications, namely browsers.) 2. About the anycast mechanism: When a client requires TURN services, it sends a TURN allocate request to the assigned anycast address. The responding TURN anycast server puts its own unicast address as the source address in the reply message. That won't work because it won't get through most firewalls and many NATs. The response's 5-tuple has to be the same as the request's. I suggest you look into the 300 (Try Alternate) response mechanism. The response would contain the unicast address in an ALTERNATE-SERVER attribute. See also RFC 5766 section 2.9. 3. It would be nice to make anycast work with TCP. 4. In the IANA Considerations section, it seems you are requesting a single IPv4 address and a single IPv6 address. If we want anycast to work across AS boundaries, we need to request a /24 and a /48, respectively. I think we want that, so that TURN service can easily be provided by a third party. (On the other hand, single addresses are interesting security-wise in that they won't travel very far in BGP.) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From gsalguei@cisco.com Tue Feb 11 07:51:53 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9C51A05CD for ; Tue, 11 Feb 2014 07:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 vR0liJycratL for ; Tue, 11 Feb 2014 07:51:50 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 227101A05D5 for ; Tue, 11 Feb 2014 07:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2200; q=dns/txt; s=iport; t=1392133910; x=1393343510; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=NR7F8y5nRxEXOEcoNPYeZ7NNGCWSXgNfkuW8EsUQUKQ=; b=bw+kRZCJzRvr9El0EzBkSte1llCTECRGEwiIUEZRMvuBUzJxVBg8FcVd APr75xsjEEwxoI0MZ5cuN9VyMJPtWq/uzX2P92u+AOryPudCwZIcfOozC EZgf030hEf4TB/G1IH/wRHNf8TvD/fEYmSLkVammAT7Ch+0URkxRIrvTk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAANG+lKtJXG9/2dsb2JhbABZgww4V75ogRIWdIIlAQEBAwEBAQE3NBsCAQg2ECcLJQIEEwmHdAgNyEAXjkY1BYMkgRQEmCqBMosuhUCDLYIq X-IronPort-AV: E=Sophos;i="4.95,826,1384300800"; d="scan'208";a="303325185" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 11 Feb 2014 15:51:49 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1BFpnYG012974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 11 Feb 2014 15:51:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 09:51:49 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: "tram@ietf.org" Thread-Topic: I-D Action: draft-petithuguenin-tram-stun-dtls-00.txt Thread-Index: AQHPJ0ApXqUd4o9GM0izue11WIzkXZqwmGuA Date: Tue, 11 Feb 2014 15:51:48 +0000 Message-ID: <4DEDC810-7F25-4F01-B811-A1F6F5181378@cisco.com> References: <20140211154410.24151.98416.idtracker@ietfa.amsl.com> In-Reply-To: <20140211154410.24151.98416.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.154.240] Content-Type: text/plain; charset="us-ascii" Content-ID: <5974A1577F883D4690FBD2E971E7FCA0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tram] I-D Action: draft-petithuguenin-tram-stun-dtls-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 15:51:53 -0000 Folks -=20 Based on comments on this list, we have recast the TURN over DTLS draft (dr= aft-petithuguenin-tram-stun-dtls-00)as a STUN over DTLS draft. Feedback is greatly appreciated and, if timely (and reasonable), will be ad= dressed prior to the draft submission deadline. Cheers, Gonzalo On Feb 11, 2014, at 10:44 AM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Datagram Transport Layer Security (DTLS) as Tran= sport for Session Traversal Utilities for NAT (STUN) > Authors : Marc Petit-Huguenin > Gonzalo Salgueiro > Filename : draft-petithuguenin-tram-stun-dtls-00.txt > Pages : 14 > Date : 2014-02-11 >=20 > Abstract: > This document specifies the usage of Datagram Transport Layer > Security (DTLS) as a transport protocol for Session Traversal > Utilities for NAT (STUN). It provides guidances on when and how to > use DTLS with the currently standardized STUN Usages. It also > specifies modifications to the STUN URIs and TURN URIs and to the > TURN resolution mechanism to facilitate the resolution of STUN URIs > and TURN URIs into the IP address and port of STUN and TURN servers > supporting DTLS as a transport protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-petithuguenin-tram-stun-dtls/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-petithuguenin-tram-stun-dtls-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From dwing@cisco.com Tue Feb 11 08:47:51 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62D11A0619 for ; Tue, 11 Feb 2014 08:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.505 X-Spam-Level: X-Spam-Status: No, score=-13.505 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 GCHvXGvylWjK for ; Tue, 11 Feb 2014 08:47:46 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 903BE1A05CD for ; Tue, 11 Feb 2014 08:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14566; q=dns/txt; s=iport; t=1392137266; x=1393346866; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=46tMbVvI0B96hXAUTkJkvMsa1wJkzjfpaIDuqTxaPgw=; b=AphbHDyCSuz5xltW9botMCoRx1f+VcnHH2teD5FssvEwqByX5XrTojuk 5J3e4VuTKBILd1gZUbBxB82JRhUqSpF6urJQzfJx2x7U4j3wVGGlF1hPD iXwWqg9T6G4c9yi3SN4Rn/ccrlf/7b5cAKOrakGsOR5DeReC2GP9/rsu2 k=; X-IronPort-AV: E=Sophos;i="4.95,826,1384300800"; d="scan'208,217";a="105427924" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 11 Feb 2014 16:47:45 +0000 Received: from [10.85.165.35] ([10.85.165.35]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1BGlahV002116; Tue, 11 Feb 2014 16:47:44 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_58B48E04-00BC-4425-A88D-D6175B2610D3" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: Date: Mon, 10 Feb 2014 21:39:11 -0800 Message-Id: <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> To: Justin Uberti X-Mailer: Apple Mail (2.1510) Cc: tireddy@icisco.com, Karl Stahl , "tram@ietf.org" , Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 16:47:51 -0000 --Apple-Mail=_58B48E04-00BC-4425-A88D-D6175B2610D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: > Good to see there is a lot of interest for this milestone. But based = on the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. +1. I would prefer allowing flows to establish themselves using their 'best' = path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all). This seems = problematic. Perhaps we need a way to signal the desired use-case = ("trait"), or as Justin suggests, using a different technology for some = of these use-cases. -d >=20 >=20 > On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: > Simon, >=20 > Good questions - see inline below --> . > Some more thought is required! >=20 > /Karl >=20 > -----Ursprungligt meddelande----- > Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon Perreault > Skickat: den 10 februari 2014 15:16 > Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com > =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs >=20 > Karl, >=20 > It is great to see such enthusiasm! Thanks! >=20 > I have a couple technical questions... >=20 > Le 2014-02-08 08:11, Karl Stahl a =E9crit : > > - Note that to achieve some of the above points, TURN must be = favored > > over STUN to enforce that the TURN-path actually is used. (The = Anycast > > method suggested below, =93automatically=94 does this.) >=20 > I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? >=20 > --- Good point - I was a bit quick here (maybe too quick) > We have given this quite bit of thought, since even if a TURN server = is provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). >=20 > The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =93automatically=94 within quotes.) >=20 > BUT, since you brought up the question, assuming that we have the = power to enforce WebRTC usage of ICE, I believe a MUST requirement to = use an auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) >=20 >=20 > > - 3^rd The Anycast method below =96 I see no problem > > > > It also has the advantage of encouraging (but not requiring) the > > STUN/TURN to be built in the default gateway or NAT/firewall/access > > router itself, with a second interface to a public IP address on the > > WAN side. (Current volume deployed, low cost NSP triple play modems > > usually have a quality assured level 2 or level 3 WAN pipe for just > > voice (and another for IPTV) =96 The anycast discovered TURN-server = can > > be the access gateway to such quality pipe for WebRTC media, in a > > single NSP provided CPE, scaling from residential and up.) >=20 > Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for > 6to4 relays. Or just bad BGP outbound filter configuration. And how = can we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. >=20 > --- Good point - needs to be resolved. For this I don't have a ready = answer... > An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. >=20 > Is there a good way for the browser to check that the anycast address = is not handled beyond the network service provider's default gateway? = Ideas? >=20 >=20 >=20 > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram --Apple-Mail=_58B48E04-00BC-4425-A88D-D6175B2610D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 juberti@google.com> = wrote:

Good to see there is a lot of interest = for this milestone. But based on the description here, it seems like we = want to use TURN primarily to identify WebRTC flows, as opposed to using = it as a NAT traversal tool. This makes me concerned that we may be using = the wrong technology to solve the = problem.

+1.

I would prefer allowing flows to establish themselves using their = 'best' path, and the best path is seldom through a TURN server. =  When we imagine IPv6 in our future, we don't want to force an = application-level proxy (TURN) server on the path solely for traversing = an IPv6 firewall.


It seems this = thread is conflating all the possible reasons / justifications for = TURN:
  * mobility
  * NAT traversal (both = endpoints are behind endpoint-dependent mapping NATs)
  = * firewall traversal (firewall blocks UDP)
  * = enhancing privacy

Unfortunately the TURN server = nor the endpoint really know which of those use-cases is desired (by the = user or by the IT network administrator) or necessary (for the call to = work at all).  This seems problematic.  Perhaps we need a way = to signal the desired use-case ("trait"), or as Justin suggests, using a = different technology for some of these = use-cases.

-d


=


On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:
Simon,

Good questions - see inline below --> .
Some more thought is required!

/Karl

-----Ursprungligt meddelande-----
Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r = Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com
=C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs

Karl,

It is great to see such enthusiasm! Thanks!

I have a couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a =E9crit :
> - Note that to achieve some of the above points, TURN must be = favored
> over STUN to enforce that the TURN-path actually is used. (The = Anycast
> method suggested below, =93automatically=94 does this.)

I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain?

--- Good point - I was a bit quick here (maybe too quick)
We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =93automatically=94 within quotes.)

BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.)


> - 3^rd The Anycast method below =96 I see no problem
>
> It also has the advantage of encouraging (but not requiring) = the
> STUN/TURN to be built in the default gateway or = NAT/firewall/access
> router itself, with a second interface to a public IP address on = the
> WAN side. (Current volume deployed, low cost NSP triple play = modems
> usually have a quality assured level 2 or level 3 WAN pipe for = just
> voice (and another for IPTV) =96 The anycast discovered TURN-server = can
> be the access gateway to such quality pipe for WebRTC media, in = a
> single NSP provided CPE, scaling from residential and up.)

Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done = for
6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet.

--- Good point - needs to be resolved. For this I don't have a = ready answer...
An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms.

Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> = http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

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

_______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tram

= --Apple-Mail=_58B48E04-00BC-4425-A88D-D6175B2610D3-- From pkyzivat@alum.mit.edu Tue Feb 11 09:07:04 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AAA1A0654 for ; Tue, 11 Feb 2014 09:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 Qjr_uHMOiTqg for ; Tue, 11 Feb 2014 09:07:01 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id AD7AF1A0675 for ; Tue, 11 Feb 2014 09:07:00 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta09.westchester.pa.mail.comcast.net with comcast id R4gD1n0050bG4ec59570hV; Tue, 11 Feb 2014 17:07:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id R56z1n00J3ZTu2S3P56zko; Tue, 11 Feb 2014 17:07:00 +0000 Message-ID: <52FA58B3.60005@alum.mit.edu> Date: Tue, 11 Feb 2014 12:06:59 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392138420; bh=X3n+xAstykGSKZZvK3vieulOlLwDAcGd8U87wv64+yQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HRYyjdGvjGSf/fULodbcv/s7ub734SSaG/meg+tJq1AlxvKhn7mso6DYUsjIh0YRf /33yUzYZ66b/ywDVdJ9PUDCdXVg1oSmUuOr72gqC2TtpFMx9l7DBU96a18JbsbuFDm oqRvbGgV4u+yHnZozbz0jgfLfqDlkmMr9zzFKmk++sCIhSDmGjgoimNGYfTaVQYwse iObG5K+tCJB3M/y7QoxclMisKh75Qf9Ho628GLPLa+vkDCL0eSxbLMyb64u5vdGEdC t7yVFYXaBfgZBezg1a1XRmCqmwSWOVBbhiERKV5dLEWuTjzHa3LAIgXZ4bSutpelsv 8fcMeJdvbriIw== Subject: [tram] Suggestion for draft-patil-tram-turn-serv-disc-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 17:07:05 -0000 IMO there is another variant on Service Resolution: A target domain that wants to make itself more reachable could advertise a TURN server via NAPTR on its domain name. So a caller of sip:foo@bar.com could use bar.com as one of the "retrieved domain names" that are candidates for resolution. Thanks, Paul From marc.blanchet@viagenie.ca Tue Feb 11 09:09:04 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499BC1A0659 for ; Tue, 11 Feb 2014 09:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 mlDLQXhS3Y0g for ; Tue, 11 Feb 2014 09:09:00 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4AB1A067E for ; Tue, 11 Feb 2014 09:08:53 -0800 (PST) Received: from [IPv6:2620::230:c000:294d:8cc1:5380:4d0c] (unknown [IPv6:2620:0:230:c000:294d:8cc1:5380:4d0c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0213B403AB; Tue, 11 Feb 2014 12:08:51 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_29B6F214-E385-4A8E-8965-8C0FC3FDB692" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Marc Blanchet In-Reply-To: <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> Date: Tue, 11 Feb 2014 12:08:51 -0500 Message-Id: <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> To: Dan Wing X-Mailer: Apple Mail (2.1827) Cc: tireddy@icisco.com, Karl Stahl , Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 17:09:04 -0000 --Apple-Mail=_29B6F214-E385-4A8E-8965-8C0FC3FDB692 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Le 2014-02-11 =E0 00:39, Dan Wing a =E9crit : >=20 > On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: >=20 >> Good to see there is a lot of interest for this milestone. But based = on the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. >=20 > +1. >=20 > I would prefer allowing flows to establish themselves using their = 'best' path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. >=20 >=20 > It seems this thread is conflating all the possible reasons / = justifications for TURN: > * mobility > * NAT traversal (both endpoints are behind endpoint-dependent = mapping NATs) > * firewall traversal (firewall blocks UDP) > * enhancing privacy >=20 > Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all). Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. > This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. >=20 > -d >=20 >=20 >=20 >>=20 >>=20 >> On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: >> Simon, >>=20 >> Good questions - see inline below --> . >> Some more thought is required! >>=20 >> /Karl >>=20 >> -----Ursprungligt meddelande----- >> Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon Perreault >> Skickat: den 10 februari 2014 15:16 >> Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com >> =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs >>=20 >> Karl, >>=20 >> It is great to see such enthusiasm! Thanks! >>=20 >> I have a couple technical questions... >>=20 >> Le 2014-02-08 08:11, Karl Stahl a =E9crit : >> > - Note that to achieve some of the above points, TURN must be = favored >> > over STUN to enforce that the TURN-path actually is used. (The = Anycast >> > method suggested below, =93automatically=94 does this.) >>=20 >> I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? >>=20 >> --- Good point - I was a bit quick here (maybe too quick) >> We have given this quite bit of thought, since even if a TURN server = is provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). >>=20 >> The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =93automatically=94 within quotes.) >>=20 >> BUT, since you brought up the question, assuming that we have the = power to enforce WebRTC usage of ICE, I believe a MUST requirement to = use an auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) >>=20 >>=20 >> > - 3^rd The Anycast method below =96 I see no problem >> > >> > It also has the advantage of encouraging (but not requiring) the >> > STUN/TURN to be built in the default gateway or NAT/firewall/access >> > router itself, with a second interface to a public IP address on = the >> > WAN side. (Current volume deployed, low cost NSP triple play modems >> > usually have a quality assured level 2 or level 3 WAN pipe for just >> > voice (and another for IPTV) =96 The anycast discovered TURN-server = can >> > be the access gateway to such quality pipe for WebRTC media, in a >> > single NSP provided CPE, scaling from residential and up.) >>=20 >> Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for >> 6to4 relays. Or just bad BGP outbound filter configuration. And how = can we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. >>=20 >> --- Good point - needs to be resolved. For this I don't have a ready = answer... >> An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. >>=20 >> Is there a good way for the browser to check that the anycast address = is not handled beyond the network service provider's default gateway? = Ideas? >>=20 >>=20 >>=20 >> Thanks, >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram --Apple-Mail=_29B6F214-E385-4A8E-8965-8C0FC3FDB692 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Le = 2014-02-11 =E0 00:39, Dan Wing <dwing@cisco.com> a =E9crit = :


On Feb 10, 2014, at = 5:30 PM, Justin Uberti <juberti@google.com> = wrote:

Good to see there is a lot of interest = for this milestone. But based on the description here, it seems like we = want to use TURN primarily to identify WebRTC flows, as opposed to using = it as a NAT traversal tool. This makes me concerned that we may be using = the wrong technology to solve the = problem.

+1.

I would prefer allowing flows to establish themselves using their = 'best' path, and the best path is seldom through a TURN server. =  When we imagine IPv6 in our future, we don't want to force an = application-level proxy (TURN) server on the path solely for traversing = an IPv6 firewall.


It seems this = thread is conflating all the possible reasons / justifications for = TURN:
  * mobility
  * NAT traversal (both = endpoints are behind endpoint-dependent mapping NATs)
  = * firewall traversal (firewall blocks UDP)
  * = enhancing privacy

Unfortunately the TURN server = nor the endpoint really know which of those use-cases is desired (by the = user or by the IT network administrator) or necessary (for the call to = work at all).

Dan, while I = agree in principle, I doubt that a user could ever say "I want mobility = or I want NAT traversal". I think the user only want the call to = succeed, whatever the properties of its network point of attachment = are.

 This seems problematic. =  Perhaps we need a way to signal the desired use-case ("trait"), or = as Justin suggests, using a different technology for some of these = use-cases.

-d


=


On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:
Simon,

Good = questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt meddelande-----
Fr=E5n:= tram [mailto:tram-bounces@ietf.org] F=F6r = Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C4mne: Re: = [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise = and ISPs

Karl,

It is great to see such = enthusiasm! Thanks!

I have a couple technical = questions...

Le 2014-02-08 08:11, Karl Stahl a =E9crit :
> = - Note that to achieve some of the above points, TURN must be = favored
> over STUN to enforce that the TURN-path actually is = used. (The Anycast
> method suggested below, =93automatically=94 = does this.)

I understand the STUN vs TURN priority issue. But I = don't see how anycast affects it in any way. Can you please = explain?

--- Good point - I was a bit quick here (maybe too = quick)
We have given this quite bit of thought, since even if a TURN = server is provided and discovered, CURRENT usage of ICE may suggest a = candidate from the remote party that will make a connection without the = need/usage of the TURN server (that we wanted to be used for the good = purposes listed).

The only way we found around this, was to stop = STUN through the IP default gateway (like a restrictive Enterprise = firewall does inhibiting ICE connectivity, which others are concerned = about...). Since the provisioning of auto-discovery using the anycast = mechanism, would be adding a route in a default gateway, adding a = firewall rule to eat STUN packets would assure that the provisioned TURN = server actually becomes used (and not bypassed "by accident"). (That was = the thought behind the =93automatically=94 within quotes.)

BUT, = since you brought up the question, assuming that we have the power to = enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.)


> - 3^rd The Anycast method = below =96 I see no problem
>
> It also has the advantage of = encouraging (but not requiring) the
> STUN/TURN to be built in the = default gateway or NAT/firewall/access
> router itself, with a = second interface to a public IP address on the
> WAN side. = (Current volume deployed, low cost NSP triple play modems
> = usually have a quality assured level 2 or level 3 WAN pipe for = just
> voice (and another for IPTV) =96 The anycast discovered = TURN-server can
> be the access gateway to such quality pipe for = WebRTC media, in a
> single NSP provided CPE, scaling from = residential and up.)

Suppose we define well-known anycast TURN = server addresses. How would this not be subject to the same service = quality issues that plagued 6to4? That is, anyone could set up a = badly-maintained, under-provisioned TURN server and announce it over BGP = to the world, as it was done for
6to4 relays. Or just bad BGP = outbound filter configuration. And how can we prevent triangle routing? = There is nothing guaranteeing that the anycast server you see is being = provided to you by your ISP, rather than a server sitting on the other = side of the planet.

--- Good point - needs to be resolved. = For this I don't have a ready answer...
An auto-discovered TURN = server must be trusted (whatever method it is discovered by). We are = trusting the one providing us with an IP address and default gateway = anyway. It would be easy if we could reuse that trust, instead of = another mechanisms.

Is there a good way for the browser to check = that the anycast address is not handled beyond the network service = provider's default gateway? Ideas?



Thanks,
Simon
--
DTN made easy, lean, = and smart --> http://postellation.viagenie.ca
NAT64/DNS64 = open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server =               --> http://numb.viagenie.ca
_________________________= ______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

__= _____________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram
=

_______________________________________= ________
tram mailing list
tram@ietf.org
https://www.ietf.org/m= ailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram
= --Apple-Mail=_29B6F214-E385-4A8E-8965-8C0FC3FDB692-- From dwing@cisco.com Tue Feb 11 09:25:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C8C1A05CD for ; Tue, 11 Feb 2014 09:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 P4UcjlrObhSH for ; Tue, 11 Feb 2014 09:25:07 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1BA1A063F for ; Tue, 11 Feb 2014 09:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21437; q=dns/txt; s=iport; t=1392139507; x=1393349107; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=nX0Oy6XV8lEH+l5sDN2ur0IYAuJizVcvcW7HLmFRQHE=; b=dwG3E1gf4MZR6fvkmUkppNQBYZ1H9Iby0F/6ZeVMvx3aVLoe2+3a5MQW NqdwcoXlsfEEUSatlcK/CtYJS+QeiZDe8FaaqFn8ZcyiJgFXNgQnxlZUb FzOIs/dl7kYbtycIzFys8Vvme1NUrHDRSd0RLoOXbIXFxiVivCjkDWHXs E=; X-IronPort-AV: E=Sophos;i="4.95,826,1384300800"; d="scan'208,217";a="105486510" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 11 Feb 2014 17:25:06 +0000 Received: from [10.85.165.35] ([10.85.165.35]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1BHP3FT015543; Tue, 11 Feb 2014 17:25:04 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_A1240F38-B833-4139-827D-284FBC8EA4D9" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> Date: Tue, 11 Feb 2014 09:25:03 -0800 Message-Id: <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.1510) Cc: tireddy@icisco.com, Karl Stahl , Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 17:25:11 -0000 --Apple-Mail=_A1240F38-B833-4139-827D-284FBC8EA4D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Feb 11, 2014, at 9:08 AM, Marc Blanchet = wrote: > Le 2014-02-11 =E0 00:39, Dan Wing a =E9crit : >=20 >>=20 >> On Feb 10, 2014, at 5:30 PM, Justin Uberti = wrote: >>=20 >>> Good to see there is a lot of interest for this milestone. But based = on the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. >>=20 >> +1. >>=20 >> I would prefer allowing flows to establish themselves using their = 'best' path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. >>=20 >>=20 >> It seems this thread is conflating all the possible reasons / = justifications for TURN: >> * mobility >> * NAT traversal (both endpoints are behind endpoint-dependent = mapping NATs) >> * firewall traversal (firewall blocks UDP) >> * enhancing privacy >>=20 >> Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all). >=20 > Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN = server will do, and the endpoint should prefer TURN candidates over all = others because there might be some functionality / usefulness of TURN = that the user might gain through TURN (e.g., enhanced privacy)? -d >=20 >> This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. >>=20 >> -d >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: >>> Simon, >>>=20 >>> Good questions - see inline below --> . >>> Some more thought is required! >>>=20 >>> /Karl >>>=20 >>> -----Ursprungligt meddelande----- >>> Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon Perreault >>> Skickat: den 10 februari 2014 15:16 >>> Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com >>> =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs >>>=20 >>> Karl, >>>=20 >>> It is great to see such enthusiasm! Thanks! >>>=20 >>> I have a couple technical questions... >>>=20 >>> Le 2014-02-08 08:11, Karl Stahl a =E9crit : >>> > - Note that to achieve some of the above points, TURN must be = favored >>> > over STUN to enforce that the TURN-path actually is used. (The = Anycast >>> > method suggested below, =93automatically=94 does this.) >>>=20 >>> I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? >>>=20 >>> --- Good point - I was a bit quick here (maybe too quick) >>> We have given this quite bit of thought, since even if a TURN server = is provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). >>>=20 >>> The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =93automatically=94 within quotes.) >>>=20 >>> BUT, since you brought up the question, assuming that we have the = power to enforce WebRTC usage of ICE, I believe a MUST requirement to = use an auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) >>>=20 >>>=20 >>> > - 3^rd The Anycast method below =96 I see no problem >>> > >>> > It also has the advantage of encouraging (but not requiring) the >>> > STUN/TURN to be built in the default gateway or = NAT/firewall/access >>> > router itself, with a second interface to a public IP address on = the >>> > WAN side. (Current volume deployed, low cost NSP triple play = modems >>> > usually have a quality assured level 2 or level 3 WAN pipe for = just >>> > voice (and another for IPTV) =96 The anycast discovered = TURN-server can >>> > be the access gateway to such quality pipe for WebRTC media, in a >>> > single NSP provided CPE, scaling from residential and up.) >>>=20 >>> Suppose we define well-known anycast TURN server addresses. How = would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for >>> 6to4 relays. Or just bad BGP outbound filter configuration. And how = can we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. >>>=20 >>> --- Good point - needs to be resolved. For this I don't have a ready = answer... >>> An auto-discovered TURN server must be trusted (whatever method it = is discovered by). We are trusting the one providing us with an IP = address and default gateway anyway. It would be easy if we could reuse = that trust, instead of another mechanisms. >>>=20 >>> Is there a good way for the browser to check that the anycast = address is not handled beyond the network service provider's default = gateway? Ideas? >>>=20 >>>=20 >>>=20 >>> Thanks, >>> Simon >>> -- >>> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >>> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >>> STUN/TURN server --> http://numb.viagenie.ca >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>>=20 >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>>=20 >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >=20 --Apple-Mail=_A1240F38-B833-4139-827D-284FBC8EA4D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 marc.blanchet@viagenie.ca>= ; wrote:
Le = 2014-02-11 =E0 00:39, Dan Wing <dwing@cisco.com> a =E9crit = :


On Feb 10, 2014, at = 5:30 PM, Justin Uberti <juberti@google.com> = wrote:

Good to see there is a lot of interest = for this milestone. But based on the description here, it seems like we = want to use TURN primarily to identify WebRTC flows, as opposed to using = it as a NAT traversal tool. This makes me concerned that we may be using = the wrong technology to solve the = problem.

+1.

I would prefer allowing flows to establish themselves using their = 'best' path, and the best path is seldom through a TURN server. =  When we imagine IPv6 in our future, we don't want to force an = application-level proxy (TURN) server on the path solely for traversing = an IPv6 firewall.


It seems this = thread is conflating all the possible reasons / justifications for = TURN:
  * mobility
  * NAT traversal (both = endpoints are behind endpoint-dependent mapping NATs)
  = * firewall traversal (firewall blocks UDP)
  * = enhancing privacy

Unfortunately the TURN server = nor the endpoint really know which of those use-cases is desired (by the = user or by the IT network administrator) or necessary (for the call to = work at all).

Dan, while I = agree in principle, I doubt that a user could ever say "I want mobility = or I want NAT traversal". I think the user only want the call to = succeed, whatever the properties of its network point of attachment = are.

So what can we = do?  Should the TURN server provide any and all services the TURN = client might possibly want, as that is what a robust TURN server will = do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced = privacy)?

-d


<= blockquote type=3D"cite">

 This seems problematic. =  Perhaps we need a way to signal the desired use-case ("trait"), or = as Justin suggests, using a different technology for some of these = use-cases.

-d


=


On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:
Simon,

Good = questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt meddelande-----
Fr=E5n:= tram [mailto:tram-bounces@ietf.org] F=F6r = Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C4mne: Re: = [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise = and ISPs

Karl,

It is great to see such = enthusiasm! Thanks!

I have a couple technical = questions...

Le 2014-02-08 08:11, Karl Stahl a =E9crit :
> = - Note that to achieve some of the above points, TURN must be = favored
> over STUN to enforce that the TURN-path actually is = used. (The Anycast
> method suggested below, =93automatically=94 = does this.)

I understand the STUN vs TURN priority issue. But I = don't see how anycast affects it in any way. Can you please = explain?

--- Good point - I was a bit quick here (maybe too = quick)
We have given this quite bit of thought, since even if a TURN = server is provided and discovered, CURRENT usage of ICE may suggest a = candidate from the remote party that will make a connection without the = need/usage of the TURN server (that we wanted to be used for the good = purposes listed).

The only way we found around this, was to stop = STUN through the IP default gateway (like a restrictive Enterprise = firewall does inhibiting ICE connectivity, which others are concerned = about...). Since the provisioning of auto-discovery using the anycast = mechanism, would be adding a route in a default gateway, adding a = firewall rule to eat STUN packets would assure that the provisioned TURN = server actually becomes used (and not bypassed "by accident"). (That was = the thought behind the =93automatically=94 within quotes.)

BUT, = since you brought up the question, assuming that we have the power to = enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.)


> - 3^rd The Anycast method = below =96 I see no problem
>
> It also has the advantage of = encouraging (but not requiring) the
> STUN/TURN to be built in the = default gateway or NAT/firewall/access
> router itself, with a = second interface to a public IP address on the
> WAN side. = (Current volume deployed, low cost NSP triple play modems
> = usually have a quality assured level 2 or level 3 WAN pipe for = just
> voice (and another for IPTV) =96 The anycast discovered = TURN-server can
> be the access gateway to such quality pipe for = WebRTC media, in a
> single NSP provided CPE, scaling from = residential and up.)

Suppose we define well-known anycast TURN = server addresses. How would this not be subject to the same service = quality issues that plagued 6to4? That is, anyone could set up a = badly-maintained, under-provisioned TURN server and announce it over BGP = to the world, as it was done for
6to4 relays. Or just bad BGP = outbound filter configuration. And how can we prevent triangle routing? = There is nothing guaranteeing that the anycast server you see is being = provided to you by your ISP, rather than a server sitting on the other = side of the planet.

--- Good point - needs to be resolved. = For this I don't have a ready answer...
An auto-discovered TURN = server must be trusted (whatever method it is discovered by). We are = trusting the one providing us with an IP address and default gateway = anyway. It would be easy if we could reuse that trust, instead of = another mechanisms.

Is there a good way for the browser to check = that the anycast address is not handled beyond the network service = provider's default gateway? Ideas?



Thanks,
Simon
--
DTN made easy, lean, = and smart --> http://postellation.viagenie.ca
NAT64/DNS64 = open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server =               --> http://numb.viagenie.ca
_________________________= ______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

__= _____________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram
=

_______________________________________= ________
tram mailing list
tram@ietf.org
https://www.ietf.org/m= ailman/listinfo/tram

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

= --Apple-Mail=_A1240F38-B833-4139-827D-284FBC8EA4D9-- From praspati@cisco.com Tue Feb 11 09:40:40 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F751A0631 for ; Tue, 11 Feb 2014 09:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 WgmmRKG5q3Mv for ; Tue, 11 Feb 2014 09:40:38 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 783CE1A05CD for ; Tue, 11 Feb 2014 09:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2462; q=dns/txt; s=iport; t=1392140438; x=1393350038; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=A7RZWxf8fh3iyL4Zsqeh534fe4szK6Qa9YstFObGoo0=; b=myNY208Prioz5Ivy0Jq6xcuC2zB3dfmnom+nSNvZjX7C+GYgnNtw4yMV zKKfSYlwfz/bOJTfJZAxnVWrt6t20IPzFJ4Qxmhv831q4Q1bK4MgadqiI U4RA5W0lJVQZfDc41sSsRT3Q3QaxS2QkIvOAr90jCXXirWZXvztoEP+zC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAMdf+lKtJXG9/2dsb2JhbABagww4V78EgRIWdIIlAQEBBAEBASRHCRICAQhGJwscCQIEARKIBQ3IZheOUy2EOASJEI8agTKQboFvgT6CKg X-IronPort-AV: E=Sophos;i="4.95,826,1384300800"; d="scan'208";a="19618925" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-8.cisco.com with ESMTP; 11 Feb 2014 17:40:36 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1BHeaUj009293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Feb 2014 17:40:36 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.211]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 11:40:36 -0600 From: "Prashanth Patil (praspati)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-00.txt Thread-Index: AQHPJujlhhkvHnd6iEyVomMYFG2jpw== Date: Tue, 11 Feb 2014 17:40:35 +0000 Message-ID: References: <20140211051944.2479.50189.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A242ABB49@xmb-rcd-x10.cisco.com> <52FA3100.60906@viagenie.ca> In-Reply-To: <52FA3100.60906@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.57.129] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1648AF8AE849C54C99DC4716D76EC176@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 17:40:40 -0000 Hi Simon, On 2/11/14 7:47 PM, "Simon Perreault" wrote: >Le 2014-02-11 00:26, Tirumaleswar Reddy (tireddy) a =E9crit : >> This document describes two mechanisms to auto discover TURN server. >>Please review and provide your valuable comments. > >Nice. A few comments/questions... > >1. Does WPAD play any role in this? Why/why not? (DHCP options are often >inaccessible/very hard to get to from end-user applications, namely >browsers.) For WPAD, my understanding is that some browsers use DHCP Inform to request and obtain information from a DHCP server for use in their local configuration. WPAD is a viable option, given that it's used quite a bit. I suppose we could suggest it as an option in the draft, but WPAD is not standardized. > >2. About the anycast mechanism: > > When a client requires TURN services, it sends a TURN allocate > request to the assigned anycast address. The responding TURN anycast > server puts its own unicast address as the source address in the > reply message. > >That won't work because it won't get through most firewalls and many >NATs. The response's 5-tuple has to be the same as the request's. > >I suggest you look into the 300 (Try Alternate) response mechanism. The >response would contain the unicast address in an ALTERNATE-SERVER >attribute. See also RFC 5766 section 2.9. Good point, will update. > >3. It would be nice to make anycast work with TCP. Yep. However, do we really need it in the context of discovery? If a client can discover a server using UDP, the client can choose to subsequently contact the same server over TCP. > >4. In the IANA Considerations section, it seems you are requesting a >single IPv4 address and a single IPv6 address. If we want anycast to >work across AS boundaries, we need to request a /24 and a /48, >respectively. I think we want that, so that TURN service can easily be >provided by a third party. (On the other hand, single addresses are >interesting security-wise in that they won't travel very far in BGP.) -Prashanth > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From simon.perreault@viagenie.ca Tue Feb 11 10:13:28 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D7A1A067E for ; Tue, 11 Feb 2014 10:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 VUKDCG7za_6t for ; Tue, 11 Feb 2014 10:13:26 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7641A066C for ; Tue, 11 Feb 2014 10:13:26 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9B2CD4690E; Tue, 11 Feb 2014 13:13:25 -0500 (EST) Message-ID: <52FA6845.90002@viagenie.ca> Date: Tue, 11 Feb 2014 13:13:25 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Prashanth Patil (praspati)" , "tram@ietf.org" References: <20140211051944.2479.50189.idtracker@ietfa.amsl.com> <913383AAA69FF945B8F946018B75898A242ABB49@xmb-rcd-x10.cisco.com> <52FA3100.60906@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [tram] FW: New Version Notification for draft-patil-tram-turn-serv-disc-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 18:13:29 -0000 Le 2014-02-11 12:40, Prashanth Patil (praspati) a écrit : >> 3. It would be nice to make anycast work with TCP. > > Yep. However, do we really need it in the context of discovery? If a > client can discover a server using UDP, the client can choose to > subsequently contact the same server over TCP. Right, that would be one possible method. One drawback would be that it would confuse the _tcp and _udp SRV stuff, and servers would be forced to provide TCP and UDP service on the same address(es). Another possibility would be to just go ahead and do discovery over TCP. I don't think routing stability would be an issue for such a short-term session. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From karl.stahl@intertex.se Tue Feb 11 11:17:13 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCECB1A070F for ; Tue, 11 Feb 2014 11:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1] autolearn=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 pxneEMndoJFM for ; Tue, 11 Feb 2014 11:17:10 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3F01A06E4 for ; Tue, 11 Feb 2014 11:17:08 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402112017065152; Tue, 11 Feb 2014 20:17:06 +0100 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Simon Perreault'" , , References: <082c01cf17d4$393d7bb0$abb87310$@stahl@intertex.se> <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se> <52F8DF21.2080303@viagenie.ca> <049801cf26b6$5a87db30$0f979190$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A242ABA2D@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242ABA2D@xmb-rcd-x10.cisco.com> Date: Tue, 11 Feb 2014 20:17:05 +0100 Message-ID: <058f01cf275d$da1dc6a0$8e5953e0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPJrZnSgUY4V56JE+wy6rTjZeHIZqvVbIwgAEJXKA= Content-Language: sv Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 19:17:14 -0000 Tireddy wrote below > There are various ways to prioritize WebRTC media = streams and I don't see a need to block P2P connectivity.=20 --- We need not only to think about prioritizing WebRTC, it is about = "traffic shaping also". - If we consider the case of WebRTC traffic over Internet/mobile OTT = (not talking about feeding WebRTC into some =20 application specific network like IMS where they may be other quality = measures), we get lost quality wise already when (if) we allow = prioritized WebRTC traffic to go into a congestion point (like a = NAT/firewall or default gateway, where there may be heavy data traffic = already filling the pipe. - Quality loss here (lost WebRTC media packets) cannot be recovered = later - That is the "need to block P2P connectivity" (which may sound ugly but = is really about assuring that we CAN get P2P connectivity with best = quality, with help of service providers and LAN administrators that want = WebRTC traffic to be good and accessible...) --- Or do see another/better way around this that I cannot see? -----Ursprungligt meddelande----- Fr=C3=A5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Skickat: den 11 februari 2014 03:40 Till: Karl Stahl; 'Simon Perreault'; tram@ietf.org; tireddy@icisco.com =C3=84mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs > The only way we found around this, was to stop STUN through the IP=20 > default gateway (like a restrictive Enterprise firewall does=20 > inhibiting ICE connectivity, which others are concerned about...).=20 > Since the provisioning of auto- discovery using the anycast mechanism, = > would be adding a route in a default gateway, adding a firewall rule=20 > to eat STUN packets would assure that the provisioned TURN server=20 > actually becomes used (and not bypassed "by accident"). (That was the=20 > thought behind the =E2=80=9Cautomatically=E2=80=9D within quotes.) There are various ways to prioritize WebRTC media streams and I don't = see a need to block P2P connectivity.=20 --- We need not only to think about prioritizing WebRTC, it is about = "traffic shaping also". - If we consider the case of WebRTC traffic over Internet/mobile OTT = (not talking about feeding WebRTC into some =20 application specific network like IMS where they may be other quality = measures), we get lost quality wise already when (if) we allow = prioritized WebRTC traffic to go into a congestion point (like a = NAT/firewall or default gateway, where there may be heavy data traffic = already filling the pipe. - Quality loss here (lost WebRTC media packets) cannot be recovered = later - That is the "need to block P2P connectivity" (which may sound ugly but = is really about assuring that we CAN get P2P connectivity with best = quality, with help of service providers and LAN administrators that want = WebRTC traffic to be good and accessible...) --- Or do see another/better way around this that I cannot see? Using TURN server itself endpoint can learn server-reflexive = candidates. If there is a restrictive firewall that blocks P2P = connectivity then relayed candidate would eventually be nominated = because ICE connectivity check fails with other candidate types.=20 I don't see any need to advertise only relayed candidates in the = offer/answer other than for privacy reasons. -Tiru. > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl > Sent: Tuesday, February 11, 2014 4:48 AM > To: 'Simon Perreault'; tram@ietf.org; tireddy@icisco.com > Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism=20 > for enterprise and ISPs >=20 > Simon, >=20 > Good questions - see inline below --> . > Some more thought is required! >=20 > /Karl >=20 > -----Ursprungligt meddelande----- > Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon = Perreault > Skickat: den 10 februari 2014 15:16 > Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com > =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery = mechanism for=20 > enterprise and ISPs >=20 > Karl, >=20 > It is great to see such enthusiasm! Thanks! >=20 > I have a couple technical questions... >=20 > Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > > - Note that to achieve some of the above points, TURN must be=20 > > favored over STUN to enforce that the TURN-path actually is used.=20 > > (The Anycast method suggested below, =E2=80=9Cautomatically=E2=80=9D = does this.) >=20 > I understand the STUN vs TURN priority issue. But I don't see how=20 > anycast affects it in any way. Can you please explain? >=20 > --- Good point - I was a bit quick here (maybe too quick) We have=20 > given this quite bit of thought, since even if a TURN server is=20 > provided and discovered, CURRENT usage of ICE may suggest a candidate=20 > from the remote party that will make a connection without the=20 > need/usage of the TURN server (that we wanted to be used for the good = purposes listed). >=20 > The only way we found around this, was to stop STUN through the IP=20 > default gateway (like a restrictive Enterprise firewall does=20 > inhibiting ICE connectivity, which others are concerned about...).=20 > Since the provisioning of auto- discovery using the anycast mechanism, = > would be adding a route in a default gateway, adding a firewall rule=20 > to eat STUN packets would assure that the provisioned TURN server=20 > actually becomes used (and not bypassed "by accident"). (That was the=20 > thought behind the =E2=80=9Cautomatically=E2=80=9D within quotes.) >=20 > BUT, since you brought up the question, assuming that we have the=20 > power to enforce WebRTC usage of ICE, I believe a MUST requirement to=20 > use an auto- discovered TURN server instead of STUN, would solve the = same problem. > However, thinking further (in relation to your next question - "anyone = > could set up a badly-maintained" - enforcing such ICE usage may not be = > good.) >=20 >=20 > > - 3^rd The Anycast method below =E2=80=93 I see no problem > > > > It also has the advantage of encouraging (but not requiring) the=20 > > STUN/TURN to be built in the default gateway or NAT/firewall/access=20 > > router itself, with a second interface to a public IP address on the = > > WAN side. (Current volume deployed, low cost NSP triple play modems=20 > > usually have a quality assured level 2 or level 3 WAN pipe for just=20 > > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server=20 > > can be the access gateway to such quality pipe for WebRTC media, in=20 > > a single NSP provided CPE, scaling from residential and up.) >=20 > Suppose we define well-known anycast TURN server addresses. How would=20 > this not be subject to the same service quality issues that plagued=20 > 6to4? That is, anyone could set up a badly-maintained,=20 > under-provisioned TURN server and announce it over BGP to the world,=20 > as it was done for > 6to4 relays. Or just bad BGP outbound filter configuration. And how=20 > can we prevent triangle routing? There is nothing guaranteeing that=20 > the anycast server you see is being provided to you by your ISP,=20 > rather than a server sitting on the other side of the planet. >=20 > --- Good point - needs to be resolved. For this I don't have a ready = answer... > An auto-discovered TURN server must be trusted (whatever method it is=20 > discovered by). We are trusting the one providing us with an IP=20 > address and default gateway anyway. It would be easy if we could reuse = > that trust, instead of another mechanisms. >=20 > Is there a good way for the browser to check that the anycast address=20 > is not handled beyond the network service provider's default gateway? = Ideas? >=20 >=20 >=20 > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From karl.stahl@intertex.se Tue Feb 11 14:37:16 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEACF1A07BD for ; Tue, 11 Feb 2014 14:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 piRdiqlXNeku for ; Tue, 11 Feb 2014 14:37:10 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id A1ED31A078F for ; Tue, 11 Feb 2014 14:37:08 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402112337055411; Tue, 11 Feb 2014 23:37:05 +0100 From: "Karl Stahl" To: "'Dan Wing'" , "'Marc Blanchet'" References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> In-Reply-To: <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> Date: Tue, 11 Feb 2014 23:37:04 +0100 Message-ID: <05b601cf2779$c9f4e670$5ddeb350$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05B7_01CF2782.2BB94E70" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8nTjb1nqu6bZ2PRc2zBs2biZuxxgAD73bA Content-Language: sv Cc: tireddy@icisco.com, 'Simon Perreault' , tram@ietf.org, 'Justin Uberti' Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 22:37:17 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_05B7_01CF2782.2BB94E70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Listening to this thread, I am afraid we are missing the very point and necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle routing",need a = new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =93TURN=85to identify WebRTC flows=94 etc! It is not = a mistake, but the very need for this milestone! =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw/problem is that quality things were not (could not be?) considered. The method=92s very idea (like all similar = methods for getting RTC through ordinary NAT/Firewalls) is to fool the media = through a NAT/Firewall that is unaware of what is happening. Thus, this is root = of quality issues (and bandwidth allocation optimization) that needs to be dealt with: Real-time traffic fighting with a data traffic crowded congestion point. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get media through (and of course with as good quality as required and possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =93TURN=85to identify WebRTC flows=94 It is also the ONLY way I can see to achieve what we want to achieve and should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not feeding WebRTC into application specific networks like IMS where other methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =93because it is all about = bandwidth=94, =93it will resolve itself with time=94 etc., I strongly object! That is = wrong and will be very detrimental for WebRTC usage. We already see it and I = can give numerous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad = considering quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and would = fight the same battle. But hopefully, those days are (soon) over =96 At least forward thinking carrier=92s realize that already. Web RTC will happen. = Which customers want to pay for an access with blocked WebRTC? The carrier=92s offering/assuring good WebRTC will rather get the customers and income = J. (Maybe the Web browser can detect and encourage this=85) =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the browser that there are good media paths to be used, and that the web browser automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone.=20 =20 /Karl =20 =20 Fr=E5n: Dan Wing [mailto:dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; = Simon Perreault =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet wrote: Le 2014-02-11 =E0 00:39, Dan Wing a =E9crit : On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. This makes = me concerned that we may be using the wrong technology to solve the = problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the call = to succeed, whatever the properties of its network point of attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the user = might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 This seems problematic. Perhaps we need a way to signal the desired use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =E9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =93automatically=94 does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage of = the TURN server (that we wanted to be used for the good purposes listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be adding a route = in a default gateway, adding a firewall rule to eat STUN packets would assure that the provisioned TURN server actually becomes used (and not bypassed = "by accident"). (That was the thought behind the =93automatically=94 within = quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - "anyone = could set up a badly-maintained" - enforcing such ICE usage may not be good.) > - 3^rd The Anycast method below =96 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =96 The anycast discovered TURN-server = can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued 6to4? = That is, anyone could set up a badly-maintained, under-provisioned TURN = server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the anycast server you see is being provided to you by your ISP, rather than a = server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready answer... An auto-discovered TURN server must be trusted (whatever method it is discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca =20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca =20 STUN/TURN server --> http://numb.viagenie.ca =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_05B7_01CF2782.2BB94E70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

 

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - = NSPs (Network Service Providers) want to provide a path where the = bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic. =

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

 

Th= is leads us into =A0“= TURN…to identify WebRTC flows” etc! It is not a mistake, but the very need for = this milestone!

 

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method’s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion = point.

 

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

 

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help!

 

Ho= pe this made it understandable on an overview level how this can = become = “TURN…to identify WebRTC flows”

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this = milestone.

 

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

 

Th= is is good, not evil!

 

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues “because it is all about = bandwidth”, “it will resolve itself with time” etc., I = strongly object! That is wrong and will be very detrimental for WebRTC = usage. We already see it and I can give numerous examples of how much = less quality demanding VoIP is/is not handled quality wise and that it = matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with them?

 

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = – At least forward thinking carrier’s realize that already. = Web RTC will happen. Which customers want to pay for an access with = blocked WebRTC? The carrier’s offering/assuring good WebRTC will = rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this…)

 

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone. =

 

/K= arl

 

 

Fr=E5n: Dan Wing = [mailto:dwing@cisco.com]
Skickat: den 11 februari 2014 = 18:25
Till: Marc = Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; = tram@ietf.org; Simon Perreault
=C4mne: Re: [tram] Milestone 3: = TURN server auto-discovery mechanism for enterprise and = ISPs

 

 

On = Feb 11, 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca&g= t; wrote:



Le = 2014-02-11 =E0 00:39, Dan Wing <dwing@cisco.com> a =E9crit = :




On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> = wrote:



Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 = ;

+1.

 = ;

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 = ;

 = ;

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks = UDP)

  * = enhancing privacy

 = ;

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all). =

 

Dan, while I agree in principle, I doubt that a user = could ever say "I want mobility or I want NAT traversal". I = think the user only want the call to succeed, whatever the properties of = its network point of attachment = are.

 

So what can we do?  Should the TURN server = provide any and all services the TURN client might possibly want, as = that is what a robust TURN server will do, and the endpoint should = prefer TURN candidates over all others because there might be some = functionality / usefulness of TURN that the user might gain through TURN = (e.g., enhanced privacy)?

 

-d

 

 



 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these = use-cases.

 = ;

-d

 = ;

 = ;



 = ;

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r = Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C4mne: Re: = [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise = and ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =E9crit :
> - Note that to achieve some of the above points, TURN = must be favored
> over STUN to enforce that the TURN-path actually = is used. (The Anycast
> method suggested below, = “automatically” does this.)

I understand the STUN vs = TURN priority issue. But I don't see how anycast affects it in any way. = Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the “automatically” within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below – I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) – The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 = open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server =               --> http://numb.viagenie.ca
________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

_= ______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 = ;

__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/= mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

 

------=_NextPart_000_05B7_01CF2782.2BB94E70-- From juberti@google.com Tue Feb 11 22:13:43 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481591A07E0 for ; Tue, 11 Feb 2014 22:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 s26PC-IzzFjB for ; Tue, 11 Feb 2014 22:13:37 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2B99E1A0729 for ; Tue, 11 Feb 2014 22:13:36 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id pa12so6876687veb.19 for ; Tue, 11 Feb 2014 22:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aoSGSDK3v1yejkzqwsGXFvLp/1bkLhbUoDs/Q1VcjfM=; b=DMt4kTTUc6FrY/oDHr/xfm5DqvoERsjimlV/OzZNfUplaV/mG95I3L6J2BsN+E9Qyb 6O0gleuozvEqndHlsIKqOnUZxMh7nh5tgzL/ekJlNMCs/xxMyvssDuc1lnxXRW3vCQ1S fIWklUr69C6XvfWF+0nU8AoWPplH05Q/CZLSzh0GZQRkXZ8tpfydAJPVD1i9/WfqGCaj jLXiF1hZFH/DjHYUisgk5kGu5rSNhFjYiLkOhrwbxMPucvq9HXO4XjjuCfZ5IdiXeonv 48735hA5lxPELRtuVO0LDIanUXR8jJGsXgc+fVd4QRjR6GCEIYEqfmHkCiv6sDc6QSoh SRJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aoSGSDK3v1yejkzqwsGXFvLp/1bkLhbUoDs/Q1VcjfM=; b=AafXbb/IRqWnz4bMjjE5HD8xRVnWD7MnXsXiHYIQEQDajdAnLlTMNvoOS55fy8Wd6k L/UM0bHmnBDqyULAEwrKIDujH1Syhz58XXpNJmzwNBrpBaxTgjnD9u1YqPdwvsIuueiI GS+TJzAUVZ3x8qU75APgkrzb28qNTo6pbLtfGbMTmf+7feJnl3bBOOYc053ghta2ieJU xFx5Fs0HS4Bl9xUuAawoF5Qy31x3TE5JEjXkhEUoNpooi8f8zWdUE3SA25duVJKg+YGH ciy3saAAAqN0MwvO4S9nhDYDOvxxiXj+BXLTRYP9H6indfIWPTkl5oHC1t961HJb1tUU FXFw== X-Gm-Message-State: ALoCoQmvSV4vJPGCdd4klNEqgCD0afl4w6GPRiUS5KgEP7uQGFr1IAn9VJbRuLkRKsgnR120caBZ91GkxfpzexSYKRhe8pkPekkJI7NYU4CilUHeEEgOX2i7OW9nv2Ks+K0EKXgZAmnNTH2cx3DZ7RE/Zv/RDOSmEc+z5HUTNyWyPX5ahgsjBgF8BI6LdkQm3H1dqK/aDRFY X-Received: by 10.59.6.7 with SMTP id cq7mr32430723ved.14.1392185616049; Tue, 11 Feb 2014 22:13:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Tue, 11 Feb 2014 22:13:14 -0800 (PST) In-Reply-To: <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> From: Justin Uberti Date: Tue, 11 Feb 2014 22:13:14 -0800 Message-ID: To: Karl Stahl Content-Type: multipart/alternative; boundary=047d7bf0ef301b40fa04f22f79dd Cc: tireddy@icisco.com, Marc Blanchet , "tram@ietf.org" , Dan Wing , Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 06:13:43 -0000 --047d7bf0ef301b40fa04f22f79dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Inline. On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl wrote: > Listening to this thread, I am afraid we are missing the very point and > necessity for this milestone! > > - There are severe NAT traversal and quality issues that should and can b= e > dealt with by a good auto-discovery mechanism and the right usage by the > turn client (the WebRTC browser) > > > > There are ways, not only: Enterprises or ISPs wishing to provide their > own TURN server, in an attempt to reduce so-called "triangle routing",nee= d > a new auto-discovery mechanism > > But also: - NSPs (Network Service Providers) want to provide a path where > the bandwidth of WebRTC is better coped with. > > - NSPs or Enterprises want to offer an Internet access quality pipe for > prioritized RTC (Real Time Communication) traffic. > > - Enterprises having restrictive firewalls, want to provide a UDP-path fo= r > WebRTC and possibly also for better quality where RTC do not compete with > data traffic. > > Also considering > > - Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4= G > OTT channels, all should be able to automatically offer their own optimal > TURN server > > > > This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80= =9D etc! It is not a > mistake, but the very need for this milestone! > Again, it has not been demonstrated why TURN is the right technology here, compared to a more transparent flow identification tool like MALICE. We don't force all HTTP requests to locate a HTTP proxy via anycast, I don't see why we need to do the same for WebRTC. > > > What are the hesitations raised here? > > > TURN primarily to identify WebRTC flows, as opposed to using it as a NA= T > traversal tool. This makes me concerned that we may be using the wrong > technology to solve the problem > > It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall > traversal problem associated with real-time communication (SIP at that > time). However, its largest flaw/problem is that quality things were not > (could not be?) considered. The method=E2=80=99s very idea (like all simi= lar > methods for getting RTC through ordinary NAT/Firewalls) is to fool the > media through a NAT/Firewall that is unaware of what is happening. Thus, > this is root of quality issues (and bandwidth allocation optimization) th= at > needs to be dealt with: Real-time traffic fighting with a data traffic > crowded congestion point. > I think that "fooling" is an incorrect description. The NAT is supposed to be transparent to the client. > > > But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate > request for a suitable pipe for quality demanding real time traffic. J > > ICE is a pre-protocol you use because you want a path for real-time media > between parties. Here: The browser says knock knock, I want to get media > through (and of course with as good quality as required and possible). > > > > If the NAT/Firewall owner and network owner are allowed to see these > requests, they can help/assist in achieving the good media path. If they > are not aware, they cannot help! > > > Hope this made it understandable on an overview level how this can become= =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D > > It is also the ONLY way I can see to achieve what we want to achieve and > should be the aim and requirement of this milestone. > > > > I am talking about general usage of WebRTC over Internet/mobile OTT (not > feeding WebRTC into application specific networks like IMS where other > methods may exist). > > > > This is good, not evil! > > > > If the hesitations are raised because of a belief/hope/wish that there ar= e > no or will not be severe quality issues =E2=80=9Cbecause it is all about > bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D et= c., I strongly object! > That is wrong and will be very detrimental for WebRTC usage. We already s= ee > it and I can give numerous examples of how much less quality demanding Vo= IP > is/is not handled quality wise and that it matters. And, what would be ba= d > considering quality issues and allowing/encouraging methods to deal with > them? > > > If the hesitations are raised, because of suspicion that the methods we > may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to > protect income from carrier telephony traffic), I could understand and > would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At > least forward thinking carrier=E2=80=99s realize that already. Web RTC wi= ll happen. > Which customers want to pay for an access with blocked WebRTC? The > carrier=E2=80=99s offering/assuring good WebRTC will rather get the custo= mers and > income J. (Maybe the Web browser can detect and encourage this=E2=80=A6) > > > If there are technical concerns of bad result, or better methods allowing > network providers and LAN managers to offer and inform the browser that > there are good media paths to be used, and that the web browser > automatically can chose those, then let us all understand those, so we ca= n > achieve what should be achieved by this milestone. > Skype, Hangouts, Facetime are doing billions of minutes per week and the Internet has not melted yet. If we need to do flow identification to allow traffic to be prioritized, fine (see above regarding my preferred approach), but forcing all WebRTC traffic through a MITM (TURN server) is a much bigger jump that I don't yet see the justification for. In short: TURN is a technology that is supposed to fade away with the move to IPv6. I don't think we want to make it a critical element of WebRTC. > > > /Karl > > > > > > *Fr=C3=A5n:* Dan Wing [mailto:dwing@cisco.com] > *Skickat:* den 11 februari 2014 18:25 > *Till:* Marc Blanchet > *Kopia:* Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; > Simon Perreault > > *=C3=84mne:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism= for > enterprise and ISPs > > > > > > On Feb 11, 2014, at 9:08 AM, Marc Blanchet > wrote: > > > > Le 2014-02-11 =C3=A0 00:39, Dan Wing a =C3=A9crit : > > > > > On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: > > > > Good to see there is a lot of interest for this milestone. But based on > the description here, it seems like we want to use TURN primarily to > identify WebRTC flows, as opposed to using it as a NAT traversal tool. Th= is > makes me concerned that we may be using the wrong technology to solve the > problem. > > > > +1. > > > > I would prefer allowing flows to establish themselves using their 'best' > path, and the best path is seldom through a TURN server. When we imagine > IPv6 in our future, we don't want to force an application-level proxy > (TURN) server on the path solely for traversing an IPv6 firewall. > > > > > > It seems this thread is conflating all the possible reasons / > justifications for TURN: > > * mobility > > * NAT traversal (both endpoints are behind endpoint-dependent mapping > NATs) > > * firewall traversal (firewall blocks UDP) > > * enhancing privacy > > > > Unfortunately the TURN server nor the endpoint really know which of those > use-cases is desired (by the user or by the IT network administrator) or > necessary (for the call to work at all). > > > > Dan, while I agree in principle, I doubt that a user could ever say "I > want mobility or I want NAT traversal". I think the user only want the ca= ll > to succeed, whatever the properties of its network point of attachment ar= e. > > > > So what can we do? Should the TURN server provide any and all services > the TURN client might possibly want, as that is what a robust TURN server > will do, and the endpoint should prefer TURN candidates over all others > because there might be some functionality / usefulness of TURN that the > user might gain through TURN (e.g., enhanced privacy)? > > > > -d > > > > > > > > This seems problematic. Perhaps we need a way to signal the desired > use-case ("trait"), or as Justin suggests, using a different technology f= or > some of these use-cases. > > > > -d > > > > > > > > > > On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl > wrote: > > Simon, > > Good questions - see inline below --> . > Some more thought is required! > > /Karl > > -----Ursprungligt meddelande----- > Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault > Skickat: den 10 februari 2014 15:16 > Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com > =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism f= or > enterprise and ISPs > > > Karl, > > It is great to see such enthusiasm! Thanks! > > I have a couple technical questions... > > Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > > - Note that to achieve some of the above points, TURN must be favored > > over STUN to enforce that the TURN-path actually is used. (The Anycast > > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) > > I understand the STUN vs TURN priority issue. But I don't see how anycast > affects it in any way. Can you please explain? > > --- Good point - I was a bit quick here (maybe too quick) > We have given this quite bit of thought, since even if a TURN server is > provided and discovered, CURRENT usage of ICE may suggest a candidate fro= m > the remote party that will make a connection without the need/usage of th= e > TURN server (that we wanted to be used for the good purposes listed). > > The only way we found around this, was to stop STUN through the IP defaul= t > gateway (like a restrictive Enterprise firewall does inhibiting ICE > connectivity, which others are concerned about...). Since the provisionin= g > of auto-discovery using the anycast mechanism, would be adding a route in= a > default gateway, adding a firewall rule to eat STUN packets would assure > that the provisioned TURN server actually becomes used (and not bypassed > "by accident"). (That was the thought behind the =E2=80=9Cautomatically= =E2=80=9D within > quotes.) > > BUT, since you brought up the question, assuming that we have the power t= o > enforce WebRTC usage of ICE, I believe a MUST requirement to use an > auto-discovered TURN server instead of STUN, would solve the same problem= . > However, thinking further (in relation to your next question - "anyone > could set up a badly-maintained" - enforcing such ICE usage may not be > good.) > > > > > - 3^rd The Anycast method below =E2=80=93 I see no problem > > > > It also has the advantage of encouraging (but not requiring) the > > STUN/TURN to be built in the default gateway or NAT/firewall/access > > router itself, with a second interface to a public IP address on the > > WAN side. (Current volume deployed, low cost NSP triple play modems > > usually have a quality assured level 2 or level 3 WAN pipe for just > > voice (and another for IPTV) =E2=80=93 The anycast discovered TURN-serv= er can > > be the access gateway to such quality pipe for WebRTC media, in a > > single NSP provided CPE, scaling from residential and up.) > > Suppose we define well-known anycast TURN server addresses. How would thi= s > not be subject to the same service quality issues that plagued 6to4? That > is, anyone could set up a badly-maintained, under-provisioned TURN server > and announce it over BGP to the world, as it was done for > 6to4 relays. Or just bad BGP outbound filter configuration. And how can w= e > prevent triangle routing? There is nothing guaranteeing that the anycast > server you see is being provided to you by your ISP, rather than a server > sitting on the other side of the planet. > > --- Good point - needs to be resolved. For this I don't have a ready > answer... > An auto-discovered TURN server must be trusted (whatever method it is > discovered by). We are trusting the one providing us with an IP address a= nd > default gateway anyway. It would be easy if we could reuse that trust, > instead of another mechanisms. > > Is there a good way for the browser to check that the anycast address is > not handled beyond the network service provider's default gateway? Ideas? > > > > > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > --047d7bf0ef301b40fa04f22f79dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Inline.

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intert= ex.se> wrote:

Listening to this thread, I am afraid we are missing the very po= int and necessity for this milestone!

- There are severe NAT traversal and quality issues that should = and can be dealt with by a good auto-discovery mechanism and the right usag= e by the turn client (the WebRTC browser)

=C2=A0

There are ways, not only: Enterprises= or ISPs wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery mechanism<= /span>

But also: - NSPs (Netwo= rk Service Providers) want to provide a path where the bandwidth of WebRTC = is better coped with.

- NSPs or Enterprises wan= t to offer an Internet access quality pipe for prioritized RTC (Real Time C= ommunication) traffic.

- Enterprises having restrictive firewall= s, want to provide a UDP-path for WebRTC and possibly also for better quali= ty where RTC do not compete with data traffic.

Also considering

- Mobility; It is c= ommon to move from a LAN to accessing via WiFi or 3G/4G OTT channels, all s= hould be able to automatically offer their own optimal TURN server

=C2=A0

This leads us into =C2=A0=E2=80=9CT= URN=E2=80=A6to identify WebRTC flows=E2=80=9D et= c! It is not a mistake, but the very need for this milestone!=


Again, it has not been demonst= rated why TURN is the right technology here, compared to a more transparent= flow identification tool like MALICE. We don't force all HTTP requests= to locate a HTTP proxy via anycast, I don't see why we need to do the = same for WebRTC.=C2=A0

=C2=A0

What are the hesitations raised here?<= /u>

> TURN pr= imarily to identify WebRTC flows, as opposed to using it as a NAT traversal= tool. This makes me concerned that we may be using the wrong technology to= solve the problem

It is correct that ICE/STUN/TURN wa= s designed to address the NAT/Firewall traversal problem associated with re= al-time communication (SIP at that time). However, its largest flaw/problem= is that quality things were not (could not be?) considered. The method=E2= =80=99s very idea (like all similar methods for getting RTC through ordinar= y NAT/Firewalls) is to fool the media through a NAT/Firewall that is unawar= e of what is happening. Thus, this is root of quality issues (and bandwidth= allocation optimization) that needs to be dealt with: Real-time traffic fi= ghting with a data traffic crowded congestion point.


I think that "fooling&quo= t; is an incorrect description. The NAT is supposed to be transparent to th= e client.

<= /u>=C2=A0

But, a BLESSING of ICE/STUN/TURN is that = it can be seen as a legitimate request for a suitable pipe for quality dema= nding real time traffic. J

ICE is a pre-protocol you use because you= want a path for real-time media between parties. Here: The browser says kn= ock knock, I want to get media through (and of course with as good quality = as required and possible).

=C2=A0

If the NAT/Firewall owner and network owner are a= llowed to see these requests, they can help/assist in achieving the good me= dia path. If they are not aware, they cannot help!

=C2=A0

Hope this made it understandable on an ov= erview level how this can become =E2=80=9CTURN=E2=80=A6to identif= y WebRTC flows=E2=80=9D

It is also the ONLY way I can see to achi= eve what we want to achieve and should be the aim and requirement of this m= ilestone.

=C2=A0

I am talking about general usage of WebRTC over I= nternet/mobile OTT (not feeding WebRTC into application specific networks l= ike IMS where other methods may exist).

=C2=A0

This is good, not evil!

=C2=A0

If the hesitations are raised because of a belief= /hope/wish that there are no or will not be severe quality issues =E2=80=9C= because it is all about bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself= with time=E2=80=9D etc., I strongly object! That is wrong and will be very= detrimental for WebRTC usage. We already see it and I can give numerous ex= amples of how much less quality demanding VoIP is/is not handled quality wi= se and that it matters. And, what would be bad considering quality issues a= nd allowing/encouraging methods to deal with them?

=C2=A0

If the hesitations are raised, because of= suspicion that the methods we may recommend may be misused to stop/block/d= estroy WebRTC usage (e.g. to protect income from carrier telephony traffic)= , I could understand and would fight the same battle. But hopefully, those = days are (soon) over =E2=80=93 At least forward thinking carrier=E2=80=99s = realize that already. Web RTC will happen. Which customers want to pay for = an access with blocked WebRTC? The carrier=E2=80=99s offering/assuring good= WebRTC will rather get the customers and income J. (Maybe the Web browser can detect and encourage this=E2=80=A6)= =C2=A0

=C2=A0

If there are technical concerns of bad re= sult, or better methods allowing network providers and LAN managers to offe= r and inform the browser that there are good media paths to be used, and th= at the web browser automatically can chose those, then let us all understan= d those, so we can achieve what should be achieved by this milestone.


Skype, Hangouts, Facetime are = doing billions of minutes per week and the Internet has not melted yet. If = we need to do flow identification to allow traffic to be prioritized, fine = (see above regarding my preferred approach), but forcing all WebRTC traffic= through a MITM (TURN server) is a much bigger jump that I don't yet se= e the justification for.

In short: TURN is a technology that is supposed to fade= away with the move to IPv6. I don't think we want to make it a critica= l element of WebRTC.

= =C2=A0

/Karl

=C2=A0

=C2=A0

Fr=C3=A5n: Dan Wing [mailto:dwing@cisco.com]
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kop= ia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon Perreault


=C3=84mne: Re: [tram] Milestone 3: TURN s= erver auto-discovery mechanism for enterprise and ISPs
<= /div>

=C2=A0

=C2=A0

On Feb 11, 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> w= rote:



Le 2014-02-11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit :=




On Feb 10, 2014, at 5:30= PM, Justin Uberti <juberti@google.com> wrote:



Good to s= ee there is a lot of interest for this milestone. But based on the descript= ion here, it seems like we want to use TURN primarily to identify WebRTC fl= ows, as opposed to using it as a NAT traversal tool. This makes me concerne= d that we may be using the wrong technology to solve the problem.=

=C2=A0

= +1.

=C2=A0

= I would prefer allowing flows to establish themselves using their 'best= ' path, and the best path is seldom through a TURN server. =C2=A0When w= e imagine IPv6 in our future, we don't want to force an application-lev= el proxy (TURN) server on the path solely for traversing an IPv6 firewall.<= u>

=C2=A0

= =C2=A0

It seems this thread is conflating all the possible r= easons / justifications for TURN:

=C2=A0 * mob= ility

=C2=A0 * NAT traversal = (both endpoints are behind endpoint-dependent mapping NATs)

=C2=A0 *=C2=A0firewall traversal (firewall blocks UDP= )

=C2=A0 * enhancing privacy<= u>

=C2=A0

= Unfortunately the TURN server nor the endpoint really know which of those u= se-cases is desired (by the user or by the IT network administrator) or nec= essary (for the call to work at all).

=C2=A0

=

Dan, while I agree in principle, I doubt that a user= could ever say "I want mobility or I want NAT traversal". I thin= k the user only want the call to succeed, whatever the properties of its ne= twork point of attachment are.

=C2=A0

So what can we do? =C2=A0Should the TURN serve= r provide any and all services the TURN client might possibly want, as that= is what a robust TURN server will do, and the endpoint should prefer TURN = candidates over all others because there might be some functionality / usef= ulness of TURN that the user might gain through TURN (e.g., enhanced privac= y)?

=C2=A0

-d

<= /u>=C2=A0

=C2=A0<= /p>



=C2=A0This seems problematic. =C2=A0Perhaps we need a way to signal th= e desired use-case ("trait"), or as Justin suggests, using a diff= erent technology for some of these use-cases.

=C2=A0

= -d

=C2=A0

= =C2=A0



=C2=A0

On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl=C2=A0<karl.sta= hl@intertex.se>=C2=A0wrote:

Simon,

Good questions - see inline below --> .
Some= more thought is required!

/Karl

-----Ursprungligt meddelande= -----
Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault
Skickat: den= 10 februari 2014 15:16
Till: Karl Stahl;=C2=A0tram@ietf.org;=C2=A0tireddy@icisco.com=
=C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for= enterprise and ISPs


Karl,

It is great to see such enthusiasm! Thanks!

I have a co= uple technical questions...

Le 2014-02-08 08:11, Karl Stahl a =C3=A9= crit :
> - Note that to achieve some of the above points, TURN must b= e favored
> over STUN to enforce that the TURN-path actually is used. (The Anycast=
> method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.= )

I understand the STUN vs TURN priority issue. But I don't see = how anycast affects it in any way. Can you please explain?

--- Good point - I was a bit quick here (maybe too quick)<= br>We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate from = the remote party that will make a connection without the need/usage of the = TURN server (that we wanted to be used for the good purposes listed).

The only way we found around this, was to stop STUN through the IP defa= ult gateway (like a restrictive Enterprise firewall does inhibiting ICE con= nectivity, which others are concerned about...). Since the provisioning of = auto-discovery using the anycast mechanism, would be adding a route in a de= fault gateway, adding a firewall rule to eat STUN packets would assure that= the provisioned TURN server actually becomes used (and not bypassed "= by accident"). (That was the thought behind the =E2=80=9Cautomatically= =E2=80=9D within quotes.)

BUT, since you brought up the question, assuming that we have the power= to enforce WebRTC usage of ICE, I believe a MUST requirement to use an aut= o-discovered TURN server instead of STUN, would solve the same problem. How= ever, thinking further (in relation to your next question - "anyone co= uld set up a badly-maintained" - enforcing such ICE usage may not be g= ood.)



> - 3^rd The Anycas= t method below =E2=80=93 I see no problem
>
> It also has the a= dvantage of encouraging (but not requiring) the
> STUN/TURN to be built in the default gateway or NAT/firewall/access> router itself, with a second interface to a public IP address on the<= br>> WAN side. (Current volume deployed, low cost NSP triple play modems=
> usually have a quality assured level 2 or level 3 WAN pipe for just> voice (and another for IPTV) =E2=80=93 The anycast discovered TURN-se= rver can
> be the access gateway to such quality pipe for WebRTC medi= a, in a
> single NSP provided CPE, scaling from residential and up.)

Supp= ose we define well-known anycast TURN server addresses. How would this not = be subject to the same service quality issues that plagued 6to4? That is, a= nyone could set up a badly-maintained, under-provisioned TURN server and an= nounce it over BGP to the world, as it was done for
6to4 relays. Or just bad BGP outbound filter configuration. And how can we = prevent triangle routing? There is nothing guaranteeing that the anycast se= rver you see is being provided to you by your ISP, rather than a server sit= ting on the other side of the planet.

--- Good point - needs to be resolved. For this I don'= t have a ready answer...
An auto-discovered TURN server must be trusted = (whatever method it is discovered by). We are trusting the one providing us= with an IP address and default gateway anyway. It would be easy if we coul= d reuse that trust, instead of another mechanisms.

Is there a good way for the browser to check that the anycast address i= s not handled beyond the network service provider's default gateway? Id= eas?




Thanks,
Simon
--
DTN made easy, lean, and smart -->=C2=A0http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 = =C2=A0 =C2=A0 =C2=A0-->=C2=A0http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -->=C2=A0http= ://numb.viagenie.ca
_______________________________________________<= br>tram mailing list
= tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________= ________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

=

=C2=A0

_______________________________________________
tram ma= iling list
tram@ietf.= org
ht= tps://www.ietf.org/mailman/listinfo/tram

=


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

=C2=A0

= =C2=A0


<= /div> --047d7bf0ef301b40fa04f22f79dd-- From tireddy@cisco.com Tue Feb 11 23:01:24 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EF91A0849 for ; Tue, 11 Feb 2014 23:01:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ZBcNSbJe0fw7 for ; Tue, 11 Feb 2014 23:01:21 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id CD6EE1A0830 for ; Tue, 11 Feb 2014 23:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12456; q=dns/txt; s=iport; t=1392188480; x=1393398080; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=yx0B2BQ54yCqnKMzkGdk4Ag4Z0nAZjnw/BmuIkia9RA=; b=G0fcagUtKy/DM/gTdFhOlE2IAkFecM9oaxStf7YnHp7dyJtMoSqAoMvr wOrDREfWqY7iWqAuIT6SdePMpLGt4p6aejv6dHey3ccbuUt/sr1M/Xgx7 S8SBNENnWe7L8KcPm/XEG4sFAYIkkZqGtjSmp+X8qufVBKcfmyeWu0O4e 0=; X-IronPort-AV: E=Sophos;i="4.95,831,1384300800"; d="scan'208";a="19782252" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-1.cisco.com with ESMTP; 12 Feb 2014 07:01:20 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1C71JKD017525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 07:01:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 01:01:19 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Karl Stahl , "'Simon Perreault'" , "tram@ietf.org" , "tireddy@icisco.com" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPJrZnSgUY4V56JE+wy6rTjZeHIZqvVbIwgAEJXKCAANCLcA== Date: Wed, 12 Feb 2014 07:01:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242AC8C2@xmb-rcd-x10.cisco.com> References: <082c01cf17d4$393d7bb0$abb87310$@stahl@intertex.se> <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se> <52F8DF21.2080303@viagenie.ca> <049801cf26b6$5a87db30$0f979190$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A242ABA2D@xmb-rcd-x10.cisco.com> <058f01cf275d$da1dc6a0$8e5953e0$@stahl@intertex.se> In-Reply-To: <058f01cf275d$da1dc6a0$8e5953e0$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.230] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 07:01:24 -0000 SGkgS2FybCwNCg0KWWVzLCB0aGVyZSBpcyBhIHByb2JsZW0gYnV0IFAyUCBXZWJSVEMgc3RyZWFt cyAoYm90aCBtZWRpYSBhbmQgZGF0YSBjaGFubmVscykgY2FuIGJlIGlkZW50aWZpZWQgYW5kIFFv UyBjYW4gYmUgcHJvdmlkZWQgYnkgdGhlIGFjY2VzcyBuZXR3b3JrIHdpdGhvdXQgZm9yY2luZyBU VVJOIHRvIGJlIHVzZWQuIFlvdSBtYXkgd2FudCB0byBsb29rIGludG8gUENQIEZMT1dEQVRBICho dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW5nLXBjcC1mbG93ZGF0YS0wMCksIE1B TElDRSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFydGluc2VuLW1tdXNpYy1t YWxpY2UtMDApLiANCg0KLVRpcnUuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogS2FybCBTdGFobCBbbWFpbHRvOmthcmwuc3RhaGxAaW50ZXJ0ZXguc2VdDQo+IFNlbnQ6 IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQgMTI6NDcgQU0NCj4gVG86IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSk7ICdTaW1vbiBQZXJyZWF1bHQnOyB0cmFtQGlldGYub3JnOw0KPiB0 aXJlZGR5QGljaXNjby5jb20NCj4gU3ViamVjdDogU1Y6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVS TiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvcg0KPiBlbnRlcnByaXNlIGFuZCBJ U1BzDQo+IA0KPiBUaXJlZGR5IHdyb3RlIGJlbG93ID4gVGhlcmUgYXJlIHZhcmlvdXMgd2F5cyB0 byBwcmlvcml0aXplIFdlYlJUQyBtZWRpYQ0KPiBzdHJlYW1zIGFuZCBJIGRvbid0IHNlZSBhIG5l ZWQgdG8gYmxvY2sgUDJQIGNvbm5lY3Rpdml0eS4NCj4gDQo+IC0tLSBXZSBuZWVkIG5vdCBvbmx5 IHRvIHRoaW5rIGFib3V0IHByaW9yaXRpemluZyBXZWJSVEMsIGl0IGlzIGFib3V0ICJ0cmFmZmlj DQo+IHNoYXBpbmcgYWxzbyIuDQo+IC0gSWYgd2UgY29uc2lkZXIgdGhlIGNhc2Ugb2YgV2ViUlRD IHRyYWZmaWMgb3ZlciBJbnRlcm5ldC9tb2JpbGUgT1RUIChub3QNCj4gdGFsa2luZyBhYm91dCBm ZWVkaW5nIFdlYlJUQyBpbnRvIHNvbWUgYXBwbGljYXRpb24gc3BlY2lmaWMgbmV0d29yayBsaWtl DQo+IElNUyB3aGVyZSB0aGV5IG1heSBiZSBvdGhlciBxdWFsaXR5IG1lYXN1cmVzKSwgd2UgZ2V0 IGxvc3QgcXVhbGl0eSB3aXNlDQo+IGFscmVhZHkgd2hlbiAoaWYpIHdlIGFsbG93IHByaW9yaXRp emVkIFdlYlJUQyB0cmFmZmljIHRvIGdvIGludG8gYSBjb25nZXN0aW9uDQo+IHBvaW50IChsaWtl IGEgTkFUL2ZpcmV3YWxsIG9yIGRlZmF1bHQgZ2F0ZXdheSwgd2hlcmUgdGhlcmUgbWF5IGJlIGhl YXZ5IGRhdGENCj4gdHJhZmZpYyBhbHJlYWR5IGZpbGxpbmcgdGhlIHBpcGUuDQo+IC0gUXVhbGl0 eSBsb3NzIGhlcmUgKGxvc3QgV2ViUlRDIG1lZGlhIHBhY2tldHMpIGNhbm5vdCBiZSByZWNvdmVy ZWQgbGF0ZXINCj4gLSBUaGF0IGlzIHRoZSAibmVlZCB0byBibG9jayBQMlAgY29ubmVjdGl2aXR5 IiAod2hpY2ggbWF5IHNvdW5kIHVnbHkgYnV0IGlzDQo+IHJlYWxseSBhYm91dCBhc3N1cmluZyB0 aGF0IHdlIENBTiBnZXQgUDJQIGNvbm5lY3Rpdml0eSB3aXRoIGJlc3QgcXVhbGl0eSwgd2l0aA0K PiBoZWxwIG9mIHNlcnZpY2UgcHJvdmlkZXJzIGFuZCBMQU4gYWRtaW5pc3RyYXRvcnMgdGhhdCB3 YW50IFdlYlJUQyB0cmFmZmljIHRvDQo+IGJlIGdvb2QgYW5kIGFjY2Vzc2libGUuLi4pDQo+IA0K PiAtLS0gT3IgZG8gc2VlIGFub3RoZXIvYmV0dGVyIHdheSBhcm91bmQgdGhpcyB0aGF0IEkgY2Fu bm90IHNlZT8NCj4gDQo+IC0tLS0tVXJzcHJ1bmdsaWd0IG1lZGRlbGFuZGUtLS0tLQ0KPiBGcsOl bjogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSBbbWFpbHRvOnRpcmVkZHlAY2lzY28uY29t XQ0KPiBTa2lja2F0OiBkZW4gMTEgZmVicnVhcmkgMjAxNCAwMzo0MA0KPiBUaWxsOiBLYXJsIFN0 YWhsOyAnU2ltb24gUGVycmVhdWx0JzsgdHJhbUBpZXRmLm9yZzsgdGlyZWRkeUBpY2lzY28uY29t DQo+IMOEbW5lOiBSRTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2Nv dmVyeSBtZWNoYW5pc20gZm9yDQo+IGVudGVycHJpc2UgYW5kIElTUHMNCj4gDQo+ID4gVGhlIG9u bHkgd2F5IHdlIGZvdW5kIGFyb3VuZCB0aGlzLCB3YXMgdG8gc3RvcCBTVFVOIHRocm91Z2ggdGhl IElQDQo+ID4gZGVmYXVsdCBnYXRld2F5IChsaWtlIGEgcmVzdHJpY3RpdmUgRW50ZXJwcmlzZSBm aXJld2FsbCBkb2VzDQo+ID4gaW5oaWJpdGluZyBJQ0UgY29ubmVjdGl2aXR5LCB3aGljaCBvdGhl cnMgYXJlIGNvbmNlcm5lZCBhYm91dC4uLikuDQo+ID4gU2luY2UgdGhlIHByb3Zpc2lvbmluZyBv ZiBhdXRvLSBkaXNjb3ZlcnkgdXNpbmcgdGhlIGFueWNhc3QgbWVjaGFuaXNtLA0KPiA+IHdvdWxk IGJlIGFkZGluZyBhIHJvdXRlIGluIGEgZGVmYXVsdCBnYXRld2F5LCBhZGRpbmcgYSBmaXJld2Fs bCBydWxlDQo+ID4gdG8gZWF0IFNUVU4gcGFja2V0cyB3b3VsZCBhc3N1cmUgdGhhdCB0aGUgcHJv dmlzaW9uZWQgVFVSTiBzZXJ2ZXINCj4gPiBhY3R1YWxseSBiZWNvbWVzIHVzZWQgKGFuZCBub3Qg YnlwYXNzZWQgImJ5IGFjY2lkZW50IikuIChUaGF0IHdhcyB0aGUNCj4gPiB0aG91Z2h0IGJlaGlu ZCB0aGUg4oCcYXV0b21hdGljYWxseeKAnSB3aXRoaW4gcXVvdGVzLikNCj4gDQo+IFRoZXJlIGFy ZSB2YXJpb3VzIHdheXMgdG8gcHJpb3JpdGl6ZSBXZWJSVEMgbWVkaWEgc3RyZWFtcyBhbmQgSSBk b24ndCBzZWUgYQ0KPiBuZWVkIHRvIGJsb2NrIFAyUCBjb25uZWN0aXZpdHkuDQo+IC0tLSBXZSBu ZWVkIG5vdCBvbmx5IHRvIHRoaW5rIGFib3V0IHByaW9yaXRpemluZyBXZWJSVEMsIGl0IGlzIGFi b3V0ICJ0cmFmZmljDQo+IHNoYXBpbmcgYWxzbyIuDQo+IC0gSWYgd2UgY29uc2lkZXIgdGhlIGNh c2Ugb2YgV2ViUlRDIHRyYWZmaWMgb3ZlciBJbnRlcm5ldC9tb2JpbGUgT1RUIChub3QNCj4gdGFs a2luZyBhYm91dCBmZWVkaW5nIFdlYlJUQyBpbnRvIHNvbWUgYXBwbGljYXRpb24gc3BlY2lmaWMg bmV0d29yayBsaWtlDQo+IElNUyB3aGVyZSB0aGV5IG1heSBiZSBvdGhlciBxdWFsaXR5IG1lYXN1 cmVzKSwgd2UgZ2V0IGxvc3QgcXVhbGl0eSB3aXNlDQo+IGFscmVhZHkgd2hlbiAoaWYpIHdlIGFs bG93IHByaW9yaXRpemVkIFdlYlJUQyB0cmFmZmljIHRvIGdvIGludG8gYSBjb25nZXN0aW9uDQo+ IHBvaW50IChsaWtlIGEgTkFUL2ZpcmV3YWxsIG9yIGRlZmF1bHQgZ2F0ZXdheSwgd2hlcmUgdGhl cmUgbWF5IGJlIGhlYXZ5IGRhdGENCj4gdHJhZmZpYyBhbHJlYWR5IGZpbGxpbmcgdGhlIHBpcGUu DQo+IC0gUXVhbGl0eSBsb3NzIGhlcmUgKGxvc3QgV2ViUlRDIG1lZGlhIHBhY2tldHMpIGNhbm5v dCBiZSByZWNvdmVyZWQgbGF0ZXINCj4gLSBUaGF0IGlzIHRoZSAibmVlZCB0byBibG9jayBQMlAg Y29ubmVjdGl2aXR5IiAod2hpY2ggbWF5IHNvdW5kIHVnbHkgYnV0IGlzDQo+IHJlYWxseSBhYm91 dCBhc3N1cmluZyB0aGF0IHdlIENBTiBnZXQgUDJQIGNvbm5lY3Rpdml0eSB3aXRoIGJlc3QgcXVh bGl0eSwgd2l0aA0KPiBoZWxwIG9mIHNlcnZpY2UgcHJvdmlkZXJzIGFuZCBMQU4gYWRtaW5pc3Ry YXRvcnMgdGhhdCB3YW50IFdlYlJUQyB0cmFmZmljIHRvDQo+IGJlIGdvb2QgYW5kIGFjY2Vzc2li bGUuLi4pDQo+IA0KPiAtLS0gT3IgZG8gc2VlIGFub3RoZXIvYmV0dGVyIHdheSBhcm91bmQgdGhp cyB0aGF0IEkgY2Fubm90IHNlZT8NCj4gDQo+ICBVc2luZyBUVVJOIHNlcnZlciBpdHNlbGYgZW5k cG9pbnQgY2FuIGxlYXJuIHNlcnZlci1yZWZsZXhpdmUgY2FuZGlkYXRlcy4gSWYNCj4gdGhlcmUg aXMgYSByZXN0cmljdGl2ZSBmaXJld2FsbCB0aGF0IGJsb2NrcyBQMlAgY29ubmVjdGl2aXR5IHRo ZW4gcmVsYXllZA0KPiBjYW5kaWRhdGUgd291bGQgZXZlbnR1YWxseSBiZSBub21pbmF0ZWQgYmVj YXVzZSBJQ0UgY29ubmVjdGl2aXR5IGNoZWNrDQo+IGZhaWxzIHdpdGggb3RoZXIgY2FuZGlkYXRl IHR5cGVzLg0KPiANCj4gSSBkb24ndCBzZWUgYW55IG5lZWQgdG8gYWR2ZXJ0aXNlIG9ubHkgcmVs YXllZCBjYW5kaWRhdGVzIGluIHRoZSBvZmZlci9hbnN3ZXINCj4gb3RoZXIgdGhhbiBmb3IgcHJp dmFjeSByZWFzb25zLg0KPiANCj4gLVRpcnUuDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEthcmwgU3RhaGwNCj4gPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxMSwgMjAx NCA0OjQ4IEFNDQo+ID4gVG86ICdTaW1vbiBQZXJyZWF1bHQnOyB0cmFtQGlldGYub3JnOyB0aXJl ZGR5QGljaXNjby5jb20NCj4gPiBTdWJqZWN0OiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJO IHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20NCj4gPiBmb3IgZW50ZXJwcmlzZSBhbmQg SVNQcw0KPiA+DQo+ID4gU2ltb24sDQo+ID4NCj4gPiBHb29kIHF1ZXN0aW9ucyAtIHNlZSBpbmxp bmUgYmVsb3cgLS0+IC4NCj4gPiBTb21lIG1vcmUgdGhvdWdodCBpcyByZXF1aXJlZCENCj4gPg0K PiA+IC9LYXJsDQo+ID4NCj4gPiAtLS0tLVVyc3BydW5nbGlndCBtZWRkZWxhbmRlLS0tLS0NCj4g PiBGcsOlbjogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gRsO2ciBTaW1vbiBQ ZXJyZWF1bHQNCj4gPiBTa2lja2F0OiBkZW4gMTAgZmVicnVhcmkgMjAxNCAxNToxNg0KPiA+IFRp bGw6IEthcmwgU3RhaGw7IHRyYW1AaWV0Zi5vcmc7IHRpcmVkZHlAaWNpc2NvLmNvbQ0KPiA+IMOE bW5lOiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBt ZWNoYW5pc20gZm9yDQo+ID4gZW50ZXJwcmlzZSBhbmQgSVNQcw0KPiA+DQo+ID4gS2FybCwNCj4g Pg0KPiA+IEl0IGlzIGdyZWF0IHRvIHNlZSBzdWNoIGVudGh1c2lhc20hIFRoYW5rcyENCj4gPg0K PiA+IEkgaGF2ZSBhIGNvdXBsZSB0ZWNobmljYWwgcXVlc3Rpb25zLi4uDQo+ID4NCj4gPiBMZSAy MDE0LTAyLTA4IDA4OjExLCBLYXJsIFN0YWhsIGEgw6ljcml0IDoNCj4gPiA+IC0gTm90ZSB0aGF0 IHRvIGFjaGlldmUgc29tZSBvZiB0aGUgYWJvdmUgcG9pbnRzLCBUVVJOIG11c3QgYmUNCj4gPiA+ IGZhdm9yZWQgb3ZlciBTVFVOIHRvIGVuZm9yY2UgdGhhdCB0aGUgVFVSTi1wYXRoIGFjdHVhbGx5 IGlzIHVzZWQuDQo+ID4gPiAoVGhlIEFueWNhc3QgbWV0aG9kIHN1Z2dlc3RlZCBiZWxvdywg4oCc YXV0b21hdGljYWxseeKAnSBkb2VzIHRoaXMuKQ0KPiA+DQo+ID4gSSB1bmRlcnN0YW5kIHRoZSBT VFVOIHZzIFRVUk4gcHJpb3JpdHkgaXNzdWUuIEJ1dCBJIGRvbid0IHNlZSBob3cNCj4gPiBhbnlj YXN0IGFmZmVjdHMgaXQgaW4gYW55IHdheS4gQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbj8NCj4gPg0K PiA+IC0tLSBHb29kIHBvaW50IC0gSSB3YXMgYSBiaXQgcXVpY2sgaGVyZSAobWF5YmUgdG9vIHF1 aWNrKSBXZSBoYXZlDQo+ID4gZ2l2ZW4gdGhpcyBxdWl0ZSBiaXQgb2YgdGhvdWdodCwgc2luY2Ug ZXZlbiBpZiBhIFRVUk4gc2VydmVyIGlzDQo+ID4gcHJvdmlkZWQgYW5kIGRpc2NvdmVyZWQsIENV UlJFTlQgdXNhZ2Ugb2YgSUNFIG1heSBzdWdnZXN0IGEgY2FuZGlkYXRlDQo+ID4gZnJvbSB0aGUg cmVtb3RlIHBhcnR5IHRoYXQgd2lsbCBtYWtlIGEgY29ubmVjdGlvbiB3aXRob3V0IHRoZQ0KPiA+ IG5lZWQvdXNhZ2Ugb2YgdGhlIFRVUk4gc2VydmVyICh0aGF0IHdlIHdhbnRlZCB0byBiZSB1c2Vk IGZvciB0aGUgZ29vZA0KPiBwdXJwb3NlcyBsaXN0ZWQpLg0KPiA+DQo+ID4gVGhlIG9ubHkgd2F5 IHdlIGZvdW5kIGFyb3VuZCB0aGlzLCB3YXMgdG8gc3RvcCBTVFVOIHRocm91Z2ggdGhlIElQDQo+ ID4gZGVmYXVsdCBnYXRld2F5IChsaWtlIGEgcmVzdHJpY3RpdmUgRW50ZXJwcmlzZSBmaXJld2Fs bCBkb2VzDQo+ID4gaW5oaWJpdGluZyBJQ0UgY29ubmVjdGl2aXR5LCB3aGljaCBvdGhlcnMgYXJl IGNvbmNlcm5lZCBhYm91dC4uLikuDQo+ID4gU2luY2UgdGhlIHByb3Zpc2lvbmluZyBvZiBhdXRv LSBkaXNjb3ZlcnkgdXNpbmcgdGhlIGFueWNhc3QgbWVjaGFuaXNtLA0KPiA+IHdvdWxkIGJlIGFk ZGluZyBhIHJvdXRlIGluIGEgZGVmYXVsdCBnYXRld2F5LCBhZGRpbmcgYSBmaXJld2FsbCBydWxl DQo+ID4gdG8gZWF0IFNUVU4gcGFja2V0cyB3b3VsZCBhc3N1cmUgdGhhdCB0aGUgcHJvdmlzaW9u ZWQgVFVSTiBzZXJ2ZXINCj4gPiBhY3R1YWxseSBiZWNvbWVzIHVzZWQgKGFuZCBub3QgYnlwYXNz ZWQgImJ5IGFjY2lkZW50IikuIChUaGF0IHdhcyB0aGUNCj4gPiB0aG91Z2h0IGJlaGluZCB0aGUg 4oCcYXV0b21hdGljYWxseeKAnSB3aXRoaW4gcXVvdGVzLikNCj4gPg0KPiA+IEJVVCwgc2luY2Ug eW91IGJyb3VnaHQgdXAgdGhlIHF1ZXN0aW9uLCBhc3N1bWluZyB0aGF0IHdlIGhhdmUgdGhlDQo+ ID4gcG93ZXIgdG8gZW5mb3JjZSBXZWJSVEMgdXNhZ2Ugb2YgSUNFLCBJIGJlbGlldmUgYSBNVVNU IHJlcXVpcmVtZW50IHRvDQo+ID4gdXNlIGFuIGF1dG8tIGRpc2NvdmVyZWQgVFVSTiBzZXJ2ZXIg aW5zdGVhZCBvZiBTVFVOLCB3b3VsZCBzb2x2ZSB0aGUNCj4gc2FtZSBwcm9ibGVtLg0KPiA+IEhv d2V2ZXIsIHRoaW5raW5nIGZ1cnRoZXIgKGluIHJlbGF0aW9uIHRvIHlvdXIgbmV4dCBxdWVzdGlv biAtICJhbnlvbmUNCj4gPiBjb3VsZCBzZXQgdXAgYSBiYWRseS1tYWludGFpbmVkIiAtIGVuZm9y Y2luZyBzdWNoIElDRSB1c2FnZSBtYXkgbm90IGJlDQo+ID4gZ29vZC4pDQo+ID4NCj4gPg0KPiA+ ID4gLSAzXnJkIFRoZSBBbnljYXN0IG1ldGhvZCBiZWxvdyDigJMgSSBzZWUgbm8gcHJvYmxlbQ0K PiA+ID4NCj4gPiA+IEl0IGFsc28gaGFzIHRoZSBhZHZhbnRhZ2Ugb2YgZW5jb3VyYWdpbmcgKGJ1 dCBub3QgcmVxdWlyaW5nKSB0aGUNCj4gPiA+IFNUVU4vVFVSTiB0byBiZSBidWlsdCBpbiB0aGUg ZGVmYXVsdCBnYXRld2F5IG9yIE5BVC9maXJld2FsbC9hY2Nlc3MNCj4gPiA+IHJvdXRlciBpdHNl bGYsIHdpdGggYSBzZWNvbmQgaW50ZXJmYWNlIHRvIGEgcHVibGljIElQIGFkZHJlc3Mgb24gdGhl DQo+ID4gPiBXQU4gc2lkZS4gKEN1cnJlbnQgdm9sdW1lIGRlcGxveWVkLCBsb3cgY29zdCBOU1Ag dHJpcGxlIHBsYXkgbW9kZW1zDQo+ID4gPiB1c3VhbGx5IGhhdmUgYSBxdWFsaXR5IGFzc3VyZWQg bGV2ZWwgMiBvciBsZXZlbCAzIFdBTiBwaXBlIGZvciBqdXN0DQo+ID4gPiB2b2ljZSAoYW5kIGFu b3RoZXIgZm9yIElQVFYpIOKAkyBUaGUgYW55Y2FzdCBkaXNjb3ZlcmVkIFRVUk4tc2VydmVyDQo+ ID4gPiBjYW4gYmUgdGhlIGFjY2VzcyBnYXRld2F5IHRvIHN1Y2ggcXVhbGl0eSBwaXBlIGZvciBX ZWJSVEMgbWVkaWEsIGluDQo+ID4gPiBhIHNpbmdsZSBOU1AgcHJvdmlkZWQgQ1BFLCBzY2FsaW5n IGZyb20gcmVzaWRlbnRpYWwgYW5kIHVwLikNCj4gPg0KPiA+IFN1cHBvc2Ugd2UgZGVmaW5lIHdl bGwta25vd24gYW55Y2FzdCBUVVJOIHNlcnZlciBhZGRyZXNzZXMuIEhvdyB3b3VsZA0KPiA+IHRo aXMgbm90IGJlIHN1YmplY3QgdG8gdGhlIHNhbWUgc2VydmljZSBxdWFsaXR5IGlzc3VlcyB0aGF0 IHBsYWd1ZWQNCj4gPiA2dG80PyBUaGF0IGlzLCBhbnlvbmUgY291bGQgc2V0IHVwIGEgYmFkbHkt bWFpbnRhaW5lZCwNCj4gPiB1bmRlci1wcm92aXNpb25lZCBUVVJOIHNlcnZlciBhbmQgYW5ub3Vu Y2UgaXQgb3ZlciBCR1AgdG8gdGhlIHdvcmxkLA0KPiA+IGFzIGl0IHdhcyBkb25lIGZvcg0KPiA+ IDZ0bzQgcmVsYXlzLiBPciBqdXN0IGJhZCBCR1Agb3V0Ym91bmQgZmlsdGVyIGNvbmZpZ3VyYXRp b24uIEFuZCBob3cNCj4gPiBjYW4gd2UgcHJldmVudCB0cmlhbmdsZSByb3V0aW5nPyBUaGVyZSBp cyBub3RoaW5nIGd1YXJhbnRlZWluZyB0aGF0DQo+ID4gdGhlIGFueWNhc3Qgc2VydmVyIHlvdSBz ZWUgaXMgYmVpbmcgcHJvdmlkZWQgdG8geW91IGJ5IHlvdXIgSVNQLA0KPiA+IHJhdGhlciB0aGFu IGEgc2VydmVyIHNpdHRpbmcgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIHBsYW5ldC4NCj4gPg0K PiA+IC0tLSBHb29kIHBvaW50IC0gbmVlZHMgdG8gYmUgcmVzb2x2ZWQuIEZvciB0aGlzIEkgZG9u J3QgaGF2ZSBhIHJlYWR5DQo+IGFuc3dlci4uLg0KPiA+IEFuIGF1dG8tZGlzY292ZXJlZCBUVVJO IHNlcnZlciBtdXN0IGJlIHRydXN0ZWQgKHdoYXRldmVyIG1ldGhvZCBpdCBpcw0KPiA+IGRpc2Nv dmVyZWQgYnkpLiBXZSBhcmUgdHJ1c3RpbmcgdGhlIG9uZSBwcm92aWRpbmcgdXMgd2l0aCBhbiBJ UA0KPiA+IGFkZHJlc3MgYW5kIGRlZmF1bHQgZ2F0ZXdheSBhbnl3YXkuIEl0IHdvdWxkIGJlIGVh c3kgaWYgd2UgY291bGQgcmV1c2UNCj4gPiB0aGF0IHRydXN0LCBpbnN0ZWFkIG9mIGFub3RoZXIg bWVjaGFuaXNtcy4NCj4gPg0KPiA+IElzIHRoZXJlIGEgZ29vZCB3YXkgZm9yIHRoZSBicm93c2Vy IHRvIGNoZWNrIHRoYXQgdGhlIGFueWNhc3QgYWRkcmVzcw0KPiA+IGlzIG5vdCBoYW5kbGVkIGJl eW9uZCB0aGUgbmV0d29yayBzZXJ2aWNlIHByb3ZpZGVyJ3MgZGVmYXVsdCBnYXRld2F5Pw0KPiBJ ZGVhcz8NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gU2ltb24NCj4gPiAtLQ0KPiA+ IERUTiBtYWRlIGVhc3ksIGxlYW4sIGFuZCBzbWFydCAtLT4gaHR0cDovL3Bvc3RlbGxhdGlvbi52 aWFnZW5pZS5jYQ0KPiA+IE5BVDY0L0ROUzY0IG9wZW4tc291cmNlICAgICAgICAtLT4gaHR0cDov L2VjZHlzaXMudmlhZ2VuaWUuY2ENCj4gPiBTVFVOL1RVUk4gc2VydmVyICAgICAgICAgICAgICAg LS0+IGh0dHA6Ly9udW1iLnZpYWdlbmllLmNhDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiB0cmFtIG1haWxpbmcgbGlzdA0KPiA+IHRyYW1A aWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0N Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gPiB0cmFtQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg== From mperumal@cisco.com Tue Feb 11 23:32:12 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C09F61A086D for ; Tue, 11 Feb 2014 23:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 E6N4ziibfLDF for ; Tue, 11 Feb 2014 23:32:08 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2061A086C for ; Tue, 11 Feb 2014 23:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=73390; q=dns/txt; s=iport; t=1392190327; x=1393399927; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=njMMeswO9BZI29SvtkAQJtUHMBzQeKXQlb4t9HsgobY=; b=UVuB+EBMZ6MzmqRpSSHZ4pTlstOEAYX4esoIOT9QXw6ZRlx0p7FH8jC+ 24ZHGzYh0/yqTV/7gpyZGAxJ9YelLbdOnGmK6fNnVyqBXxOAr4dusElry f1saKHD3LrTHc0TgoeRSXRnGthmZk6GQRTqaQ6PDLbrGGoM7L+iPhAkbg 8=; X-IronPort-AV: E=Sophos;i="4.95,831,1384300800"; d="scan'208,217";a="19789379" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 12 Feb 2014 07:32:06 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1C7W6uv021932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 07:32:06 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.56]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 01:32:06 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Justin Uberti , Karl Stahl Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPJ7mlnafoQENNEUmFuRpz1h1atZqxMH2A Date: Wed, 12 Feb 2014 07:32:05 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.13] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DA8E0xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "tireddy@icisco.com" , Marc Blanchet , "tram@ietf.org" , "Dan Wing \(dwing\)" , Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 07:32:13 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DA8E0xmbrcdx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRm9yY2luZyBhbGwgdHJhZmZpYyB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgYW5kIGV4cGVj dGluZyBpdCB3b3VsZCBwcm92aWRlIHRoZSBiZXN0IHVzZXIgZXhwZXJpZW5jZSBkb2Vzbid0IGxv b2sgdGhlIHJpZ2h0IGFwcHJvYWNoLiBJbnN0ZWFkLCBpZiBhIHBhdGggdGhyb3VnaCBhIFRVUk4g c2VydmVyIGV4aXN0cyBhbmQgZG9lcyBwcm92aWRlIGxvd2VyIFJUVCwgaml0dGVyIGV0YywgYmVp bmcgYWJsZSB0byBkZXRlY3QgYW5kIHVzZSAob3Igc3dpdGNoIHRvKSB0aGF0IHBhdGggbWlnaHQg YmUgZGVzaXJhYmxlLi4NCg0KTXV0aHUNCg0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IFdlZG5lc2RheSwg RmVicnVhcnkgMTIsIDIwMTQgMTE6NDMgQU0NClRvOiBLYXJsIFN0YWhsDQpDYzogdGlyZWRkeUBp Y2lzY28uY29tOyBNYXJjIEJsYW5jaGV0OyB0cmFtQGlldGYub3JnOyBEYW4gV2luZyAoZHdpbmcp OyBTaW1vbiBQZXJyZWF1bHQNClN1YmplY3Q6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4g c2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0K DQpJbmxpbmUuDQoNCk9uIFR1ZSwgRmViIDExLCAyMDE0IGF0IDI6MzcgUE0sIEthcmwgU3RhaGwg PGthcmwuc3RhaGxAaW50ZXJ0ZXguc2U8bWFpbHRvOmthcmwuc3RhaGxAaW50ZXJ0ZXguc2U+PiB3 cm90ZToNCkxpc3RlbmluZyB0byB0aGlzIHRocmVhZCwgSSBhbSBhZnJhaWQgd2UgYXJlIG1pc3Np bmcgdGhlIHZlcnkgcG9pbnQgYW5kIG5lY2Vzc2l0eSBmb3IgdGhpcyBtaWxlc3RvbmUhDQotIFRo ZXJlIGFyZSBzZXZlcmUgTkFUIHRyYXZlcnNhbCBhbmQgcXVhbGl0eSBpc3N1ZXMgdGhhdCBzaG91 bGQgYW5kIGNhbiBiZSBkZWFsdCB3aXRoIGJ5IGEgZ29vZCBhdXRvLWRpc2NvdmVyeSBtZWNoYW5p c20gYW5kIHRoZSByaWdodCB1c2FnZSBieSB0aGUgdHVybiBjbGllbnQgKHRoZSBXZWJSVEMgYnJv d3NlcikNCg0KVGhlcmUgYXJlIHdheXMsIG5vdCBvbmx5OiBFbnRlcnByaXNlcyBvciBJU1BzIHdp c2hpbmcgdG8gcHJvdmlkZSB0aGVpciBvd24gVFVSTiBzZXJ2ZXIsIGluIGFuIGF0dGVtcHQgdG8g cmVkdWNlIHNvLWNhbGxlZCAidHJpYW5nbGUgcm91dGluZyIsbmVlZCBhIG5ldyBhdXRvLWRpc2Nv dmVyeSBtZWNoYW5pc20NCkJ1dCBhbHNvOiAtIE5TUHMgKE5ldHdvcmsgU2VydmljZSBQcm92aWRl cnMpIHdhbnQgdG8gcHJvdmlkZSBhIHBhdGggd2hlcmUgdGhlIGJhbmR3aWR0aCBvZiBXZWJSVEMg aXMgYmV0dGVyIGNvcGVkIHdpdGguDQotIE5TUHMgb3IgRW50ZXJwcmlzZXMgd2FudCB0byBvZmZl ciBhbiBJbnRlcm5ldCBhY2Nlc3MgcXVhbGl0eSBwaXBlIGZvciBwcmlvcml0aXplZCBSVEMgKFJl YWwgVGltZSBDb21tdW5pY2F0aW9uKSB0cmFmZmljLg0KLSBFbnRlcnByaXNlcyBoYXZpbmcgcmVz dHJpY3RpdmUgZmlyZXdhbGxzLCB3YW50IHRvIHByb3ZpZGUgYSBVRFAtcGF0aCBmb3IgV2ViUlRD IGFuZCBwb3NzaWJseSBhbHNvIGZvciBiZXR0ZXIgcXVhbGl0eSB3aGVyZSBSVEMgZG8gbm90IGNv bXBldGUgd2l0aCBkYXRhIHRyYWZmaWMuDQpBbHNvIGNvbnNpZGVyaW5nDQotIE1vYmlsaXR5OyBJ dCBpcyBjb21tb24gdG8gbW92ZSBmcm9tIGEgTEFOIHRvIGFjY2Vzc2luZyB2aWEgV2lGaSBvciAz Ry80RyBPVFQgY2hhbm5lbHMsIGFsbCBzaG91bGQgYmUgYWJsZSB0byBhdXRvbWF0aWNhbGx5IG9m ZmVyIHRoZWlyIG93biBvcHRpbWFsIFRVUk4gc2VydmVyDQoNClRoaXMgbGVhZHMgdXMgaW50byAg 4oCcVFVSTuKApnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnSBldGMhIEl0IGlzIG5vdCBhIG1p c3Rha2UsIGJ1dCB0aGUgdmVyeSBuZWVkIGZvciB0aGlzIG1pbGVzdG9uZSENCg0KQWdhaW4sIGl0 IGhhcyBub3QgYmVlbiBkZW1vbnN0cmF0ZWQgd2h5IFRVUk4gaXMgdGhlIHJpZ2h0IHRlY2hub2xv Z3kgaGVyZSwgY29tcGFyZWQgdG8gYSBtb3JlIHRyYW5zcGFyZW50IGZsb3cgaWRlbnRpZmljYXRp b24gdG9vbCBsaWtlIE1BTElDRS4gV2UgZG9uJ3QgZm9yY2UgYWxsIEhUVFAgcmVxdWVzdHMgdG8g bG9jYXRlIGEgSFRUUCBwcm94eSB2aWEgYW55Y2FzdCwgSSBkb24ndCBzZWUgd2h5IHdlIG5lZWQg dG8gZG8gdGhlIHNhbWUgZm9yIFdlYlJUQy4NCg0KV2hhdCBhcmUgdGhlIGhlc2l0YXRpb25zIHJh aXNlZCBoZXJlPw0KPiBUVVJOIHByaW1hcmlseSB0byBpZGVudGlmeSBXZWJSVEMgZmxvd3MsIGFz IG9wcG9zZWQgdG8gdXNpbmcgaXQgYXMgYSBOQVQgdHJhdmVyc2FsIHRvb2wuIFRoaXMgbWFrZXMg bWUgY29uY2VybmVkIHRoYXQgd2UgbWF5IGJlIHVzaW5nIHRoZSB3cm9uZyB0ZWNobm9sb2d5IHRv IHNvbHZlIHRoZSBwcm9ibGVtDQpJdCBpcyBjb3JyZWN0IHRoYXQgSUNFL1NUVU4vVFVSTiB3YXMg ZGVzaWduZWQgdG8gYWRkcmVzcyB0aGUgTkFUL0ZpcmV3YWxsIHRyYXZlcnNhbCBwcm9ibGVtIGFz c29jaWF0ZWQgd2l0aCByZWFsLXRpbWUgY29tbXVuaWNhdGlvbiAoU0lQIGF0IHRoYXQgdGltZSku IEhvd2V2ZXIsIGl0cyBsYXJnZXN0IGZsYXcvcHJvYmxlbSBpcyB0aGF0IHF1YWxpdHkgdGhpbmdz IHdlcmUgbm90IChjb3VsZCBub3QgYmU/KSBjb25zaWRlcmVkLiBUaGUgbWV0aG9k4oCZcyB2ZXJ5 IGlkZWEgKGxpa2UgYWxsIHNpbWlsYXIgbWV0aG9kcyBmb3IgZ2V0dGluZyBSVEMgdGhyb3VnaCBv cmRpbmFyeSBOQVQvRmlyZXdhbGxzKSBpcyB0byBmb29sIHRoZSBtZWRpYSB0aHJvdWdoIGEgTkFU L0ZpcmV3YWxsIHRoYXQgaXMgdW5hd2FyZSBvZiB3aGF0IGlzIGhhcHBlbmluZy4gVGh1cywgdGhp cyBpcyByb290IG9mIHF1YWxpdHkgaXNzdWVzIChhbmQgYmFuZHdpZHRoIGFsbG9jYXRpb24gb3B0 aW1pemF0aW9uKSB0aGF0IG5lZWRzIHRvIGJlIGRlYWx0IHdpdGg6IFJlYWwtdGltZSB0cmFmZmlj IGZpZ2h0aW5nIHdpdGggYSBkYXRhIHRyYWZmaWMgY3Jvd2RlZCBjb25nZXN0aW9uIHBvaW50Lg0K DQpJIHRoaW5rIHRoYXQgImZvb2xpbmciIGlzIGFuIGluY29ycmVjdCBkZXNjcmlwdGlvbi4gVGhl IE5BVCBpcyBzdXBwb3NlZCB0byBiZSB0cmFuc3BhcmVudCB0byB0aGUgY2xpZW50Lg0KDQpCdXQs IGEgQkxFU1NJTkcgb2YgSUNFL1NUVU4vVFVSTiBpcyB0aGF0IGl0IGNhbiBiZSBzZWVuIGFzIGEg bGVnaXRpbWF0ZSByZXF1ZXN0IGZvciBhIHN1aXRhYmxlIHBpcGUgZm9yIHF1YWxpdHkgZGVtYW5k aW5nIHJlYWwgdGltZSB0cmFmZmljLiDimLoNCklDRSBpcyBhIHByZS1wcm90b2NvbCB5b3UgdXNl IGJlY2F1c2UgeW91IHdhbnQgYSBwYXRoIGZvciByZWFsLXRpbWUgbWVkaWEgYmV0d2VlbiBwYXJ0 aWVzLiBIZXJlOiBUaGUgYnJvd3NlciBzYXlzIGtub2NrIGtub2NrLCBJIHdhbnQgdG8gZ2V0IG1l ZGlhIHRocm91Z2ggKGFuZCBvZiBjb3Vyc2Ugd2l0aCBhcyBnb29kIHF1YWxpdHkgYXMgcmVxdWly ZWQgYW5kIHBvc3NpYmxlKS4NCg0KSWYgdGhlIE5BVC9GaXJld2FsbCBvd25lciBhbmQgbmV0d29y ayBvd25lciBhcmUgYWxsb3dlZCB0byBzZWUgdGhlc2UgcmVxdWVzdHMsIHRoZXkgY2FuIGhlbHAv YXNzaXN0IGluIGFjaGlldmluZyB0aGUgZ29vZCBtZWRpYSBwYXRoLiBJZiB0aGV5IGFyZSBub3Qg YXdhcmUsIHRoZXkgY2Fubm90IGhlbHAhDQoNCkhvcGUgdGhpcyBtYWRlIGl0IHVuZGVyc3RhbmRh YmxlIG9uIGFuIG92ZXJ2aWV3IGxldmVsIGhvdyB0aGlzIGNhbiBiZWNvbWUg4oCcVFVSTuKApnRv IGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnQ0KSXQgaXMgYWxzbyB0aGUgT05MWSB3YXkgSSBjYW4g c2VlIHRvIGFjaGlldmUgd2hhdCB3ZSB3YW50IHRvIGFjaGlldmUgYW5kIHNob3VsZCBiZSB0aGUg YWltIGFuZCByZXF1aXJlbWVudCBvZiB0aGlzIG1pbGVzdG9uZS4NCg0KSSBhbSB0YWxraW5nIGFi b3V0IGdlbmVyYWwgdXNhZ2Ugb2YgV2ViUlRDIG92ZXIgSW50ZXJuZXQvbW9iaWxlIE9UVCAobm90 IGZlZWRpbmcgV2ViUlRDIGludG8gYXBwbGljYXRpb24gc3BlY2lmaWMgbmV0d29ya3MgbGlrZSBJ TVMgd2hlcmUgb3RoZXIgbWV0aG9kcyBtYXkgZXhpc3QpLg0KDQpUaGlzIGlzIGdvb2QsIG5vdCBl dmlsIQ0KDQpJZiB0aGUgaGVzaXRhdGlvbnMgYXJlIHJhaXNlZCBiZWNhdXNlIG9mIGEgYmVsaWVm L2hvcGUvd2lzaCB0aGF0IHRoZXJlIGFyZSBubyBvciB3aWxsIG5vdCBiZSBzZXZlcmUgcXVhbGl0 eSBpc3N1ZXMg4oCcYmVjYXVzZSBpdCBpcyBhbGwgYWJvdXQgYmFuZHdpZHRo4oCdLCDigJxpdCB3 aWxsIHJlc29sdmUgaXRzZWxmIHdpdGggdGltZeKAnSBldGMuLCBJIHN0cm9uZ2x5IG9iamVjdCEg VGhhdCBpcyB3cm9uZyBhbmQgd2lsbCBiZSB2ZXJ5IGRldHJpbWVudGFsIGZvciBXZWJSVEMgdXNh Z2UuIFdlIGFscmVhZHkgc2VlIGl0IGFuZCBJIGNhbiBnaXZlIG51bWVyb3VzIGV4YW1wbGVzIG9m IGhvdyBtdWNoIGxlc3MgcXVhbGl0eSBkZW1hbmRpbmcgVm9JUCBpcy9pcyBub3QgaGFuZGxlZCBx dWFsaXR5IHdpc2UgYW5kIHRoYXQgaXQgbWF0dGVycy4gQW5kLCB3aGF0IHdvdWxkIGJlIGJhZCBj b25zaWRlcmluZyBxdWFsaXR5IGlzc3VlcyBhbmQgYWxsb3dpbmcvZW5jb3VyYWdpbmcgbWV0aG9k cyB0byBkZWFsIHdpdGggdGhlbT8NCg0KSWYgdGhlIGhlc2l0YXRpb25zIGFyZSByYWlzZWQsIGJl Y2F1c2Ugb2Ygc3VzcGljaW9uIHRoYXQgdGhlIG1ldGhvZHMgd2UgbWF5IHJlY29tbWVuZCBtYXkg YmUgbWlzdXNlZCB0byBzdG9wL2Jsb2NrL2Rlc3Ryb3kgV2ViUlRDIHVzYWdlIChlLmcuIHRvIHBy b3RlY3QgaW5jb21lIGZyb20gY2FycmllciB0ZWxlcGhvbnkgdHJhZmZpYyksIEkgY291bGQgdW5k ZXJzdGFuZCBhbmQgd291bGQgZmlnaHQgdGhlIHNhbWUgYmF0dGxlLiBCdXQgaG9wZWZ1bGx5LCB0 aG9zZSBkYXlzIGFyZSAoc29vbikgb3ZlciDigJMgQXQgbGVhc3QgZm9yd2FyZCB0aGlua2luZyBj YXJyaWVy4oCZcyByZWFsaXplIHRoYXQgYWxyZWFkeS4gV2ViIFJUQyB3aWxsIGhhcHBlbi4gV2hp Y2ggY3VzdG9tZXJzIHdhbnQgdG8gcGF5IGZvciBhbiBhY2Nlc3Mgd2l0aCBibG9ja2VkIFdlYlJU Qz8gVGhlIGNhcnJpZXLigJlzIG9mZmVyaW5nL2Fzc3VyaW5nIGdvb2QgV2ViUlRDIHdpbGwgcmF0 aGVyIGdldCB0aGUgY3VzdG9tZXJzIGFuZCBpbmNvbWUg4pi6LiAoTWF5YmUgdGhlIFdlYiBicm93 c2VyIGNhbiBkZXRlY3QgYW5kIGVuY291cmFnZSB0aGlz4oCmKQ0KDQpJZiB0aGVyZSBhcmUgdGVj aG5pY2FsIGNvbmNlcm5zIG9mIGJhZCByZXN1bHQsIG9yIGJldHRlciBtZXRob2RzIGFsbG93aW5n IG5ldHdvcmsgcHJvdmlkZXJzIGFuZCBMQU4gbWFuYWdlcnMgdG8gb2ZmZXIgYW5kIGluZm9ybSB0 aGUgYnJvd3NlciB0aGF0IHRoZXJlIGFyZSBnb29kIG1lZGlhIHBhdGhzIHRvIGJlIHVzZWQsIGFu ZCB0aGF0IHRoZSB3ZWIgYnJvd3NlciBhdXRvbWF0aWNhbGx5IGNhbiBjaG9zZSB0aG9zZSwgdGhl biBsZXQgdXMgYWxsIHVuZGVyc3RhbmQgdGhvc2UsIHNvIHdlIGNhbiBhY2hpZXZlIHdoYXQgc2hv dWxkIGJlIGFjaGlldmVkIGJ5IHRoaXMgbWlsZXN0b25lLg0KDQpTa3lwZSwgSGFuZ291dHMsIEZh Y2V0aW1lIGFyZSBkb2luZyBiaWxsaW9ucyBvZiBtaW51dGVzIHBlciB3ZWVrIGFuZCB0aGUgSW50 ZXJuZXQgaGFzIG5vdCBtZWx0ZWQgeWV0LiBJZiB3ZSBuZWVkIHRvIGRvIGZsb3cgaWRlbnRpZmlj YXRpb24gdG8gYWxsb3cgdHJhZmZpYyB0byBiZSBwcmlvcml0aXplZCwgZmluZSAoc2VlIGFib3Zl IHJlZ2FyZGluZyBteSBwcmVmZXJyZWQgYXBwcm9hY2gpLCBidXQgZm9yY2luZyBhbGwgV2ViUlRD IHRyYWZmaWMgdGhyb3VnaCBhIE1JVE0gKFRVUk4gc2VydmVyKSBpcyBhIG11Y2ggYmlnZ2VyIGp1 bXAgdGhhdCBJIGRvbid0IHlldCBzZWUgdGhlIGp1c3RpZmljYXRpb24gZm9yLg0KDQpJbiBzaG9y dDogVFVSTiBpcyBhIHRlY2hub2xvZ3kgdGhhdCBpcyBzdXBwb3NlZCB0byBmYWRlIGF3YXkgd2l0 aCB0aGUgbW92ZSB0byBJUHY2LiBJIGRvbid0IHRoaW5rIHdlIHdhbnQgdG8gbWFrZSBpdCBhIGNy aXRpY2FsIGVsZW1lbnQgb2YgV2ViUlRDLg0KDQovS2FybA0KDQoNCkZyw6VuOiBEYW4gV2luZyBb bWFpbHRvOmR3aW5nQGNpc2NvLmNvbTxtYWlsdG86ZHdpbmdAY2lzY28uY29tPl0NClNraWNrYXQ6 IGRlbiAxMSBmZWJydWFyaSAyMDE0IDE4OjI1DQpUaWxsOiBNYXJjIEJsYW5jaGV0DQpLb3BpYTog SnVzdGluIFViZXJ0aTsgdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGljaXNjby5j b20+OyBLYXJsIFN0YWhsOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPjsgU2lt b24gUGVycmVhdWx0DQoNCsOEbW5lOiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZl ciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KDQpP biBGZWIgMTEsIDIwMTQsIGF0IDk6MDggQU0sIE1hcmMgQmxhbmNoZXQgPG1hcmMuYmxhbmNoZXRA dmlhZ2VuaWUuY2E8bWFpbHRvOm1hcmMuYmxhbmNoZXRAdmlhZ2VuaWUuY2E+PiB3cm90ZToNCg0K TGUgMjAxNC0wMi0xMSDDoCAwMDozOSwgRGFuIFdpbmcgPGR3aW5nQGNpc2NvLmNvbTxtYWlsdG86 ZHdpbmdAY2lzY28uY29tPj4gYSDDqWNyaXQgOg0KDQoNCk9uIEZlYiAxMCwgMjAxNCwgYXQgNToz MCBQTSwgSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29tPG1haWx0bzpqdWJlcnRpQGdv b2dsZS5jb20+PiB3cm90ZToNCg0KR29vZCB0byBzZWUgdGhlcmUgaXMgYSBsb3Qgb2YgaW50ZXJl c3QgZm9yIHRoaXMgbWlsZXN0b25lLiBCdXQgYmFzZWQgb24gdGhlIGRlc2NyaXB0aW9uIGhlcmUs IGl0IHNlZW1zIGxpa2Ugd2Ugd2FudCB0byB1c2UgVFVSTiBwcmltYXJpbHkgdG8gaWRlbnRpZnkg V2ViUlRDIGZsb3dzLCBhcyBvcHBvc2VkIHRvIHVzaW5nIGl0IGFzIGEgTkFUIHRyYXZlcnNhbCB0 b29sLiBUaGlzIG1ha2VzIG1lIGNvbmNlcm5lZCB0aGF0IHdlIG1heSBiZSB1c2luZyB0aGUgd3Jv bmcgdGVjaG5vbG9neSB0byBzb2x2ZSB0aGUgcHJvYmxlbS4NCg0KKzEuDQoNCkkgd291bGQgcHJl ZmVyIGFsbG93aW5nIGZsb3dzIHRvIGVzdGFibGlzaCB0aGVtc2VsdmVzIHVzaW5nIHRoZWlyICdi ZXN0JyBwYXRoLCBhbmQgdGhlIGJlc3QgcGF0aCBpcyBzZWxkb20gdGhyb3VnaCBhIFRVUk4gc2Vy dmVyLiAgV2hlbiB3ZSBpbWFnaW5lIElQdjYgaW4gb3VyIGZ1dHVyZSwgd2UgZG9uJ3Qgd2FudCB0 byBmb3JjZSBhbiBhcHBsaWNhdGlvbi1sZXZlbCBwcm94eSAoVFVSTikgc2VydmVyIG9uIHRoZSBw YXRoIHNvbGVseSBmb3IgdHJhdmVyc2luZyBhbiBJUHY2IGZpcmV3YWxsLg0KDQoNCkl0IHNlZW1z IHRoaXMgdGhyZWFkIGlzIGNvbmZsYXRpbmcgYWxsIHRoZSBwb3NzaWJsZSByZWFzb25zIC8ganVz dGlmaWNhdGlvbnMgZm9yIFRVUk46DQogICogbW9iaWxpdHkNCiAgKiBOQVQgdHJhdmVyc2FsIChi b3RoIGVuZHBvaW50cyBhcmUgYmVoaW5kIGVuZHBvaW50LWRlcGVuZGVudCBtYXBwaW5nIE5BVHMp DQogICogZmlyZXdhbGwgdHJhdmVyc2FsIChmaXJld2FsbCBibG9ja3MgVURQKQ0KICAqIGVuaGFu Y2luZyBwcml2YWN5DQoNClVuZm9ydHVuYXRlbHkgdGhlIFRVUk4gc2VydmVyIG5vciB0aGUgZW5k cG9pbnQgcmVhbGx5IGtub3cgd2hpY2ggb2YgdGhvc2UgdXNlLWNhc2VzIGlzIGRlc2lyZWQgKGJ5 IHRoZSB1c2VyIG9yIGJ5IHRoZSBJVCBuZXR3b3JrIGFkbWluaXN0cmF0b3IpIG9yIG5lY2Vzc2Fy eSAoZm9yIHRoZSBjYWxsIHRvIHdvcmsgYXQgYWxsKS4NCg0KRGFuLCB3aGlsZSBJIGFncmVlIGlu IHByaW5jaXBsZSwgSSBkb3VidCB0aGF0IGEgdXNlciBjb3VsZCBldmVyIHNheSAiSSB3YW50IG1v YmlsaXR5IG9yIEkgd2FudCBOQVQgdHJhdmVyc2FsIi4gSSB0aGluayB0aGUgdXNlciBvbmx5IHdh bnQgdGhlIGNhbGwgdG8gc3VjY2VlZCwgd2hhdGV2ZXIgdGhlIHByb3BlcnRpZXMgb2YgaXRzIG5l dHdvcmsgcG9pbnQgb2YgYXR0YWNobWVudCBhcmUuDQoNClNvIHdoYXQgY2FuIHdlIGRvPyAgU2hv dWxkIHRoZSBUVVJOIHNlcnZlciBwcm92aWRlIGFueSBhbmQgYWxsIHNlcnZpY2VzIHRoZSBUVVJO IGNsaWVudCBtaWdodCBwb3NzaWJseSB3YW50LCBhcyB0aGF0IGlzIHdoYXQgYSByb2J1c3QgVFVS TiBzZXJ2ZXIgd2lsbCBkbywgYW5kIHRoZSBlbmRwb2ludCBzaG91bGQgcHJlZmVyIFRVUk4gY2Fu ZGlkYXRlcyBvdmVyIGFsbCBvdGhlcnMgYmVjYXVzZSB0aGVyZSBtaWdodCBiZSBzb21lIGZ1bmN0 aW9uYWxpdHkgLyB1c2VmdWxuZXNzIG9mIFRVUk4gdGhhdCB0aGUgdXNlciBtaWdodCBnYWluIHRo cm91Z2ggVFVSTiAoZS5nLiwgZW5oYW5jZWQgcHJpdmFjeSk/DQoNCi1kDQoNCg0KDQogVGhpcyBz ZWVtcyBwcm9ibGVtYXRpYy4gIFBlcmhhcHMgd2UgbmVlZCBhIHdheSB0byBzaWduYWwgdGhlIGRl c2lyZWQgdXNlLWNhc2UgKCJ0cmFpdCIpLCBvciBhcyBKdXN0aW4gc3VnZ2VzdHMsIHVzaW5nIGEg ZGlmZmVyZW50IHRlY2hub2xvZ3kgZm9yIHNvbWUgb2YgdGhlc2UgdXNlLWNhc2VzLg0KDQotZA0K DQoNCg0KDQpPbiBNb24sIEZlYiAxMCwgMjAxNCBhdCAzOjE4IFBNLCBLYXJsIFN0YWhsIDxrYXJs LnN0YWhsQGludGVydGV4LnNlPG1haWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlPj4gd3JvdGU6 DQpTaW1vbiwNCg0KR29vZCBxdWVzdGlvbnMgLSBzZWUgaW5saW5lIGJlbG93IC0tPiAuDQpTb21l IG1vcmUgdGhvdWdodCBpcyByZXF1aXJlZCENCg0KL0thcmwNCg0KLS0tLS1VcnNwcnVuZ2xpZ3Qg bWVkZGVsYW5kZS0tLS0tDQpGcsOlbjogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPl0gRsO2ciBTaW1vbiBQZXJyZWF1bHQNClNr aWNrYXQ6IGRlbiAxMCBmZWJydWFyaSAyMDE0IDE1OjE2DQpUaWxsOiBLYXJsIFN0YWhsOyB0cmFt QGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPjsgdGlyZWRkeUBpY2lzY28uY29tPG1haWx0 bzp0aXJlZGR5QGljaXNjby5jb20+DQrDhG1uZTogUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVS TiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1Bz DQoNCkthcmwsDQoNCkl0IGlzIGdyZWF0IHRvIHNlZSBzdWNoIGVudGh1c2lhc20hIFRoYW5rcyEN Cg0KSSBoYXZlIGEgY291cGxlIHRlY2huaWNhbCBxdWVzdGlvbnMuLi4NCg0KTGUgMjAxNC0wMi0w OCAwODoxMSwgS2FybCBTdGFobCBhIMOpY3JpdCA6DQo+IC0gTm90ZSB0aGF0IHRvIGFjaGlldmUg c29tZSBvZiB0aGUgYWJvdmUgcG9pbnRzLCBUVVJOIG11c3QgYmUgZmF2b3JlZA0KPiBvdmVyIFNU VU4gdG8gZW5mb3JjZSB0aGF0IHRoZSBUVVJOLXBhdGggYWN0dWFsbHkgaXMgdXNlZC4gKFRoZSBB bnljYXN0DQo+IG1ldGhvZCBzdWdnZXN0ZWQgYmVsb3csIOKAnGF1dG9tYXRpY2FsbHnigJ0gZG9l cyB0aGlzLikNCg0KSSB1bmRlcnN0YW5kIHRoZSBTVFVOIHZzIFRVUk4gcHJpb3JpdHkgaXNzdWUu IEJ1dCBJIGRvbid0IHNlZSBob3cgYW55Y2FzdCBhZmZlY3RzIGl0IGluIGFueSB3YXkuIENhbiB5 b3UgcGxlYXNlIGV4cGxhaW4/DQotLS0gR29vZCBwb2ludCAtIEkgd2FzIGEgYml0IHF1aWNrIGhl cmUgKG1heWJlIHRvbyBxdWljaykNCldlIGhhdmUgZ2l2ZW4gdGhpcyBxdWl0ZSBiaXQgb2YgdGhv dWdodCwgc2luY2UgZXZlbiBpZiBhIFRVUk4gc2VydmVyIGlzIHByb3ZpZGVkIGFuZCBkaXNjb3Zl cmVkLCBDVVJSRU5UIHVzYWdlIG9mIElDRSBtYXkgc3VnZ2VzdCBhIGNhbmRpZGF0ZSBmcm9tIHRo ZSByZW1vdGUgcGFydHkgdGhhdCB3aWxsIG1ha2UgYSBjb25uZWN0aW9uIHdpdGhvdXQgdGhlIG5l ZWQvdXNhZ2Ugb2YgdGhlIFRVUk4gc2VydmVyICh0aGF0IHdlIHdhbnRlZCB0byBiZSB1c2VkIGZv ciB0aGUgZ29vZCBwdXJwb3NlcyBsaXN0ZWQpLg0KDQpUaGUgb25seSB3YXkgd2UgZm91bmQgYXJv dW5kIHRoaXMsIHdhcyB0byBzdG9wIFNUVU4gdGhyb3VnaCB0aGUgSVAgZGVmYXVsdCBnYXRld2F5 IChsaWtlIGEgcmVzdHJpY3RpdmUgRW50ZXJwcmlzZSBmaXJld2FsbCBkb2VzIGluaGliaXRpbmcg SUNFIGNvbm5lY3Rpdml0eSwgd2hpY2ggb3RoZXJzIGFyZSBjb25jZXJuZWQgYWJvdXQuLi4pLiBT aW5jZSB0aGUgcHJvdmlzaW9uaW5nIG9mIGF1dG8tZGlzY292ZXJ5IHVzaW5nIHRoZSBhbnljYXN0 IG1lY2hhbmlzbSwgd291bGQgYmUgYWRkaW5nIGEgcm91dGUgaW4gYSBkZWZhdWx0IGdhdGV3YXks IGFkZGluZyBhIGZpcmV3YWxsIHJ1bGUgdG8gZWF0IFNUVU4gcGFja2V0cyB3b3VsZCBhc3N1cmUg dGhhdCB0aGUgcHJvdmlzaW9uZWQgVFVSTiBzZXJ2ZXIgYWN0dWFsbHkgYmVjb21lcyB1c2VkIChh bmQgbm90IGJ5cGFzc2VkICJieSBhY2NpZGVudCIpLiAoVGhhdCB3YXMgdGhlIHRob3VnaHQgYmVo aW5kIHRoZSDigJxhdXRvbWF0aWNhbGx54oCdIHdpdGhpbiBxdW90ZXMuKQ0KDQpCVVQsIHNpbmNl IHlvdSBicm91Z2h0IHVwIHRoZSBxdWVzdGlvbiwgYXNzdW1pbmcgdGhhdCB3ZSBoYXZlIHRoZSBw b3dlciB0byBlbmZvcmNlIFdlYlJUQyB1c2FnZSBvZiBJQ0UsIEkgYmVsaWV2ZSBhIE1VU1QgcmVx dWlyZW1lbnQgdG8gdXNlIGFuIGF1dG8tZGlzY292ZXJlZCBUVVJOIHNlcnZlciBpbnN0ZWFkIG9m IFNUVU4sIHdvdWxkIHNvbHZlIHRoZSBzYW1lIHByb2JsZW0uIEhvd2V2ZXIsIHRoaW5raW5nIGZ1 cnRoZXIgKGluIHJlbGF0aW9uIHRvIHlvdXIgbmV4dCBxdWVzdGlvbiAtICJhbnlvbmUgY291bGQg c2V0IHVwIGEgYmFkbHktbWFpbnRhaW5lZCIgLSBlbmZvcmNpbmcgc3VjaCBJQ0UgdXNhZ2UgbWF5 IG5vdCBiZSBnb29kLikNCg0KDQo+IC0gM15yZCBUaGUgQW55Y2FzdCBtZXRob2QgYmVsb3cg4oCT IEkgc2VlIG5vIHByb2JsZW0NCj4NCj4gSXQgYWxzbyBoYXMgdGhlIGFkdmFudGFnZSBvZiBlbmNv dXJhZ2luZyAoYnV0IG5vdCByZXF1aXJpbmcpIHRoZQ0KPiBTVFVOL1RVUk4gdG8gYmUgYnVpbHQg aW4gdGhlIGRlZmF1bHQgZ2F0ZXdheSBvciBOQVQvZmlyZXdhbGwvYWNjZXNzDQo+IHJvdXRlciBp dHNlbGYsIHdpdGggYSBzZWNvbmQgaW50ZXJmYWNlIHRvIGEgcHVibGljIElQIGFkZHJlc3Mgb24g dGhlDQo+IFdBTiBzaWRlLiAoQ3VycmVudCB2b2x1bWUgZGVwbG95ZWQsIGxvdyBjb3N0IE5TUCB0 cmlwbGUgcGxheSBtb2RlbXMNCj4gdXN1YWxseSBoYXZlIGEgcXVhbGl0eSBhc3N1cmVkIGxldmVs IDIgb3IgbGV2ZWwgMyBXQU4gcGlwZSBmb3IganVzdA0KPiB2b2ljZSAoYW5kIGFub3RoZXIgZm9y IElQVFYpIOKAkyBUaGUgYW55Y2FzdCBkaXNjb3ZlcmVkIFRVUk4tc2VydmVyIGNhbg0KPiBiZSB0 aGUgYWNjZXNzIGdhdGV3YXkgdG8gc3VjaCBxdWFsaXR5IHBpcGUgZm9yIFdlYlJUQyBtZWRpYSwg aW4gYQ0KPiBzaW5nbGUgTlNQIHByb3ZpZGVkIENQRSwgc2NhbGluZyBmcm9tIHJlc2lkZW50aWFs IGFuZCB1cC4pDQoNClN1cHBvc2Ugd2UgZGVmaW5lIHdlbGwta25vd24gYW55Y2FzdCBUVVJOIHNl cnZlciBhZGRyZXNzZXMuIEhvdyB3b3VsZCB0aGlzIG5vdCBiZSBzdWJqZWN0IHRvIHRoZSBzYW1l IHNlcnZpY2UgcXVhbGl0eSBpc3N1ZXMgdGhhdCBwbGFndWVkIDZ0bzQ/IFRoYXQgaXMsIGFueW9u ZSBjb3VsZCBzZXQgdXAgYSBiYWRseS1tYWludGFpbmVkLCB1bmRlci1wcm92aXNpb25lZCBUVVJO IHNlcnZlciBhbmQgYW5ub3VuY2UgaXQgb3ZlciBCR1AgdG8gdGhlIHdvcmxkLCBhcyBpdCB3YXMg ZG9uZSBmb3INCjZ0bzQgcmVsYXlzLiBPciBqdXN0IGJhZCBCR1Agb3V0Ym91bmQgZmlsdGVyIGNv bmZpZ3VyYXRpb24uIEFuZCBob3cgY2FuIHdlIHByZXZlbnQgdHJpYW5nbGUgcm91dGluZz8gVGhl cmUgaXMgbm90aGluZyBndWFyYW50ZWVpbmcgdGhhdCB0aGUgYW55Y2FzdCBzZXJ2ZXIgeW91IHNl ZSBpcyBiZWluZyBwcm92aWRlZCB0byB5b3UgYnkgeW91ciBJU1AsIHJhdGhlciB0aGFuIGEgc2Vy dmVyIHNpdHRpbmcgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIHBsYW5ldC4NCi0tLSBHb29kIHBv aW50IC0gbmVlZHMgdG8gYmUgcmVzb2x2ZWQuIEZvciB0aGlzIEkgZG9uJ3QgaGF2ZSBhIHJlYWR5 IGFuc3dlci4uLg0KQW4gYXV0by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVyIG11c3QgYmUgdHJ1c3Rl ZCAod2hhdGV2ZXIgbWV0aG9kIGl0IGlzIGRpc2NvdmVyZWQgYnkpLiBXZSBhcmUgdHJ1c3Rpbmcg dGhlIG9uZSBwcm92aWRpbmcgdXMgd2l0aCBhbiBJUCBhZGRyZXNzIGFuZCBkZWZhdWx0IGdhdGV3 YXkgYW55d2F5LiBJdCB3b3VsZCBiZSBlYXN5IGlmIHdlIGNvdWxkIHJldXNlIHRoYXQgdHJ1c3Qs IGluc3RlYWQgb2YgYW5vdGhlciBtZWNoYW5pc21zLg0KDQpJcyB0aGVyZSBhIGdvb2Qgd2F5IGZv ciB0aGUgYnJvd3NlciB0byBjaGVjayB0aGF0IHRoZSBhbnljYXN0IGFkZHJlc3MgaXMgbm90IGhh bmRsZWQgYmV5b25kIHRoZSBuZXR3b3JrIHNlcnZpY2UgcHJvdmlkZXIncyBkZWZhdWx0IGdhdGV3 YXk/IElkZWFzPw0KDQoNCg0KVGhhbmtzLA0KU2ltb24NCi0tDQpEVE4gbWFkZSBlYXN5LCBsZWFu LCBhbmQgc21hcnQgLS0+IGh0dHA6Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUuY2E8aHR0cDovL3Bv c3RlbGxhdGlvbi52aWFnZW5pZS5jYS8+DQpOQVQ2NC9ETlM2NCBvcGVuLXNvdXJjZSAgICAgICAg LS0+IGh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhPGh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNh Lz4NClNUVU4vVFVSTiBzZXJ2ZXIgICAgICAgICAgICAgICAtLT4gaHR0cDovL251bWIudmlhZ2Vu aWUuY2E8aHR0cDovL251bWIudmlhZ2VuaWUuY2EvPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3Jn PG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90cmFtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5nIGxp c3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1h aWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmFtDQoNCg0KDQo= --_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DA8E0xmbrcdx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Rm9yY2luZyBhbGwgdHJhZmZpYyB0aHJv dWdoIGEgVFVSTiBzZXJ2ZXIgYW5kIGV4cGVjdGluZyBpdCB3b3VsZCBwcm92aWRlIHRoZSBiZXN0 IHVzZXIgZXhwZXJpZW5jZSBkb2Vzbid0IGxvb2sgdGhlIHJpZ2h0IGFwcHJvYWNoLiBJbnN0ZWFk LCBpZiBhIHBhdGggdGhyb3VnaCBhIFRVUk4gc2VydmVyIGV4aXN0cw0KIGFuZCBkb2VzIHByb3Zp ZGUgbG93ZXIgUlRULCBqaXR0ZXIgZXRjLCBiZWluZyBhYmxlIHRvIGRldGVjdCBhbmQgdXNlIChv ciBzd2l0Y2ggdG8pIHRoYXQgcGF0aCBtaWdodCBiZSBkZXNpcmFibGUuLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TXV0aHU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDEyLCAyMDE0IDExOjQzIEFNPGJyPg0KPGI+VG86PC9iPiBLYXJsIFN0YWhsPGJyPg0KPGI+Q2M6 PC9iPiB0aXJlZGR5QGljaXNjby5jb207IE1hcmMgQmxhbmNoZXQ7IHRyYW1AaWV0Zi5vcmc7IERh biBXaW5nIChkd2luZyk7IFNpbW9uIFBlcnJlYXVsdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20g Zm9yIGVudGVycHJpc2UgYW5kIElTUHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFR1ZSwgRmViIDExLCAyMDE0IGF0IDI6MzcgUE0sIEthcmwgU3RhaGwgJmx0 OzxhIGhyZWY9Im1haWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlIiB0YXJnZXQ9Il9ibGFuayI+ a2FybC5zdGFobEBpbnRlcnRleC5zZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6Ymx1ZSI+TGlzdGVuaW5nIHRvIHRoaXMgdGhyZWFkLCBJIGFtIGFmcmFpZCB3ZSBh cmUgbWlzc2luZyB0aGUgdmVyeSBwb2ludCBhbmQgbmVjZXNzaXR5IGZvciB0aGlzIG1pbGVzdG9u ZSE8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIFRo ZXJlIGFyZSBzZXZlcmUgTkFUIHRyYXZlcnNhbCBhbmQgcXVhbGl0eSBpc3N1ZXMgdGhhdCBzaG91 bGQgYW5kIGNhbiBiZSBkZWFsdCB3aXRoIGJ5IGEgZ29vZCBhdXRvLWRpc2NvdmVyeQ0KIG1lY2hh bmlzbSBhbmQgdGhlIHJpZ2h0IHVzYWdlIGJ5IHRoZSB0dXJuIGNsaWVudCAodGhlIFdlYlJUQyBi cm93c2VyKTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi PlRoZXJlIGFyZSB3YXlzLCBub3Qgb25seToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RW50ZXJwcmlzZXMg b3IgSVNQcyB3aXNoaW5nIHRvIHByb3ZpZGUgdGhlaXIgb3duIFRVUk4gc2VydmVyLCBpbiBhbiBh dHRlbXB0IHRvIHJlZHVjZSBzby1jYWxsZWQgJnF1b3Q7dHJpYW5nbGUgcm91dGluZyZxdW90Oyxu ZWVkIGEgbmV3IGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkJ1dCBhbHNvOiAtIE5TUHMgKE5ldHdvcmsgU2Vy dmljZSBQcm92aWRlcnMpIHdhbnQgdG8gcHJvdmlkZSBhIHBhdGggd2hlcmUgdGhlIGJhbmR3aWR0 aCBvZiBXZWJSVEMgaXMgYmV0dGVyDQogY29wZWQgd2l0aC48L3NwYW4+PHNwYW4gbGFuZz0iU1Yi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LSBOU1BzIG9yIEVudGVycHJpc2Vz IHdhbnQgdG8gb2ZmZXIgYW4gSW50ZXJuZXQgYWNjZXNzIHF1YWxpdHkgcGlwZSBmb3IgcHJpb3Jp dGl6ZWQgUlRDIChSZWFsIFRpbWUgQ29tbXVuaWNhdGlvbikNCiB0cmFmZmljLiA8L3NwYW4+PHNw YW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIEVudGVycHJpc2VzIGhh dmluZyByZXN0cmljdGl2ZSBmaXJld2FsbHMsIHdhbnQgdG8gcHJvdmlkZSBhIFVEUC1wYXRoIGZv ciBXZWJSVEMgYW5kIHBvc3NpYmx5IGFsc28gZm9yDQogYmV0dGVyIHF1YWxpdHkgd2hlcmUgUlRD IGRvIG5vdCBjb21wZXRlIHdpdGggZGF0YSB0cmFmZmljLiA8L3NwYW4+PHNwYW4gbGFuZz0iU1Yi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkFsc28gY29uc2lkZXJpbmc8L3Nw YW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LSBN b2JpbGl0eTsgSXQgaXMgY29tbW9uIHRvIG1vdmUgZnJvbSBhIExBTiB0byBhY2Nlc3Npbmcgdmlh IFdpRmkgb3IgM0cvNEcgT1RUIGNoYW5uZWxzLCBhbGwgc2hvdWxkIGJlDQogYWJsZSB0byBhdXRv bWF0aWNhbGx5IG9mZmVyIHRoZWlyIG93biBvcHRpbWFsIFRVUk4gc2VydmVyPC9zcGFuPjxzcGFu IGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5UaGlzIGxlYWRz IHVzIGludG8NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDvigJxU VVJO4oCmdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dz4oCdDQo8c3BhbiBzdHlsZT0iY29sb3I6Ymx1 ZSI+ZXRjISBJdCBpcyBub3QgYSBtaXN0YWtlLCBidXQgdGhlIHZlcnkgbmVlZCBmb3IgdGhpcyBt aWxlc3RvbmUhPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFnYWlu LCBpdCBoYXMgbm90IGJlZW4gZGVtb25zdHJhdGVkIHdoeSBUVVJOIGlzIHRoZSByaWdodCB0ZWNo bm9sb2d5IGhlcmUsIGNvbXBhcmVkIHRvIGEgbW9yZSB0cmFuc3BhcmVudCBmbG93IGlkZW50aWZp Y2F0aW9uIHRvb2wgbGlrZSBNQUxJQ0UuIFdlIGRvbid0IGZvcmNlIGFsbCBIVFRQIHJlcXVlc3Rz IHRvIGxvY2F0ZSBhIEhUVFAgcHJveHkgdmlhIGFueWNhc3QsIEkgZG9uJ3Qgc2VlIHdoeSB3ZSBu ZWVkDQogdG8gZG8gdGhlIHNhbWUgZm9yIFdlYlJUQy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPldoYXQgYXJlIHRoZSBoZXNpdGF0 aW9ucyByYWlzZWQgaGVyZT88L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZndDsgVFVSTiBwcmltYXJpbHkgdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dzLCBh cyBvcHBvc2VkIHRvIHVzaW5nIGl0IGFzIGEgTkFUIHRyYXZlcnNhbCB0b29sLiBUaGlzIG1ha2Vz IG1lIGNvbmNlcm5lZA0KIHRoYXQgd2UgbWF5IGJlIHVzaW5nIHRoZSB3cm9uZyB0ZWNobm9sb2d5 IHRvIHNvbHZlIHRoZSBwcm9ibGVtPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JdCBpcyBjb3JyZWN0IHRoYXQgSUNFL1NUVU4vVFVSTiB3 YXMgZGVzaWduZWQgdG8gYWRkcmVzcyB0aGUgTkFUL0ZpcmV3YWxsIHRyYXZlcnNhbCBwcm9ibGVt IGFzc29jaWF0ZWQNCiB3aXRoIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIChTSVAgYXQgdGhhdCB0 aW1lKS4gSG93ZXZlciwgaXRzIGxhcmdlc3QgZmxhdy9wcm9ibGVtIGlzIHRoYXQgcXVhbGl0eSB0 aGluZ3Mgd2VyZSBub3QgKGNvdWxkIG5vdCBiZT8pIGNvbnNpZGVyZWQuIFRoZSBtZXRob2TigJlz IHZlcnkgaWRlYSAobGlrZSBhbGwgc2ltaWxhciBtZXRob2RzIGZvciBnZXR0aW5nIFJUQyB0aHJv dWdoIG9yZGluYXJ5IE5BVC9GaXJld2FsbHMpIGlzIHRvIGZvb2wgdGhlIG1lZGlhDQogdGhyb3Vn aCBhIE5BVC9GaXJld2FsbCB0aGF0IGlzIHVuYXdhcmUgb2Ygd2hhdCBpcyBoYXBwZW5pbmcuIFRo dXMsIHRoaXMgaXMgcm9vdCBvZiBxdWFsaXR5IGlzc3VlcyAoYW5kIGJhbmR3aWR0aCBhbGxvY2F0 aW9uIG9wdGltaXphdGlvbikgdGhhdCBuZWVkcyB0byBiZSBkZWFsdCB3aXRoOiBSZWFsLXRpbWUg dHJhZmZpYyBmaWdodGluZyB3aXRoIGEgZGF0YSB0cmFmZmljIGNyb3dkZWQgY29uZ2VzdGlvbiBw b2ludC48L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHRoaW5rIHRoYXQgJnF1b3Q7Zm9vbGluZyZxdW90OyBpcyBhbiBpbmNvcnJlY3QgZGVzY3JpcHRp b24uIFRoZSBOQVQgaXMgc3VwcG9zZWQgdG8gYmUgdHJhbnNwYXJlbnQgdG8gdGhlIGNsaWVudC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkJ1 dCwgYSBCTEVTU0lORyBvZiBJQ0UvU1RVTi9UVVJOIGlzIHRoYXQgaXQgY2FuIGJlIHNlZW4gYXMg YSBsZWdpdGltYXRlIHJlcXVlc3QgZm9yIGEgc3VpdGFibGUgcGlwZSBmb3INCiBxdWFsaXR5IGRl bWFuZGluZyByZWFsIHRpbWUgdHJhZmZpYy4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibHVlIj5KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JQ0UgaXMgYSBwcmUtcHJvdG9jb2wgeW91IHVzZSBi ZWNhdXNlIHlvdSB3YW50IGEgcGF0aCBmb3IgcmVhbC10aW1lIG1lZGlhIGJldHdlZW4gcGFydGll cy4gSGVyZTogVGhlIGJyb3dzZXINCiBzYXlzIGtub2NrIGtub2NrLCBJIHdhbnQgdG8gZ2V0IG1l ZGlhIHRocm91Z2ggKGFuZCBvZiBjb3Vyc2Ugd2l0aCBhcyBnb29kIHF1YWxpdHkgYXMgcmVxdWly ZWQgYW5kIHBvc3NpYmxlKS4NCjwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPklmIHRoZSBOQVQvRmlyZXdhbGwgb3duZXIgYW5kIG5ldHdvcmsgb3duZXIg YXJlIGFsbG93ZWQgdG8gc2VlIHRoZXNlIHJlcXVlc3RzLCB0aGV5IGNhbiBoZWxwL2Fzc2lzdCBp bg0KIGFjaGlldmluZyB0aGUgZ29vZCBtZWRpYSBwYXRoLiBJZiB0aGV5IGFyZSBub3QgYXdhcmUs IHRoZXkgY2Fubm90IGhlbHAhPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPkhvcGUgdGhpcyBtYWRlIGl0IHVuZGVyc3RhbmRhYmxlIG9uIGFuIG92ZXJ2 aWV3IGxldmVsIGhvdyB0aGlzIGNhbiBiZWNvbWU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+DQog4oCcVFVSTuKApnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnTwvc3Bhbj48 c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkl0IGlzIGFsc28gdGhl IE9OTFkgd2F5IEkgY2FuIHNlZSB0byBhY2hpZXZlIHdoYXQgd2Ugd2FudCB0byBhY2hpZXZlIGFu ZCBzaG91bGQgYmUgdGhlIGFpbSBhbmQgcmVxdWlyZW1lbnQNCiBvZiB0aGlzIG1pbGVzdG9uZS48 L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JIGFtIHRh bGtpbmcgYWJvdXQgZ2VuZXJhbCB1c2FnZSBvZiBXZWJSVEMgb3ZlciBJbnRlcm5ldC9tb2JpbGUg T1RUIChub3QgZmVlZGluZyBXZWJSVEMgaW50byBhcHBsaWNhdGlvbg0KIHNwZWNpZmljIG5ldHdv cmtzIGxpa2UgSU1TIHdoZXJlIG90aGVyIG1ldGhvZHMgbWF5IGV4aXN0KS4gPC9zcGFuPjxzcGFu IGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhpcyBpcyBnb29kLCBub3Qg ZXZpbCE8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5J ZiB0aGUgaGVzaXRhdGlvbnMgYXJlIHJhaXNlZCBiZWNhdXNlIG9mIGEgYmVsaWVmL2hvcGUvd2lz aCB0aGF0IHRoZXJlIGFyZSBubyBvciB3aWxsIG5vdCBiZSBzZXZlcmUgcXVhbGl0eQ0KIGlzc3Vl cyDigJxiZWNhdXNlIGl0IGlzIGFsbCBhYm91dCBiYW5kd2lkdGjigJ0sIOKAnGl0IHdpbGwgcmVz b2x2ZSBpdHNlbGYgd2l0aCB0aW1l4oCdIGV0Yy4sIEkgc3Ryb25nbHkgb2JqZWN0ISBUaGF0IGlz IHdyb25nIGFuZCB3aWxsIGJlIHZlcnkgZGV0cmltZW50YWwgZm9yIFdlYlJUQyB1c2FnZS4gV2Ug YWxyZWFkeSBzZWUgaXQgYW5kIEkgY2FuIGdpdmUgbnVtZXJvdXMgZXhhbXBsZXMgb2YgaG93IG11 Y2ggbGVzcyBxdWFsaXR5IGRlbWFuZGluZyBWb0lQDQogaXMvaXMgbm90IGhhbmRsZWQgcXVhbGl0 eSB3aXNlIGFuZCB0aGF0IGl0IG1hdHRlcnMuIEFuZCwgd2hhdCB3b3VsZCBiZSBiYWQgY29uc2lk ZXJpbmcgcXVhbGl0eSBpc3N1ZXMgYW5kIGFsbG93aW5nL2VuY291cmFnaW5nIG1ldGhvZHMgdG8g ZGVhbCB3aXRoIHRoZW0/PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPklmIHRoZSBoZXNpdGF0aW9ucyBhcmUgcmFpc2VkLCBiZWNhdXNlIG9mIHN1c3Bp Y2lvbiB0aGF0IHRoZSBtZXRob2RzIHdlIG1heSByZWNvbW1lbmQgbWF5IGJlIG1pc3VzZWQgdG8N CiBzdG9wL2Jsb2NrL2Rlc3Ryb3kgV2ViUlRDIHVzYWdlIChlLmcuIHRvIHByb3RlY3QgaW5jb21l IGZyb20gY2FycmllciB0ZWxlcGhvbnkgdHJhZmZpYyksIEkgY291bGQgdW5kZXJzdGFuZCBhbmQg d291bGQgZmlnaHQgdGhlIHNhbWUgYmF0dGxlLiBCdXQgaG9wZWZ1bGx5LCB0aG9zZSBkYXlzIGFy ZSAoc29vbikgb3ZlciDigJMgQXQgbGVhc3QgZm9yd2FyZCB0aGlua2luZyBjYXJyaWVy4oCZcyBy ZWFsaXplIHRoYXQgYWxyZWFkeS4gV2ViIFJUQyB3aWxsDQogaGFwcGVuLiBXaGljaCBjdXN0b21l cnMgd2FudCB0byBwYXkgZm9yIGFuIGFjY2VzcyB3aXRoIGJsb2NrZWQgV2ViUlRDPyBUaGUgY2Fy cmllcuKAmXMgb2ZmZXJpbmcvYXNzdXJpbmcgZ29vZCBXZWJSVEMgd2lsbCByYXRoZXIgZ2V0IHRo ZSBjdXN0b21lcnMgYW5kIGluY29tZQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibHVlIj5KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LiAoTWF5YmUgdGhlIFdlYiBicm93c2VyIGNhbiBk ZXRlY3QgYW5kIGVuY291cmFnZSB0aGlz4oCmKTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1Yi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JZiB0aGVyZSBhcmUgdGVjaG5pY2FsIGNvbmNl cm5zIG9mIGJhZCByZXN1bHQsIG9yIGJldHRlciBtZXRob2RzIGFsbG93aW5nIG5ldHdvcmsgcHJv dmlkZXJzIGFuZCBMQU4gbWFuYWdlcnMNCiB0byBvZmZlciBhbmQgaW5mb3JtIHRoZSBicm93c2Vy IHRoYXQgdGhlcmUgYXJlIGdvb2QgbWVkaWEgcGF0aHMgdG8gYmUgdXNlZCwgYW5kIHRoYXQgdGhl IHdlYiBicm93c2VyIGF1dG9tYXRpY2FsbHkgY2FuIGNob3NlIHRob3NlLCB0aGVuIGxldCB1cyBh bGwgdW5kZXJzdGFuZCB0aG9zZSwgc28gd2UgY2FuIGFjaGlldmUgd2hhdCBzaG91bGQgYmUgYWNo aWV2ZWQgYnkgdGhpcyBtaWxlc3RvbmUuPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U2t5cGUsIEhhbmdvdXRzLCBGYWNldGltZSBhcmUgZG9pbmcgYmls bGlvbnMgb2YgbWludXRlcyBwZXIgd2VlayBhbmQgdGhlIEludGVybmV0IGhhcyBub3QgbWVsdGVk IHlldC4gSWYgd2UgbmVlZCB0byBkbyBmbG93IGlkZW50aWZpY2F0aW9uIHRvIGFsbG93IHRyYWZm aWMgdG8gYmUgcHJpb3JpdGl6ZWQsIGZpbmUgKHNlZSBhYm92ZSByZWdhcmRpbmcgbXkgcHJlZmVy cmVkIGFwcHJvYWNoKSwgYnV0IGZvcmNpbmcNCiBhbGwgV2ViUlRDIHRyYWZmaWMgdGhyb3VnaCBh IE1JVE0gKFRVUk4gc2VydmVyKSBpcyBhIG11Y2ggYmlnZ2VyIGp1bXAgdGhhdCBJIGRvbid0IHll dCBzZWUgdGhlIGp1c3RpZmljYXRpb24gZm9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBzaG9ydDogVFVSTiBpcyBhIHRlY2hub2xvZ3kg dGhhdCBpcyBzdXBwb3NlZCB0byBmYWRlIGF3YXkgd2l0aCB0aGUgbW92ZSB0byBJUHY2LiBJIGRv bid0IHRoaW5rIHdlIHdhbnQgdG8gbWFrZSBpdCBhIGNyaXRpY2FsIGVsZW1lbnQgb2YgV2ViUlRD LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ L0thcmw8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5GcsOlbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gRGFuIFdpbmcgW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZHdpbmdAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHdpbmdAY2lzY28uY29tPC9hPl0NCjxicj4NCjxiPlNr aWNrYXQ6PC9iPiBkZW4gMTEgZmVicnVhcmkgMjAxNCAxODoyNTxicj4NCjxiPlRpbGw6PC9iPiA8 L3NwYW4+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NYXJjIEJsYW5jaGV0 PGJyPg0KPGI+S29waWE6PC9iPiBKdXN0aW4gVWJlcnRpOyA8YSBocmVmPSJtYWlsdG86dGlyZWRk eUBpY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+DQp0aXJlZGR5QGljaXNjby5jb208L2E+OyBL YXJsIFN0YWhsOyA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pg0KdHJhbUBpZXRmLm9yZzwvYT47IFNpbW9uIFBlcnJlYXVsdDwvc3Bhbj48c3BhbiBsYW5nPSJT ViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJTViI+PGJyPg0KPGI+w4RtbmU6PC9iPiBSZTogW3RyYW1dIE1pbGVz dG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJp c2UgYW5kIElTUHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJTViI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5PbiBGZWIgMTEsIDIw MTQsIGF0IDk6MDggQU0sIE1hcmMgQmxhbmNoZXQgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJjLmJs YW5jaGV0QHZpYWdlbmllLmNhIiB0YXJnZXQ9Il9ibGFuayI+bWFyYy5ibGFuY2hldEB2aWFnZW5p ZS5jYTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPkxlIDIwMTQtMDIt MTEgw6AgMDA6MzksIERhbiBXaW5nICZsdDs8YSBocmVmPSJtYWlsdG86ZHdpbmdAY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+ZHdpbmdAY2lzY28uY29tPC9hPiZndDsgYSDDqWNyaXQgOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IlNW Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4N Ck9uIEZlYiAxMCwgMjAxNCwgYXQgNTozMCBQTSwgSnVzdGluIFViZXJ0aSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmp1YmVydGlAZ29vZ2xl LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IlNWIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+R29vZCB0byBzZWUgdGhlcmUgaXMg YSBsb3Qgb2YgaW50ZXJlc3QgZm9yIHRoaXMgbWlsZXN0b25lLiBCdXQgYmFzZWQgb24gdGhlIGRl c2NyaXB0aW9uIGhlcmUsIGl0IHNlZW1zDQogbGlrZSB3ZSB3YW50IHRvIHVzZSBUVVJOIHByaW1h cmlseSB0byBpZGVudGlmeSBXZWJSVEMgZmxvd3MsIGFzIG9wcG9zZWQgdG8gdXNpbmcgaXQgYXMg YSBOQVQgdHJhdmVyc2FsIHRvb2wuIFRoaXMgbWFrZXMgbWUgY29uY2VybmVkIHRoYXQgd2UgbWF5 IGJlIHVzaW5nIHRoZSB3cm9uZyB0ZWNobm9sb2d5IHRvIHNvbHZlIHRoZSBwcm9ibGVtLjwvc3Bh bj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mIzQzOzEuPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pkkgd291bGQgcHJlZmVyIGFsbG93aW5nIGZsb3dzIHRvIGVzdGFibGlzaCB0aGVtc2VsdmVzIHVz aW5nIHRoZWlyICdiZXN0JyBwYXRoLCBhbmQgdGhlIGJlc3QgcGF0aCBpcw0KIHNlbGRvbSB0aHJv dWdoIGEgVFVSTiBzZXJ2ZXIuICZuYnNwO1doZW4gd2UgaW1hZ2luZSBJUHY2IGluIG91ciBmdXR1 cmUsIHdlIGRvbid0IHdhbnQgdG8gZm9yY2UgYW4gYXBwbGljYXRpb24tbGV2ZWwgcHJveHkgKFRV Uk4pIHNlcnZlciBvbiB0aGUgcGF0aCBzb2xlbHkgZm9yIHRyYXZlcnNpbmcgYW4gSVB2NiBmaXJl d2FsbC48L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JdCBzZWVt cyB0aGlzIHRocmVhZCBpcyBjb25mbGF0aW5nIGFsbCB0aGUgcG9zc2libGUgcmVhc29ucyAvIGp1 c3RpZmljYXRpb25zIGZvciBUVVJOOjwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICogbW9iaWxpdHk8L3NwYW4+ PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOyAqIE5BVCB0cmF2ZXJzYWwgKGJvdGggZW5kcG9pbnRzIGFyZSBiZWhpbmQgZW5k cG9pbnQtZGVwZW5kZW50IG1hcHBpbmcgTkFUcyk8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAqJm5ic3A7Zmly ZXdhbGwgdHJhdmVyc2FsIChmaXJld2FsbCBibG9ja3MgVURQKTwvc3Bhbj48c3BhbiBsYW5nPSJT ViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICog ZW5oYW5jaW5nIHByaXZhY3k8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VW5mb3J0dW5hdGVs eSB0aGUgVFVSTiBzZXJ2ZXIgbm9yIHRoZSBlbmRwb2ludCByZWFsbHkga25vdyB3aGljaCBvZiB0 aG9zZSB1c2UtY2FzZXMgaXMgZGVzaXJlZCAoYnkgdGhlDQogdXNlciBvciBieSB0aGUgSVQgbmV0 d29yayBhZG1pbmlzdHJhdG9yKSBvciBuZWNlc3NhcnkgKGZvciB0aGUgY2FsbCB0byB3b3JrIGF0 IGFsbCkuDQo8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJT ViI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+RGFuLCB3aGlsZSBJIGFncmVlIGluIHByaW5j aXBsZSwgSSBkb3VidCB0aGF0IGEgdXNlciBjb3VsZCBldmVyIHNheSAmcXVvdDtJIHdhbnQgbW9i aWxpdHkgb3IgSSB3YW50IE5BVCB0cmF2ZXJzYWwmcXVvdDsuIEkgdGhpbmsgdGhlIHVzZXIgb25s eSB3YW50IHRoZSBjYWxsIHRvIHN1Y2NlZWQsIHdoYXRldmVyDQogdGhlIHByb3BlcnRpZXMgb2Yg aXRzIG5ldHdvcmsgcG9pbnQgb2YgYXR0YWNobWVudCBhcmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPlNvIHdoYXQgY2FuIHdl IGRvPyAmbmJzcDtTaG91bGQgdGhlIFRVUk4gc2VydmVyIHByb3ZpZGUgYW55IGFuZCBhbGwgc2Vy dmljZXMgdGhlIFRVUk4gY2xpZW50IG1pZ2h0IHBvc3NpYmx5IHdhbnQsIGFzIHRoYXQgaXMgd2hh dCBhIHJvYnVzdCBUVVJOIHNlcnZlciB3aWxsIGRvLCBhbmQgdGhlDQogZW5kcG9pbnQgc2hvdWxk IHByZWZlciBUVVJOIGNhbmRpZGF0ZXMgb3ZlciBhbGwgb3RoZXJzIGJlY2F1c2UgdGhlcmUgbWln aHQgYmUgc29tZSBmdW5jdGlvbmFsaXR5IC8gdXNlZnVsbmVzcyBvZiBUVVJOIHRoYXQgdGhlIHVz ZXIgbWlnaHQgZ2FpbiB0aHJvdWdoIFRVUk4gKGUuZy4sIGVuaGFuY2VkIHByaXZhY3kpPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPi1kPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJTViI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBs YW5nPSJTViI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDtUaGlzIHNlZW1zIHByb2JsZW1hdGljLiAmbmJzcDtQZXJoYXBzIHdlIG5lZWQgYSB3 YXkgdG8gc2lnbmFsIHRoZSBkZXNpcmVkIHVzZS1jYXNlICgmcXVvdDt0cmFpdCZxdW90OyksIG9y IGFzIEp1c3Rpbg0KIHN1Z2dlc3RzLCB1c2luZyBhIGRpZmZlcmVudCB0ZWNobm9sb2d5IGZvciBz b21lIG9mIHRoZXNlIHVzZS1jYXNlcy48L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LWQ8L3Nw YW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i U1YiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBNb24s IEZlYiAxMCwgMjAxNCBhdCAzOjE4IFBNLCBLYXJsIFN0YWhsJm5ic3A7Jmx0OzxhIGhyZWY9Im1h aWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlIiB0YXJnZXQ9Il9ibGFuayI+a2FybC5zdGFobEBp bnRlcnRleC5zZTwvYT4mZ3Q7Jm5ic3A7d3JvdGU6PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TaW1vbiw8YnI+DQo8YnI+DQpHb29kIHF1ZXN0aW9u cyAtIHNlZSBpbmxpbmUgYmVsb3cgLS0mZ3Q7IC48YnI+DQpTb21lIG1vcmUgdGhvdWdodCBpcyBy ZXF1aXJlZCE8YnI+DQo8YnI+DQovS2FybDxicj4NCjxicj4NCi0tLS0tVXJzcHJ1bmdsaWd0IG1l ZGRlbGFuZGUtLS0tLTxicj4NCkZyw6VuOiB0cmFtIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnRy YW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW0tYm91bmNlc0BpZXRmLm9y ZzwvYT5dIEbDtnIgU2ltb24gUGVycmVhdWx0PGJyPg0KU2tpY2thdDogZGVuIDEwIGZlYnJ1YXJp IDIwMTQgMTU6MTY8YnI+DQpUaWxsOiBLYXJsIFN0YWhsOyZuYnNwOzxhIGhyZWY9Im1haWx0bzp0 cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9yZzwvYT47Jm5ic3A7PGEg aHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRpcmVkZHlA aWNpc2NvLmNvbTwvYT48YnI+DQrDhG1uZTogUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBz ZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzPC9z cGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0K S2FybCw8YnI+DQo8YnI+DQpJdCBpcyBncmVhdCB0byBzZWUgc3VjaCBlbnRodXNpYXNtISBUaGFu a3MhPGJyPg0KPGJyPg0KSSBoYXZlIGEgY291cGxlIHRlY2huaWNhbCBxdWVzdGlvbnMuLi48YnI+ DQo8YnI+DQpMZSAyMDE0LTAyLTA4IDA4OjExLCBLYXJsIFN0YWhsIGEgw6ljcml0IDo8YnI+DQom Z3Q7IC0gTm90ZSB0aGF0IHRvIGFjaGlldmUgc29tZSBvZiB0aGUgYWJvdmUgcG9pbnRzLCBUVVJO IG11c3QgYmUgZmF2b3JlZDxicj4NCiZndDsgb3ZlciBTVFVOIHRvIGVuZm9yY2UgdGhhdCB0aGUg VFVSTi1wYXRoIGFjdHVhbGx5IGlzIHVzZWQuIChUaGUgQW55Y2FzdDxicj4NCiZndDsgbWV0aG9k IHN1Z2dlc3RlZCBiZWxvdywg4oCcYXV0b21hdGljYWxseeKAnSBkb2VzIHRoaXMuKTxicj4NCjxi cj4NCkkgdW5kZXJzdGFuZCB0aGUgU1RVTiB2cyBUVVJOIHByaW9yaXR5IGlzc3VlLiBCdXQgSSBk b24ndCBzZWUgaG93IGFueWNhc3QgYWZmZWN0cyBpdCBpbiBhbnkgd2F5LiBDYW4geW91IHBsZWFz ZSBleHBsYWluPzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4tLS0gR29vZCBwb2ludCAtIEkgd2FzIGEgYml0IHF1aWNrIGhlcmUgKG1h eWJlIHRvbyBxdWljayk8YnI+DQpXZSBoYXZlIGdpdmVuIHRoaXMgcXVpdGUgYml0IG9mIHRob3Vn aHQsIHNpbmNlIGV2ZW4gaWYgYSBUVVJOIHNlcnZlciBpcyBwcm92aWRlZCBhbmQgZGlzY292ZXJl ZCwgQ1VSUkVOVCB1c2FnZSBvZiBJQ0UgbWF5IHN1Z2dlc3QgYSBjYW5kaWRhdGUgZnJvbSB0aGUg cmVtb3RlIHBhcnR5IHRoYXQgd2lsbCBtYWtlIGEgY29ubmVjdGlvbiB3aXRob3V0IHRoZSBuZWVk L3VzYWdlIG9mIHRoZSBUVVJOIHNlcnZlciAodGhhdCB3ZSB3YW50ZWQgdG8gYmUgdXNlZA0KIGZv ciB0aGUgZ29vZCBwdXJwb3NlcyBsaXN0ZWQpLjxicj4NCjxicj4NClRoZSBvbmx5IHdheSB3ZSBm b3VuZCBhcm91bmQgdGhpcywgd2FzIHRvIHN0b3AgU1RVTiB0aHJvdWdoIHRoZSBJUCBkZWZhdWx0 IGdhdGV3YXkgKGxpa2UgYSByZXN0cmljdGl2ZSBFbnRlcnByaXNlIGZpcmV3YWxsIGRvZXMgaW5o aWJpdGluZyBJQ0UgY29ubmVjdGl2aXR5LCB3aGljaCBvdGhlcnMgYXJlIGNvbmNlcm5lZCBhYm91 dC4uLikuIFNpbmNlIHRoZSBwcm92aXNpb25pbmcgb2YgYXV0by1kaXNjb3ZlcnkgdXNpbmcgdGhl IGFueWNhc3QgbWVjaGFuaXNtLA0KIHdvdWxkIGJlIGFkZGluZyBhIHJvdXRlIGluIGEgZGVmYXVs dCBnYXRld2F5LCBhZGRpbmcgYSBmaXJld2FsbCBydWxlIHRvIGVhdCBTVFVOIHBhY2tldHMgd291 bGQgYXNzdXJlIHRoYXQgdGhlIHByb3Zpc2lvbmVkIFRVUk4gc2VydmVyIGFjdHVhbGx5IGJlY29t ZXMgdXNlZCAoYW5kIG5vdCBieXBhc3NlZCAmcXVvdDtieSBhY2NpZGVudCZxdW90OykuIChUaGF0 IHdhcyB0aGUgdGhvdWdodCBiZWhpbmQgdGhlIOKAnGF1dG9tYXRpY2FsbHnigJ0gd2l0aGluIHF1 b3Rlcy4pPGJyPg0KPGJyPg0KQlVULCBzaW5jZSB5b3UgYnJvdWdodCB1cCB0aGUgcXVlc3Rpb24s IGFzc3VtaW5nIHRoYXQgd2UgaGF2ZSB0aGUgcG93ZXIgdG8gZW5mb3JjZSBXZWJSVEMgdXNhZ2Ug b2YgSUNFLCBJIGJlbGlldmUgYSBNVVNUIHJlcXVpcmVtZW50IHRvIHVzZSBhbiBhdXRvLWRpc2Nv dmVyZWQgVFVSTiBzZXJ2ZXIgaW5zdGVhZCBvZiBTVFVOLCB3b3VsZCBzb2x2ZSB0aGUgc2FtZSBw cm9ibGVtLiBIb3dldmVyLCB0aGlua2luZyBmdXJ0aGVyIChpbiByZWxhdGlvbg0KIHRvIHlvdXIg bmV4dCBxdWVzdGlvbiAtICZxdW90O2FueW9uZSBjb3VsZCBzZXQgdXAgYSBiYWRseS1tYWludGFp bmVkJnF1b3Q7IC0gZW5mb3JjaW5nIHN1Y2ggSUNFIHVzYWdlIG1heSBub3QgYmUgZ29vZC4pPC9z cGFuPjxzcGFuIGxhbmc9IlNWIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0K PGJyPg0KJmd0OyAtIDNecmQgVGhlIEFueWNhc3QgbWV0aG9kIGJlbG93IOKAkyBJIHNlZSBubyBw cm9ibGVtPGJyPg0KJmd0Ozxicj4NCiZndDsgSXQgYWxzbyBoYXMgdGhlIGFkdmFudGFnZSBvZiBl bmNvdXJhZ2luZyAoYnV0IG5vdCByZXF1aXJpbmcpIHRoZTxicj4NCiZndDsgU1RVTi9UVVJOIHRv IGJlIGJ1aWx0IGluIHRoZSBkZWZhdWx0IGdhdGV3YXkgb3IgTkFUL2ZpcmV3YWxsL2FjY2Vzczxi cj4NCiZndDsgcm91dGVyIGl0c2VsZiwgd2l0aCBhIHNlY29uZCBpbnRlcmZhY2UgdG8gYSBwdWJs aWMgSVAgYWRkcmVzcyBvbiB0aGU8YnI+DQomZ3Q7IFdBTiBzaWRlLiAoQ3VycmVudCB2b2x1bWUg ZGVwbG95ZWQsIGxvdyBjb3N0IE5TUCB0cmlwbGUgcGxheSBtb2RlbXM8YnI+DQomZ3Q7IHVzdWFs bHkgaGF2ZSBhIHF1YWxpdHkgYXNzdXJlZCBsZXZlbCAyIG9yIGxldmVsIDMgV0FOIHBpcGUgZm9y IGp1c3Q8YnI+DQomZ3Q7IHZvaWNlIChhbmQgYW5vdGhlciBmb3IgSVBUVikg4oCTIFRoZSBhbnlj YXN0IGRpc2NvdmVyZWQgVFVSTi1zZXJ2ZXIgY2FuPGJyPg0KJmd0OyBiZSB0aGUgYWNjZXNzIGdh dGV3YXkgdG8gc3VjaCBxdWFsaXR5IHBpcGUgZm9yIFdlYlJUQyBtZWRpYSwgaW4gYTxicj4NCiZn dDsgc2luZ2xlIE5TUCBwcm92aWRlZCBDUEUsIHNjYWxpbmcgZnJvbSByZXNpZGVudGlhbCBhbmQg dXAuKTxicj4NCjxicj4NClN1cHBvc2Ugd2UgZGVmaW5lIHdlbGwta25vd24gYW55Y2FzdCBUVVJO IHNlcnZlciBhZGRyZXNzZXMuIEhvdyB3b3VsZCB0aGlzIG5vdCBiZSBzdWJqZWN0IHRvIHRoZSBz YW1lIHNlcnZpY2UgcXVhbGl0eSBpc3N1ZXMgdGhhdCBwbGFndWVkIDZ0bzQ/IFRoYXQgaXMsIGFu eW9uZSBjb3VsZCBzZXQgdXAgYSBiYWRseS1tYWludGFpbmVkLCB1bmRlci1wcm92aXNpb25lZCBU VVJOIHNlcnZlciBhbmQgYW5ub3VuY2UgaXQgb3ZlciBCR1AgdG8gdGhlIHdvcmxkLA0KIGFzIGl0 IHdhcyBkb25lIGZvcjxicj4NCjZ0bzQgcmVsYXlzLiBPciBqdXN0IGJhZCBCR1Agb3V0Ym91bmQg ZmlsdGVyIGNvbmZpZ3VyYXRpb24uIEFuZCBob3cgY2FuIHdlIHByZXZlbnQgdHJpYW5nbGUgcm91 dGluZz8gVGhlcmUgaXMgbm90aGluZyBndWFyYW50ZWVpbmcgdGhhdCB0aGUgYW55Y2FzdCBzZXJ2 ZXIgeW91IHNlZSBpcyBiZWluZyBwcm92aWRlZCB0byB5b3UgYnkgeW91ciBJU1AsIHJhdGhlciB0 aGFuIGEgc2VydmVyIHNpdHRpbmcgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIHBsYW5ldC48L3Nw YW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ LS0tIEdvb2QgcG9pbnQgLSBuZWVkcyB0byBiZSByZXNvbHZlZC4gRm9yIHRoaXMgSSBkb24ndCBo YXZlIGEgcmVhZHkgYW5zd2VyLi4uPGJyPg0KQW4gYXV0by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVy IG11c3QgYmUgdHJ1c3RlZCAod2hhdGV2ZXIgbWV0aG9kIGl0IGlzIGRpc2NvdmVyZWQgYnkpLiBX ZSBhcmUgdHJ1c3RpbmcgdGhlIG9uZSBwcm92aWRpbmcgdXMgd2l0aCBhbiBJUCBhZGRyZXNzIGFu ZCBkZWZhdWx0IGdhdGV3YXkgYW55d2F5LiBJdCB3b3VsZCBiZSBlYXN5IGlmIHdlIGNvdWxkIHJl dXNlIHRoYXQgdHJ1c3QsIGluc3RlYWQgb2YgYW5vdGhlciBtZWNoYW5pc21zLjxicj4NCjxicj4N CklzIHRoZXJlIGEgZ29vZCB3YXkgZm9yIHRoZSBicm93c2VyIHRvIGNoZWNrIHRoYXQgdGhlIGFu eWNhc3QgYWRkcmVzcyBpcyBub3QgaGFuZGxlZCBiZXlvbmQgdGhlIG5ldHdvcmsgc2VydmljZSBw cm92aWRlcidzIGRlZmF1bHQgZ2F0ZXdheT8gSWRlYXM/PC9zcGFuPjxzcGFuIGxhbmc9IlNWIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCjxi cj4NClRoYW5rcyw8YnI+DQpTaW1vbjxicj4NCi0tPGJyPg0KRFROIG1hZGUgZWFzeSwgbGVhbiwg YW5kIHNtYXJ0IC0tJmd0OyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9wb3N0ZWxsYXRpb24udmlhZ2Vu aWUuY2EvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5jYTwv YT48YnI+DQpOQVQ2NC9ETlM2NCBvcGVuLXNvdXJjZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDstLSZndDsmbmJzcDs8YSBocmVmPSJodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYS8iIHRhcmdl dD0iX2JsYW5rIj5odHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYTwvYT48YnI+DQpTVFVOL1RVUk4g c2VydmVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAt LSZndDsmbmJzcDs8YSBocmVmPSJodHRwOi8vbnVtYi52aWFnZW5pZS5jYS8iIHRhcmdldD0iX2Js YW5rIj5odHRwOi8vbnVtYi52aWFnZW5pZS5jYTwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHJhbTwvYT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwv YT48L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJTViI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJh bSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHJhbTwvYT48L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJT ViI+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNw YW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48c3BhbiBs YW5nPSJTViI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 cmFtIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9zcGFuPjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i U1YiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DA8E0xmbrcdx02ciscoc_-- From mom040267@gmail.com Tue Feb 11 23:37:22 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5201A087A for ; Tue, 11 Feb 2014 23:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Wlb3tQOyiMON for ; Tue, 11 Feb 2014 23:37:13 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0311A0875 for ; Tue, 11 Feb 2014 23:37:13 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id g10so8647016pdj.30 for ; Tue, 11 Feb 2014 23:37:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lkTTqiYBtA6YRlsbs8J/cml0v9QExtECPNyITm0quv4=; b=vqohQ7DJttzyAajquSEmo2R0cxuv/+jZF/UDDkm3cGIw4oCWePYI1Oe7/Gzy2qKBu1 YP95URyF7TWGLINrAWyRIZwON5Z0FNRW7v5IdXX/vjW0adt35EnRlNQ8LPtVN0KFFuCi qCB0dMBvbkmtBPzk9OJrRHwMVoDUHc5XaOpEepyWfyT3FrWGO5VxHAbTAdQU4TipMn3e F6wKTseRMsw96+bhQdZPNGa2tbRkPna1Bl7U5dDMiN2Pj/bdamo4Z70qPN8I+aJiYRlY DLkMi92jZWMOw2K7Uf+eYoPi/1a0lkRzcI/ueeJyFql1SPdH/l9EJrm6+DiVKBjRcDJd XDdA== MIME-Version: 1.0 X-Received: by 10.68.89.162 with SMTP id bp2mr15646186pbb.151.1392190632139; Tue, 11 Feb 2014 23:37:12 -0800 (PST) Received: by 10.68.147.131 with HTTP; Tue, 11 Feb 2014 23:37:12 -0800 (PST) In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> Date: Tue, 11 Feb 2014 23:37:12 -0800 Message-ID: From: Oleg Moskalenko To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: multipart/alternative; boundary=047d7b675e3e16a10b04f230a485 Cc: "tireddy@icisco.com" , Simon Perreault , "tram@ietf.org" , Justin Uberti , Marc Blanchet , "Dan Wing \(dwing\)" , Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 07:37:22 -0000 --047d7b675e3e16a10b04f230a485 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The TURN server has to be used when it is either the only option, or if it provides a better path (I guess the second case is rather rare). On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: > +1 > > > > Forcing all traffic through a TURN server and expecting it would provide > the best user experience doesn't look the right approach. Instead, if a > path through a TURN server exists and does provide lower RTT, jitter etc, > being able to detect and use (or switch to) that path might be desirable.= . > > > > Muthu > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Wednesday, February 12, 2014 11:43 AM > *To:* Karl Stahl > *Cc:* tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); > Simon Perreault > *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism > for enterprise and ISPs > > > > Inline. > > > > On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl > wrote: > > Listening to this thread, I am afraid we are missing the very point and > necessity for this milestone! > > - There are severe NAT traversal and quality issues that should and can b= e > dealt with by a good auto-discovery mechanism and the right usage by the > turn client (the WebRTC browser) > > > > There are ways, not only: Enterprises or ISPs wishing to provide their > own TURN server, in an attempt to reduce so-called "triangle routing",nee= d > a new auto-discovery mechanism > > But also: - NSPs (Network Service Providers) want to provide a path where > the bandwidth of WebRTC is better coped with. > > - NSPs or Enterprises want to offer an Internet access quality pipe for > prioritized RTC (Real Time Communication) traffic. > > - Enterprises having restrictive firewalls, want to provide a UDP-path fo= r > WebRTC and possibly also for better quality where RTC do not compete with > data traffic. > > Also considering > > - Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4= G > OTT channels, all should be able to automatically offer their own optimal > TURN server > > > > This leads us into "TURN...to identify WebRTC flows" etc! It is not a > mistake, but the very need for this milestone! > > > > Again, it has not been demonstrated why TURN is the right technology here= , > compared to a more transparent flow identification tool like MALICE. We > don't force all HTTP requests to locate a HTTP proxy via anycast, I don't > see why we need to do the same for WebRTC. > > > > What are the hesitations raised here? > > > TURN primarily to identify WebRTC flows, as opposed to using it as a NA= T > traversal tool. This makes me concerned that we may be using the wrong > technology to solve the problem > > It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall > traversal problem associated with real-time communication (SIP at that > time). However, its largest flaw/problem is that quality things were not > (could not be?) considered. The method's very idea (like all similar > methods for getting RTC through ordinary NAT/Firewalls) is to fool the > media through a NAT/Firewall that is unaware of what is happening. Thus, > this is root of quality issues (and bandwidth allocation optimization) th= at > needs to be dealt with: Real-time traffic fighting with a data traffic > crowded congestion point. > > > > I think that "fooling" is an incorrect description. The NAT is supposed t= o > be transparent to the client. > > > > But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate > request for a suitable pipe for quality demanding real time traffic. J > > ICE is a pre-protocol you use because you want a path for real-time media > between parties. Here: The browser says knock knock, I want to get media > through (and of course with as good quality as required and possible). > > > > If the NAT/Firewall owner and network owner are allowed to see these > requests, they can help/assist in achieving the good media path. If they > are not aware, they cannot help! > > > > Hope this made it understandable on an overview level how this can become= "TURN...to identify WebRTC flows" > > It is also the ONLY way I can see to achieve what we want to achieve and > should be the aim and requirement of this milestone. > > > > I am talking about general usage of WebRTC over Internet/mobile OTT (not > feeding WebRTC into application specific networks like IMS where other > methods may exist). > > > > This is good, not evil! > > > > If the hesitations are raised because of a belief/hope/wish that there ar= e > no or will not be severe quality issues "because it is all about > bandwidth", "it will resolve itself with time" etc., I strongly object! > That is wrong and will be very detrimental for WebRTC usage. We already s= ee > it and I can give numerous examples of how much less quality demanding Vo= IP > is/is not handled quality wise and that it matters. And, what would be ba= d > considering quality issues and allowing/encouraging methods to deal with > them? > > > > If the hesitations are raised, because of suspicion that the methods we > may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to > protect income from carrier telephony traffic), I could understand and > would fight the same battle. But hopefully, those days are (soon) over - = At > least forward thinking carrier's realize that already. Web RTC will happe= n. > Which customers want to pay for an access with blocked WebRTC? The > carrier's offering/assuring good WebRTC will rather get the customers and > income J. (Maybe the Web browser can detect and encourage this...) > > > > If there are technical concerns of bad result, or better methods allowing > network providers and LAN managers to offer and inform the browser that > there are good media paths to be used, and that the web browser > automatically can chose those, then let us all understand those, so we ca= n > achieve what should be achieved by this milestone. > > > > Skype, Hangouts, Facetime are doing billions of minutes per week and the > Internet has not melted yet. If we need to do flow identification to allo= w > traffic to be prioritized, fine (see above regarding my preferred > approach), but forcing all WebRTC traffic through a MITM (TURN server) is= a > much bigger jump that I don't yet see the justification for. > > > > In short: TURN is a technology that is supposed to fade away with the mov= e > to IPv6. I don't think we want to make it a critical element of WebRTC. > > > > /Karl > > > > > > *Fr=E5n:* Dan Wing [mailto:dwing@cisco.com] > *Skickat:* den 11 februari 2014 18:25 > *Till:* Marc Blanchet > *Kopia:* Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; > Simon Perreault > > > *=C4mne:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism fo= r > enterprise and ISPs > > > > > > On Feb 11, 2014, at 9:08 AM, Marc Blanchet > wrote: > > > > Le 2014-02-11 =E0 00:39, Dan Wing a =E9crit : > > > > > On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: > > > > Good to see there is a lot of interest for this milestone. But based on > the description here, it seems like we want to use TURN primarily to > identify WebRTC flows, as opposed to using it as a NAT traversal tool. Th= is > makes me concerned that we may be using the wrong technology to solve the > problem. > > > > +1. > > > > I would prefer allowing flows to establish themselves using their 'best' > path, and the best path is seldom through a TURN server. When we imagine > IPv6 in our future, we don't want to force an application-level proxy > (TURN) server on the path solely for traversing an IPv6 firewall. > > > > > > It seems this thread is conflating all the possible reasons / > justifications for TURN: > > * mobility > > * NAT traversal (both endpoints are behind endpoint-dependent mapping > NATs) > > * firewall traversal (firewall blocks UDP) > > * enhancing privacy > > > > Unfortunately the TURN server nor the endpoint really know which of those > use-cases is desired (by the user or by the IT network administrator) or > necessary (for the call to work at all). > > > > Dan, while I agree in principle, I doubt that a user could ever say "I > want mobility or I want NAT traversal". I think the user only want the ca= ll > to succeed, whatever the properties of its network point of attachment ar= e. > > > > So what can we do? Should the TURN server provide any and all services > the TURN client might possibly want, as that is what a robust TURN server > will do, and the endpoint should prefer TURN candidates over all others > because there might be some functionality / usefulness of TURN that the > user might gain through TURN (e.g., enhanced privacy)? > > > > -d > > > > > > > > This seems problematic. Perhaps we need a way to signal the desired > use-case ("trait"), or as Justin suggests, using a different technology f= or > some of these use-cases. > > > > -d > > > > > > > > > > On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl > wrote: > > Simon, > > Good questions - see inline below --> . > Some more thought is required! > > /Karl > > -----Ursprungligt meddelande----- > Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon Perreault > Skickat: den 10 februari 2014 15:16 > Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com > =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for > enterprise and ISPs > > > Karl, > > It is great to see such enthusiasm! Thanks! > > I have a couple technical questions... > > Le 2014-02-08 08:11, Karl Stahl a =E9crit : > > - Note that to achieve some of the above points, TURN must be favored > > over STUN to enforce that the TURN-path actually is used. (The Anycast > > method suggested below, "automatically" does this.) > > I understand the STUN vs TURN priority issue. But I don't see how anycast > affects it in any way. Can you please explain? > > --- Good point - I was a bit quick here (maybe too quick) > We have given this quite bit of thought, since even if a TURN server is > provided and discovered, CURRENT usage of ICE may suggest a candidate fro= m > the remote party that will make a connection without the need/usage of th= e > TURN server (that we wanted to be used for the good purposes listed). > > The only way we found around this, was to stop STUN through the IP defaul= t > gateway (like a restrictive Enterprise firewall does inhibiting ICE > connectivity, which others are concerned about...). Since the provisionin= g > of auto-discovery using the anycast mechanism, would be adding a route in= a > default gateway, adding a firewall rule to eat STUN packets would assure > that the provisioned TURN server actually becomes used (and not bypassed > "by accident"). (That was the thought behind the "automatically" within > quotes.) > > BUT, since you brought up the question, assuming that we have the power t= o > enforce WebRTC usage of ICE, I believe a MUST requirement to use an > auto-discovered TURN server instead of STUN, would solve the same problem= . > However, thinking further (in relation to your next question - "anyone > could set up a badly-maintained" - enforcing such ICE usage may not be > good.) > > > > > - 3^rd The Anycast method below - I see no problem > > > > It also has the advantage of encouraging (but not requiring) the > > STUN/TURN to be built in the default gateway or NAT/firewall/access > > router itself, with a second interface to a public IP address on the > > WAN side. (Current volume deployed, low cost NSP triple play modems > > usually have a quality assured level 2 or level 3 WAN pipe for just > > voice (and another for IPTV) - The anycast discovered TURN-server can > > be the access gateway to such quality pipe for WebRTC media, in a > > single NSP provided CPE, scaling from residential and up.) > > Suppose we define well-known anycast TURN server addresses. How would thi= s > not be subject to the same service quality issues that plagued 6to4? That > is, anyone could set up a badly-maintained, under-provisioned TURN server > and announce it over BGP to the world, as it was done for > 6to4 relays. Or just bad BGP outbound filter configuration. And how can w= e > prevent triangle routing? There is nothing guaranteeing that the anycast > server you see is being provided to you by your ISP, rather than a server > sitting on the other side of the planet. > > --- Good point - needs to be resolved. For this I don't have a ready > answer... > An auto-discovered TURN server must be trusted (whatever method it is > discovered by). We are trusting the one providing us with an IP address a= nd > default gateway anyway. It would be easy if we could reuse that trust, > instead of another mechanisms. > > Is there a good way for the browser to check that the anycast address is > not handled beyond the network service provider's default gateway? Ideas? > > > > > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7b675e3e16a10b04f230a485 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The TURN server has to be used when it is either the only = option, or if it provides a better path (I guess the second case is rather = rare).


On = Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) <mperu= mal@cisco.com> wrote:

+1

 

Forcing all traffic through a TURN server and expecting it= would provide the best user experience doesn't look the right approach= . Instead, if a path through a TURN server exists and does provide lower RTT, jitter etc, being able to detect and use (or s= witch to) that path might be desirable..

 

Muthu

 

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl
Cc: tireddy@= icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex= .se> wrote:

Listening to this thread, I am= afraid we are missing the very point and necessity for this milestone!

- There are severe NAT travers= al and quality issues that should and can be dealt with by a good auto-disc= overy mechanism and the right usage by the turn client (the WebRTC browser)

 

There are ways, not only: Enterprises or ISPs wishing to provide their own TURN server, in an attemp= t to reduce so-called "triangle routing",need a new auto-discover= y mechanism

But also: - NSPs (Network Serv= ice Providers) want to provide a path where the bandwidth of WebRTC is bett= er coped with.

- NSPs or Enterprises want to = offer an Internet access quality pipe for prioritized RTC (Real Time Commun= ication) traffic.

- Enterprises having restricti= ve firewalls, want to provide a UDP-path for WebRTC and possibly also for better quality where RTC do not compete with data traffic.

Also considering

- Mobility; It is common to mo= ve from a LAN to accessing via WiFi or 3G/4G OTT channels, all should be able to automatically offer their own optimal TURN server

 

This leads us into  “TURN…to identify WebRTC flows&rdqu= o; etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the = right technology here, compared to a more transparent flow identification t= ool like MALICE. We don't force all HTTP requests to locate a HTTP prox= y via anycast, I don't see why we need to do the same for WebRTC. 

 

What are the hesitations raise= d here?

> TURN primarily to identify WebRTC= flows, as opposed to using it as a NAT traversal tool. This makes me conce= rned that we may be using the wrong technology to solve the problem

It is correct that ICE/STUN/TU= RN was designed to address the NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw= /problem is that quality things were not (could not be?) considered. The me= thod’s very idea (like all similar methods for getting RTC through or= dinary NAT/Firewalls) is to fool the media through a NAT/Firewall that is unaware of what is happening. Thus, this is= root of quality issues (and bandwidth allocation optimization) that needs = to be dealt with: Real-time traffic fighting with a data traffic crowded co= ngestion point.

 

I think that "fooling" is an incorrect des= cription. The NAT is supposed to be transparent to the client.

 

But, a BLESSING of ICE/STUN/TU= RN is that it can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. J

ICE is a pre-protocol you use = because you want a path for real-time media between parties. Here: The brow= ser says knock knock, I want to get media through (and of course with as good = quality as required and possible).

 

If the NAT/Firewall owner and = network owner are allowed to see these requests, they can help/assist in achieving the good media path. If they are not aware, they cannot help!

 

Hope this made it understandab= le on an overview level how this can become “TURN…to identify WebRTC flows”

It is also the ONLY way I can = see to achieve what we want to achieve and should be the aim and requiremen= t of this milestone.

 

I am talking about general usa= ge of WebRTC over Internet/mobile OTT (not feeding WebRTC into application specific networks like IMS where other methods may exist).

 

This is good, not evil!=

 

If the hesitations are raised = because of a belief/hope/wish that there are no or will not be severe quali= ty issues “because it is all about bandwidth”, “it will res= olve itself with time” etc., I strongly object! That is wrong and wil= l be very detrimental for WebRTC usage. We already see it and I can give nu= merous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad= considering quality issues and allowing/encouraging methods to deal with t= hem?

 

If the hesitations are raised,= because of suspicion that the methods we may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to protect income from carrier telep= hony traffic), I could understand and would fight the same battle. But hope= fully, those days are (soon) over – At least forward thinking carrier= ’s realize that already. Web RTC will happen. Which customers want to pay for an access with blocked WebRTC? The= carrier’s offering/assuring good WebRTC will rather get the customer= s and income J<= /span>. (Maybe the Web browser can detect and encoura= ge this…) 

 

If there are technical concern= s of bad result, or better methods allowing network providers and LAN manag= ers to offer and inform the browser that there are good media paths to be used= , and that the web browser automatically can chose those, then let us all u= nderstand those, so we can achieve what should be achieved by this mileston= e.

 

Skype, Hangouts, Facetime are doing billions of minu= tes per week and the Internet has not melted yet. If we need to do flow ide= ntification to allow traffic to be prioritized, fine (see above regarding m= y preferred approach), but forcing all WebRTC traffic through a MITM (TURN server) is a much bigger jump that= I don't yet see the justification for.

 

In short: TURN is a technology that is supposed to f= ade away with the move to IPv6. I don't think we want to make it a crit= ical element of WebRTC.

 

/Karl=

 

 

Fr=E5n: Dan Wi= ng [mailto:dwing@cisco= .com]
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon Perreault


=C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism= for enterprise and ISPs

 

 

On Feb 11, 2014, at 9:08 AM, Marc = Blanchet <marc.blanchet@viagenie.ca> wrote:

=  

Le 2014-02-11 =E0 00:39, Dan Wing = <dwing@cisco.com> a =E9crit :

=  

=  

Good to see there is a lot= of interest for this milestone. But based on the description here, it seem= s like we want to use TURN primarily to identify WebRTC flows, as opposed to= using it as a NAT traversal tool. This makes me concerned that we may be u= sing the wrong technology to solve the problem.=

 

+1.

 

I would prefer allowing fl= ows to establish themselves using their 'best' path, and the best p= ath is seldom through a TURN server.  When we imagine IPv6 in our future, we= don't want to force an application-level proxy (TURN) server on the pa= th solely for traversing an IPv6 firewall.<= u>

 

 

It seems this thread is co= nflating all the possible reasons / justifications for TURN:

  * mobility

  * NAT traversal (bo= th endpoints are behind endpoint-dependent mapping NATs)

  * firewall tra= versal (firewall blocks UDP)<= /p>

  * enhancing privacy=

 

Unfortunately the TURN ser= ver nor the endpoint really know which of those use-cases is desired (by th= e user or by the IT network administrator) or necessary (for the call to wor= k at all).

 

Dan, while I agree in principle, I= doubt that a user could ever say "I want mobility or I want NAT trave= rsal". I think the user only want the call to succeed, whatever the properties of its network point of attachment are.

 

So what can we do?  Should th= e TURN server provide any and all services the TURN client might possibly w= ant, as that is what a robust TURN server will do, and the endpoint should prefer TURN candidates over all others because there might= be some functionality / usefulness of TURN that the user might gain throug= h TURN (e.g., enhanced privacy)?

 

-d

 

 

=  

 This seems problemat= ic.  Perhaps we need a way to signal the desired use-case ("trait= "), or as Justin suggests, using a different technology for some of these use-cases.=

 

-d

 

 

=  

 

On Mon, Feb 10, 2014 at 3:= 18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

Simon,

Good questions - see inline below --> .
Some more thought is required!

/Karl

-----Ursprungligt meddelande-----
Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; t= ram@ietf.org; tireddy@icisco.com
=C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for en= terprise and ISPs


Karl,

It is great to see such enthusiasm! Thanks!

I have a couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a =E9crit :
> - Note that to achieve some of the above points, TURN must be favored<= br> > over STUN to enforce that the TURN-path actually is used. (The Anycast=
> method suggested below, “automatically” does this.)

I understand the STUN vs TURN priority issue. But I don't see how anyca= st affects it in any way. Can you please explain?<= u>

--- Good point - I was a b= it quick here (maybe too quick)
We have given this quite bit of thought, since even if a TURN server is pro= vided and discovered, CURRENT usage of ICE may suggest a candidate from the= remote party that will make a connection without the need/usage of the TUR= N server (that we wanted to be used for the good purposes listed).

The only way we found around this, was to stop STUN through the IP default = gateway (like a restrictive Enterprise firewall does inhibiting ICE connect= ivity, which others are concerned about...). Since the provisioning of auto= -discovery using the anycast mechanism, would be adding a route in a default gateway, adding a firewall rule to ea= t STUN packets would assure that the provisioned TURN server actually becom= es used (and not bypassed "by accident"). (That was the thought b= ehind the “automatically” within quotes.)

BUT, since you brought up the question, assuming that we have the power to = enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-di= scovered TURN server instead of STUN, would solve the same problem. However= , thinking further (in relation to your next question - "anyone could set up a badly-maintained"= - enforcing such ICE usage may not be good.)



> - 3^rd The Anycast method below – I see no problem
>
> It also has the advantage of encouraging (but not requiring) the
> STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) – The anycast discovered TURN-serve= r can
> be the access gateway to such quality pipe for WebRTC media, in a
> single NSP provided CPE, scaling from residential and up.)

Suppose we define well-known anycast TURN server addresses. How would this = not be subject to the same service quality issues that plagued 6to4? That i= s, anyone could set up a badly-maintained, under-provisioned TURN server an= d announce it over BGP to the world, as it was done for
6to4 relays. Or just bad BGP outbound filter configuration. And how can we = prevent triangle routing? There is nothing guaranteeing that the anycast se= rver you see is being provided to you by your ISP, rather than a server sit= ting on the other side of the planet.

--- Good point - needs to = be resolved. For this I don't have a ready answer...
An auto-discovered TURN server must be trusted (whatever method it is disco= vered by). We are trusting the one providing us with an IP address and defa= ult gateway anyway. It would be easy if we could reuse that trust, instead = of another mechanisms.

Is there a good way for the browser to check that the anycast address is no= t handled beyond the network service provider's default gateway? Ideas?=




Thanks,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               -->&nb= sp;http://numb.viage= nie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

 

__________________________= _____________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


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

 

 

 


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--047d7b675e3e16a10b04f230a485-- From palmarti@cisco.com Wed Feb 12 00:51:50 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F2C1A08CC for ; Wed, 12 Feb 2014 00:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ggCRIelsQMQf for ; Wed, 12 Feb 2014 00:51:48 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 049B51A08B1 for ; Wed, 12 Feb 2014 00:51:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1445; q=dns/txt; s=iport; t=1392195107; x=1393404707; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=FgV+89YW4joLNEULUMIWecROVZJK7uwbkAWX1SIntDg=; b=bz3oCHeOzWi1Ore2rNtypThWuQfNxby2vAoT44G9OuupA0pTzTBI1d8r qa13wfqE8kudgaVE7P0t79wljaYh5cAH/tXgCUCuDXWo2dUJ5jQwq9jyz wstcqxKkHKj/ddIs5XEWy/Flwt5yYMxzD0ucaJLWrkTj3cV+AGe5kDfZG g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAMc1+1KtJXHA/2dsb2JhbABagww4V78lgRAWdIIseRIBgQAnBA4OEodqDcknF455gyuBFASJEI8agTKQb4Mtgio X-IronPort-AV: E=Sophos;i="4.95,831,1384300800"; d="scan'208";a="303310958" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 12 Feb 2014 08:51:47 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1C8plmk012717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 12 Feb 2014 08:51:47 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.65]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 02:51:46 -0600 From: "Pal Martinsen (palmarti)" To: "tram@ietf.org" Thread-Topic: Communication between app and network using STUN Thread-Index: AQHPJ8+oaj40MN8jhk2bXiv88jHOQw== Date: Wed, 12 Feb 2014 08:51:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Herb Wildfeuer \(hwildfeu\)" Subject: [tram] Communication between app and network using STUN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 08:51:50 -0000 Hi Tramsters, We published a draft today describing extensions to STUN that enables simpl= e communication between the endpoint and the network. Name: draft-martinsen-tram-discuss Revision: 00 Title: Differentiated prIorities and Status Code-points Using Stun Signall= ing (DISCUSS) Document date: 2014-02-12 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-martinsen-tram-di= scuss-00.txt Status: https://datatracker.ietf.org/doc/draft-martinsen-tram-discu= ss/ Htmlized: http://tools.ietf.org/html/draft-martinsen-tram-discuss-00 The main goals for now: - Make it easy for an application to communicate its intent to the network= (QoE) without needing access to the lower layers of the IP stack. Sending = a STUN packet would be an easy solution for the application. - Make it easy for the network to process information from the endpoint. ST= UN have nice characteristics that makes it easy for network elements to pic= k it up. - Create a tightly defined set of STUN attributes that does not leak unnece= ssary information. To describe the draft using established mechanisms; think of it as extended= DSCP markings with ECN capabilities sent in-band using STUN. I realize the TRAM agenda is packet, but hopefully we would fine time to di= scuss if this is something useful that fits under the TRAM charter. .-. P=E5l-Erik From mom040267@gmail.com Wed Feb 12 01:10:44 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3ACE1A08B1 for ; Wed, 12 Feb 2014 01:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 hadyENhKdgX5 for ; Wed, 12 Feb 2014 01:10:42 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C77E91A08AB for ; Wed, 12 Feb 2014 01:10:42 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa1so8886642pad.41 for ; Wed, 12 Feb 2014 01:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gOGaHMXir0NYq5DVG31oX+31RUHrkw8exWqrr4nKurg=; b=Nss9fFD7q0/4yJnjwAIJIC1Kgaboe58FeM0HjxP75cACSRVAyMLKfHwPcZ4gVC50WD bpmXnF94vB3JCiHIah7fyIEYpGBzwR4m3wnMAudrILpB/vqs/MkM7baHpHCv0RtC+Hr9 Hyup8EQ1oxxE6cZmFHdaXOm9gHP65Asn9ArAs5zJ190p5MvkJb+tXJYCYdcIP+Xe0F4b TYLIpiZK3gh6XPmPpAdAjby04rBq5nkht18dyG6neEfaFO0i3HPImIUFUaGiTGHvxH6N 5aLblwsNvxKYtMrbRmfEk1f5+fr34M7QsY+W7J887x5O9yJpVv2x1XYPCu75AzzUMZSZ NdKA== MIME-Version: 1.0 X-Received: by 10.68.212.161 with SMTP id nl1mr182090pbc.142.1392196241186; Wed, 12 Feb 2014 01:10:41 -0800 (PST) Received: by 10.68.147.131 with HTTP; Wed, 12 Feb 2014 01:10:41 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Feb 2014 01:10:41 -0800 Message-ID: From: Oleg Moskalenko To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=e89a8ff1c89c69e38a04f231f2f1 Cc: "Herb Wildfeuer \(hwildfeu\)" , "tram@ietf.org" Subject: Re: [tram] Communication between app and network using STUN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 09:10:45 -0000 --e89a8ff1c89c69e38a04f231f2f1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Question (or comment) on Section 6.3: Can the application be behind a NAT ? Can a NAT be involved ? If yes, then all applications behind that NAT may have the same IP address, from the STUN message receiver point of view. Then how the Session ID and the priority works in such a case ? Oleg On Wed, Feb 12, 2014 at 12:51 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > > Hi Tramsters, > > We published a draft today describing extensions to STUN that enables > simple communication between the endpoint and the network. > > > Name: draft-martinsen-tram-discuss > Revision: 00 > Title: Differentiated prIorities and Status Code-points Using > Stun Signalling (DISCUSS) > Document date: 2014-02-12 > Group: Individual Submission > Pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-martinsen-tram-discuss-00.txt > Status: > https://datatracker.ietf.org/doc/draft-martinsen-tram-discuss/ > Htmlized: http://tools.ietf.org/html/draft-martinsen-tram-discuss-0= 0 > > > The main goals for now: > > - Make it easy for an application to communicate its intent to the > network (QoE) without needing access to the lower layers of the IP stack. > Sending a STUN packet would be an easy solution for the application. > - Make it easy for the network to process information from the endpoint. > STUN have nice characteristics that makes it easy for network elements to > pick it up. > - Create a tightly defined set of STUN attributes that does not leak > unnecessary information. > > To describe the draft using established mechanisms; think of it as > extended DSCP markings with ECN capabilities sent in-band using STUN. > > I realize the TRAM agenda is packet, but hopefully we would fine time to > discuss if this is something useful that fits under the TRAM charter. > > .-. > P=E5l-Erik > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --e89a8ff1c89c69e38a04f231f2f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Question (or comment) on Section 6.3:

Can the application be behind a NAT ? Can a NAT be involved ? If ye= s, then all applications behind that NAT may have the same IP address, from= the STUN message receiver point of view. Then how the Session ID and the p= riority works in such a case ?

Oleg





On Wed, Feb 12, 2014 at 12:51 AM, P= al Martinsen (palmarti) <palmarti@cisco.com> wrote:

Hi Tramsters,

We published a draft today describing extensions to STUN that enables simpl= e communication between the endpoint and the network.


Name: =A0 =A0 =A0 =A0 =A0 draft-martinsen-tram-discuss
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0Differentiated prIorities and Status Code-points = Using Stun Signalling (DISCUSS)
Document date: =A02014-02-12
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A013
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/= internet-drafts/draft-martinsen-tram-discuss-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/doc/= draft-martinsen-tram-discuss/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-martin= sen-tram-discuss-00


The main goals for now:

=A0- Make it easy for an application to communicate its intent to the netwo= rk (QoE) without needing access to the lower layers of the IP stack. Sendin= g a STUN packet would be an easy solution for the application.
- Make it easy for the network to process information from the endpoint. ST= UN have nice characteristics that makes it easy for network elements to pic= k it up.
- Create a tightly defined set of STUN attributes that does not leak unnece= ssary information.

To describe the draft using established mechanisms; think of it as extended= DSCP markings with ECN capabilities sent in-band using STUN.

I realize the TRAM agenda is packet, but hopefully we would fine time to di= scuss if this is something useful that fits under the TRAM charter.

.-.
P=E5l-Erik

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--e89a8ff1c89c69e38a04f231f2f1-- From palmarti@cisco.com Wed Feb 12 01:13:41 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4341A08C9 for ; Wed, 12 Feb 2014 01:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 vfTG0EZ4hXDR for ; Wed, 12 Feb 2014 01:13:39 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 300661A08C1 for ; Wed, 12 Feb 2014 01:13:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1117; q=dns/txt; s=iport; t=1392196419; x=1393406019; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=G3V5kfiNbImtnbZqwa/zEsmPejIJAGxCn56K1uHqDpU=; b=Iy2CcVXGl9KU0vnESgphoh4e5kiH6Oe4FYRPMaJDqmk36muasacUXTln 9lVv4NkuenycZLXUk/DCgweLJtC+N4sRXi1C8kpjEoZB+mLH7pjCc4G8k XD4DJBhPxTuoxDMZ5Pfve/JfO8VFqtLB/Gxw+yrBuHC8PMwSkOzdhZ+VL g=; X-IronPort-AV: E=Sophos;i="4.95,831,1384300800"; d="scan'208";a="303529616" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 12 Feb 2014 09:13:37 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1C9DbJ4017494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 09:13:37 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.65]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 03:13:37 -0600 From: "Pal Martinsen (palmarti)" To: Justin Uberti Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPJ7mlTNEKdEV/S06oVknK3f+v9pqxuouA Date: Wed, 12 Feb 2014 09:13:36 +0000 Message-ID: <0D315AC8-BCD4-4BAC-B4B3-6BBFD1AED17A@cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.70] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tireddy@icisco.com" , Simon Perreault , "tram@ietf.org" , Marc Blanchet , "Dan Wing \(dwing\)" , Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 09:13:41 -0000 Inline and a lot of context clipped away. On 12 Feb 2014, at 07:13 am, Justin Uberti wrote: > Inline. >=20 > On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl wrot= e: [cut] > This leads us into =93TURN=85to identify WebRTC flows=94 etc! It is not = a mistake, but the very need for this milestone! >=20 >=20 > Again, it has not been demonstrated why TURN is the right technology here= , compared to a more transparent flow identification tool like MALICE. We d= on't force all HTTP requests to locate a HTTP proxy via anycast, I don't se= e why we need to do the same for WebRTC.=20 >=20 We renamed MALICE to DISCUSS. To get rid of Meta-data associations and ICE= from the name, and to indicate that this is a much simplified version. DISCUSS is posted here: http://tools.ietf.org/html/draft-martinsen-tram-dis= cuss-00 Started a separate thread on the topic. Just wanted to make explain the MAL= ICE -> DISCUSS correlation. Is it possible to get a link from the expired MALICE draft to the new DISCU= SS draft? How?=20 .-. P=E5l-Erik From mperumal@cisco.com Wed Feb 12 01:28:10 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F20A1A08E6 for ; Wed, 12 Feb 2014 01:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 GJjVDjRHym41 for ; Wed, 12 Feb 2014 01:28:00 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 77ABD1A08E3 for ; Wed, 12 Feb 2014 01:27:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59740; q=dns/txt; s=iport; t=1392197279; x=1393406879; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=p0nwBo9dB/MiL02Ne4rul/imipNL/aTZ4KD2V2Zz+f4=; b=PHNlTXF7XSELaH7VaZXXnXIOOsj2eJB9M0nTMzzLFucTnAgj0pDqQerH OqPVjmckq+iSghpK2I4aWwhnMdqtbbw8Y3fTKoWwDZ7HFkIiUtEWWljg0 ppX0hB7rlOaFJDtij+ynHxYEwOXjlKNzuvNaQUlXlR32LhbBNty0poGZu 0=; X-IronPort-AV: E=Sophos;i="4.95,831,1384300800"; d="scan'208,217";a="303467288" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 12 Feb 2014 09:27:58 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1C9RwA1003903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 09:27:58 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.56]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 03:27:58 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Oleg Moskalenko Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPJ7mlnafoQENNEUmFuRpz1h1atZqxMH2AgABvIQD//7gfIA== Date: Wed, 12 Feb 2014 09:27:57 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.13] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DAB7Dxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "tireddy@icisco.com" , Simon Perreault , "tram@ietf.org" , Justin Uberti , Marc Blanchet , "Dan Wing \(dwing\)" , Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 09:28:10 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DAB7Dxmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, I believe the second case is rare, but would be better than a rat race= b/w administrators trying to block p2p traffic and force it through a TURN= server and apps/endpoints finding smarter ways to bypass them. Muthu From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf= .org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for e= nterprise and ISPs The TURN server has to be used when it is either the only option, or if it = provides a better path (I guess the second case is rather rare). On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) > wrote: +1 Forcing all traffic through a TURN server and expecting it would provide th= e best user experience doesn't look the right approach. Instead, if a path = through a TURN server exists and does provide lower RTT, jitter etc, being = able to detect and use (or switch to) that path might be desirable.. Muthu From: tram [mailto:tram-bounces@ietf.org] On = Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf= .org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for e= nterprise and ISPs Inline. On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl > wrote: Listening to this thread, I am afraid we are missing the very point and nec= essity for this milestone! - There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the tu= rn client (the WebRTC browser) There are ways, not only: Enterprises or ISPs wishing to provide their own = TURN server, in an attempt to reduce so-called "triangle routing",need a ne= w auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path where t= he bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for pri= oritized RTC (Real Time Communication) traffic. - Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete with d= ata traffic. Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own optimal T= URN server This leads us into "TURN...to identify WebRTC flows" etc! It is not a mist= ake, but the very need for this milestone! Again, it has not been demonstrated why TURN is the right technology here, = compared to a more transparent flow identification tool like MALICE. We don= 't force all HTTP requests to locate a HTTP proxy via anycast, I don't see = why we need to do the same for WebRTC. What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong tech= nology to solve the problem It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall t= raversal problem associated with real-time communication (SIP at that time)= . However, its largest flaw/problem is that quality things were not (could = not be?) considered. The method's very idea (like all similar methods for g= etting RTC through ordinary NAT/Firewalls) is to fool the media through a N= AT/Firewall that is unaware of what is happening. Thus, this is root of qua= lity issues (and bandwidth allocation optimization) that needs to be dealt = with: Real-time traffic fighting with a data traffic crowded congestion poi= nt. I think that "fooling" is an incorrect description. The NAT is supposed to = be transparent to the client. But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate req= uest for a suitable pipe for quality demanding real time traffic. :) ICE is a pre-protocol you use because you want a path for real-time media b= etween parties. Here: The browser says knock knock, I want to get media thr= ough (and of course with as good quality as required and possible). If the NAT/Firewall owner and network owner are allowed to see these reques= ts, they can help/assist in achieving the good media path. If they are not = aware, they cannot help! Hope this made it understandable on an overview level how this can become "= TURN...to identify WebRTC flows" It is also the ONLY way I can see to achieve what we want to achieve and sh= ould be the aim and requirement of this milestone. I am talking about general usage of WebRTC over Internet/mobile OTT (not fe= eding WebRTC into application specific networks like IMS where other method= s may exist). This is good, not evil! If the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues "because it is all about bandwidth"= , "it will resolve itself with time" etc., I strongly object! That is wrong= and will be very detrimental for WebRTC usage. We already see it and I can= give numerous examples of how much less quality demanding VoIP is/is not h= andled quality wise and that it matters. And, what would be bad considering= quality issues and allowing/encouraging methods to deal with them? If the hesitations are raised, because of suspicion that the methods we may= recommend may be misused to stop/block/destroy WebRTC usage (e.g. to prote= ct income from carrier telephony traffic), I could understand and would fig= ht the same battle. But hopefully, those days are (soon) over - At least fo= rward thinking carrier's realize that already. Web RTC will happen. Which c= ustomers want to pay for an access with blocked WebRTC? The carrier's offer= ing/assuring good WebRTC will rather get the customers and income :). (Mayb= e the Web browser can detect and encourage this...) If there are technical concerns of bad result, or better methods allowing n= etwork providers and LAN managers to offer and inform the browser that ther= e are good media paths to be used, and that the web browser automatically c= an chose those, then let us all understand those, so we can achieve what sh= ould be achieved by this milestone. Skype, Hangouts, Facetime are doing billions of minutes per week and the In= ternet has not melted yet. If we need to do flow identification to allow tr= affic to be prioritized, fine (see above regarding my preferred approach), = but forcing all WebRTC traffic through a MITM (TURN server) is a much bigge= r jump that I don't yet see the justification for. In short: TURN is a technology that is supposed to fade away with the move = to IPv6. I don't think we want to make it a critical element of WebRTC. /Karl Fr=E5n: Dan Wing [mailto:dwing@cisco.com] Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl S= tahl; tram@ietf.org; Simon Perreault =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for en= terprise and ISPs On Feb 11, 2014, at 9:08 AM, Marc Blanchet > wrote: Le 2014-02-11 =E0 00:39, Dan Wing >= a =E9crit : On Feb 10, 2014, at 5:30 PM, Justin Uberti > wrote: Good to see there is a lot of interest for this milestone. But based on the= description here, it seems like we want to use TURN primarily to identify = WebRTC flows, as opposed to using it as a NAT traversal tool. This makes me= concerned that we may be using the wrong technology to solve the problem. +1. I would prefer allowing flows to establish themselves using their 'best' pa= th, and the best path is seldom through a TURN server. When we imagine IPv= 6 in our future, we don't want to force an application-level proxy (TURN) s= erver on the path solely for traversing an IPv6 firewall. It seems this thread is conflating all the possible reasons / justification= s for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping NAT= s) * firewall traversal (firewall blocks UDP) * enhancing privacy Unfortunately the TURN server nor the endpoint really know which of those u= se-cases is desired (by the user or by the IT network administrator) or nec= essary (for the call to work at all). Dan, while I agree in principle, I doubt that a user could ever say "I want= mobility or I want NAT traversal". I think the user only want the call to = succeed, whatever the properties of its network point of attachment are. So what can we do? Should the TURN server provide any and all services the= TURN client might possibly want, as that is what a robust TURN server will= do, and the endpoint should prefer TURN candidates over all others because= there might be some functionality / usefulness of TURN that the user might= gain through TURN (e.g., enhanced privacy)? -d This seems problematic. Perhaps we need a way to signal the desired use-c= ase ("trait"), or as Justin suggests, using a different technology for some= of these use-cases. -d On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl > wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F= =F6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for en= terprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =E9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, "automatically" does this.) I understand the STUN vs TURN priority issue. But I don't see how anycast a= ffects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is pro= vided and discovered, CURRENT usage of ICE may suggest a candidate from the= remote party that will make a connection without the need/usage of the TUR= N server (that we wanted to be used for the good purposes listed). The only way we found around this, was to stop STUN through the IP default = gateway (like a restrictive Enterprise firewall does inhibiting ICE connect= ivity, which others are concerned about...). Since the provisioning of auto= -discovery using the anycast mechanism, would be adding a route in a defaul= t gateway, adding a firewall rule to eat STUN packets would assure that the= provisioned TURN server actually becomes used (and not bypassed "by accide= nt"). (That was the thought behind the "automatically" within quotes.) BUT, since you brought up the question, assuming that we have the power to = enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-di= scovered TURN server instead of STUN, would solve the same problem. However= , thinking further (in relation to your next question - "anyone could set u= p a badly-maintained" - enforcing such ICE usage may not be good.) > - 3^rd The Anycast method below - I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) - The anycast discovered TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would this = not be subject to the same service quality issues that plagued 6to4? That i= s, anyone could set up a badly-maintained, under-provisioned TURN server an= d announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can we = prevent triangle routing? There is nothing guaranteeing that the anycast se= rver you see is being provided to you by your ISP, rather than a server sit= ting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready answer= ... An auto-discovered TURN server must be trusted (whatever method it is disco= vered by). We are trusting the one providing us with an IP address and defa= ult gateway anyway. It would be easy if we could reuse that trust, instead = of another mechanisms. Is there a good way for the browser to check that the anycast address is no= t handled beyond the network service provider's default gateway? Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DAB7Dxmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes, I believe the second case is rare, but would be bette= r than a rat race b/w administrators trying to block p2p traffic and force = it through a TURN server and apps/endpoints finding smarter ways to bypass them.

 

Muthu

 

From: Oleg Mos= kalenko [mailto:mom040267@gmail.com]
Sent: Wednesday, February 12, 2014 1:07 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tr= am@ietf.org; Dan Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

 

The TURN server has to be used when it is either the= only option, or if it provides a better path (I guess the second case is r= ather rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi P= erumal (mperumal) <mperumal@cisco.com> wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would provide= the best user experience doesn't look the right approach. Instead, if a path through a TURN server exists and does provide= lower RTT, jitter etc, being able to detect and use (or switch to) that pa= th might be desirable..

 

Muthu

 

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl
Cc: tireddy@= icisco.com; Marc Blanchet; tram@ietf.org; Dan W= ing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> wr= ote:

Listening to this thread, I am afraid we are= missing the very point and necessity for this milestone!=

- There are severe NAT traversal and quality= issues that should and can be dealt with by a good auto-discovery mechanism and the right usage by the turn client (the WebRTC browser)

 

There are ways, not only: Enterprises or ISPs wishing to provide their own TURN server, in an attemp= t to reduce so-called "triangle routing",need a new auto-discover= y mechanism

But also: - NSPs (Network Service Providers)= want to provide a path where the bandwidth of WebRTC is better coped with.

- NSPs or Enterprises want to offer an Inter= net access quality pipe for prioritized RTC (Real Time Communication) traffic.

- Enterprises having restrictive firewalls, = want to provide a UDP-path for WebRTC and possibly also for better quality where RTC do not compete with data traffic.

Also considering

- Mobility; It is common to move from a LAN = to accessing via WiFi or 3G/4G OTT channels, all should be able to automatically offer their own optimal TURN server

 

This leads us into  “TURN…to identify WebRTC flows”= ; etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the right technolo= gy here, compared to a more transparent flow identification tool like MALIC= E. We don't force all HTTP requests to locate a HTTP proxy via anycast, I don't see why we need to do the same= for WebRTC. 

 

What are the hesitations raised here?=

> TURN primarily to identify WebRTC flows, as opp= osed to using it as a NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem=

It is correct that ICE/STUN/TURN was designe= d to address the NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw= /problem is that quality things were not (could not be?) considered. The me= thod’s very idea (like all similar methods for getting RTC through or= dinary NAT/Firewalls) is to fool the media through a NAT/Firewall that is unaware of what is happening. Thus, this is= root of quality issues (and bandwidth allocation optimization) that needs = to be dealt with: Real-time traffic fighting with a data traffic crowded co= ngestion point.

 

I think that "fooling" is an incorrect description. The = NAT is supposed to be transparent to the client.

 

But, a BLESSING of ICE/STUN/TURN is that it = can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. J

ICE is a pre-protocol you use because you wa= nt a path for real-time media between parties. Here: The browser says knock knock, I want to get media through (and of course with as good = quality as required and possible).

 

If the NAT/Firewall owner and network owner = are allowed to see these requests, they can help/assist in achieving the good media path. If they are not aware, they cannot help!

 

Hope this made it understandable on an overv= iew level how this can become “TURN…to identify WebRTC flows”

It is also the ONLY way I can see to achieve= what we want to achieve and should be the aim and requirement of this milestone.

 

I am talking about general usage of WebRTC o= ver Internet/mobile OTT (not feeding WebRTC into application specific networks like IMS where other methods may exist).

 

This is good, not evil!

 

If the hesitations are raised because of a b= elief/hope/wish that there are no or will not be severe quality issues “because it is all about bandwidth”, “it will res= olve itself with time” etc., I strongly object! That is wrong and wil= l be very detrimental for WebRTC usage. We already see it and I can give nu= merous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad= considering quality issues and allowing/encouraging methods to deal with t= hem?

 

If the hesitations are raised, because of su= spicion that the methods we may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to protect income from carrier telep= hony traffic), I could understand and would fight the same battle. But hope= fully, those days are (soon) over – At least forward thinking carrier= ’s realize that already. Web RTC will happen. Which customers want to pay for an access with blocked WebRTC? The= carrier’s offering/assuring good WebRTC will rather get the customer= s and income J<= /span>. (Maybe the Web browser can detect and encoura= ge this…) 

 

If there are technical concerns of bad resul= t, or better methods allowing network providers and LAN managers to offer and inform the browser that there are good media paths to be used= , and that the web browser automatically can chose those, then let us all u= nderstand those, so we can achieve what should be achieved by this mileston= e.

 

Skype, Hangouts, Facetime are doing billions of minutes per week a= nd the Internet has not melted yet. If we need to do flow identification to= allow traffic to be prioritized, fine (see above regarding my preferred approach), but forcing all WebRTC traffi= c through a MITM (TURN server) is a much bigger jump that I don't yet see t= he justification for.

 

In short: TURN is a technology that is supposed to fade away with = the move to IPv6. I don't think we want to make it a critical element of We= bRTC.

 

/Karl

 

 

Fr=E5n: Dan Wing [mailto:dwing@cisco.com]
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon Perreault


=C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism= for enterprise and ISPs

 

 

On Feb 11, 2014, at 9:08 AM, Marc Blanchet <<= a href=3D"mailto:marc.blanchet@viagenie.ca" target=3D"_blank">marc.blanchet= @viagenie.ca> wrote:

 

Le 2014-02-11 =E0 00:39, Dan Wing <dwing@cisco.com> a =E9cri= t :

 


On Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> wrote:

 

Good to see there is a lot of interest f= or this milestone. But based on the description here, it seems like we want to use TURN primarily to identify WebRTC flows, as opposed to= using it as a NAT traversal tool. This makes me concerned that we may be u= sing the wrong technology to solve the problem.

 

+1.

 

I would prefer allowing flows to establi= sh themselves using their 'best' path, and the best path is seldom through a TURN server.  When we imagine IPv6 in our future, we= don't want to force an application-level proxy (TURN) server on the path s= olely for traversing an IPv6 firewall.

 

 

It seems this thread is conflating all t= he possible reasons / justifications for TURN:

  * mobility

  * NAT traversal (both endpoints a= re behind endpoint-dependent mapping NATs)

  * firewall traversal (firewa= ll blocks UDP)

  * enhancing privacy

 

Unfortunately the TURN server nor the en= dpoint really know which of those use-cases is desired (by the user or by the IT network administrator) or necessary (for the call to wor= k at all).

 

Dan, while I agree in principle, I doubt that a = user could ever say "I want mobility or I want NAT traversal". I = think the user only want the call to succeed, whatever the properties of its network point of attachment are.

 

So what can we do?  Should the TURN server = provide any and all services the TURN client might possibly want, as that i= s what a robust TURN server will do, and the endpoint should prefer TURN candidates over all others because there might= be some functionality / usefulness of TURN that the user might gain throug= h TURN (e.g., enhanced privacy)?

 

-d

 

 

 

 This seems problematic.  Perh= aps we need a way to signal the desired use-case ("trait"), or as= Justin suggests, using a different technology for some of these use-cases.=

 

-d

 

 

 

 

On Mon, Feb 10, 2014 at 3:18 PM, Karl St= ahl <ka= rl.stahl@intertex.se> wrote:

Simon,

Good questions - see inline below --> .
Some more thought is required!

/Karl

-----Ursprungligt meddelande-----
Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; t= ram@ietf.org; tireddy@icisco.com
=C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for en= terprise and ISPs


Karl,

It is great to see such enthusiasm! Thanks!

I have a couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a =E9crit :
> - Note that to achieve some of the above points, TURN must be favored<= br> > over STUN to enforce that the TURN-path actually is used. (The Anycast=
> method suggested below, “automatically” does this.)

I understand the STUN vs TURN priority issue. But I don't see how anycast a= ffects it in any way. Can you please explain?

--- Good point - I was a bit quick here = (maybe too quick)
We have given this quite bit of thought, since even if a TURN server is pro= vided and discovered, CURRENT usage of ICE may suggest a candidate from the= remote party that will make a connection without the need/usage of the TUR= N server (that we wanted to be used for the good purposes listed).

The only way we found around this, was to stop STUN through the IP default = gateway (like a restrictive Enterprise firewall does inhibiting ICE connect= ivity, which others are concerned about...). Since the provisioning of auto= -discovery using the anycast mechanism, would be adding a route in a default gateway, adding a firewall rule to ea= t STUN packets would assure that the provisioned TURN server actually becom= es used (and not bypassed "by accident"). (That was the thought b= ehind the “automatically” within quotes.)

BUT, since you brought up the question, assuming that we have the power to = enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-di= scovered TURN server instead of STUN, would solve the same problem. However= , thinking further (in relation to your next question - "anyone could set up a badly-maintained"= - enforcing such ICE usage may not be good.)



> - 3^rd The Anycast method below – I see no problem
>
> It also has the advantage of encouraging (but not requiring) the
> STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) – The anycast discovered TURN-serve= r can
> be the access gateway to such quality pipe for WebRTC media, in a
> single NSP provided CPE, scaling from residential and up.)

Suppose we define well-known anycast TURN server addresses. How would this = not be subject to the same service quality issues that plagued 6to4? That i= s, anyone could set up a badly-maintained, under-provisioned TURN server an= d announce it over BGP to the world, as it was done for
6to4 relays. Or just bad BGP outbound filter configuration. And how can we = prevent triangle routing? There is nothing guaranteeing that the anycast se= rver you see is being provided to you by your ISP, rather than a server sit= ting on the other side of the planet.

--- Good point - needs to be resolved. F= or this I don't have a ready answer...
An auto-discovered TURN server must be trusted (whatever method it is disco= vered by). We are trusting the one providing us with an IP address and defa= ult gateway anyway. It would be easy if we could reuse that trust, instead = of another mechanisms.

Is there a good way for the browser to check that the anycast address is no= t handled beyond the network service provider's default gateway? Ideas?




Thanks,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               -->&nb= sp;http://numb.viage= nie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

 

________________________________________= _______
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


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

 

 

 


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

 

--_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DAB7Dxmbrcdx02ciscoc_-- From palmarti@cisco.com Wed Feb 12 01:58:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474B61A090F for ; Wed, 12 Feb 2014 01:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 vgBbmi5UiB7L for ; Wed, 12 Feb 2014 01:58:08 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 519751A090B for ; Wed, 12 Feb 2014 01:58:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9081; q=dns/txt; s=iport; t=1392199088; x=1393408688; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sjqblz+P/U5emo2vUmb5MIbohlHr6Km4dQziE8MQmj0=; b=eQtzReXG7Dz0tqGjTGwSPWin/Rj5sZQsYDjLkusREMiTBRJIx6yhP5iQ IXgmrBOCugbB2JyolXCEXHtu3Ac1TpljqZMulA14/BLsnWPR/RUVWAABt WohshVqhXuQBX4Vyokx44INcjqQwF4icrOjfACNyGOAnqSsEl4TM9JDJl U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0GAARF+1KtJXHB/2dsb2JhbABagww4V7ZRiFSBEBZ0giYBAQQBAQFlBgsQAgEIDjEHIQYLFBECBA4FCRKHVgMRDcBTDYguF4xfgXgeBAeDJIEUBIkQjS6BbIEyiyyFQ4Mtgio X-IronPort-AV: E=Sophos;i="4.95,831,1384300800"; d="scan'208,217";a="303494849" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 12 Feb 2014 09:58:07 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1C9w76u012037 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 09:58:07 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.65]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 03:58:07 -0600 From: "Pal Martinsen (palmarti)" To: Oleg Moskalenko Thread-Topic: [tram] Communication between app and network using STUN Thread-Index: AQHPJ8+oaj40MN8jhk2bXiv88jHOQ5qxuZCAgAANPoA= Date: Wed, 12 Feb 2014 09:58:06 +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: [10.55.154.70] Content-Type: multipart/alternative; boundary="_000_F08F11F333F34D06B58631ECE4B920C3ciscocom_" MIME-Version: 1.0 Cc: "Herb Wildfeuer \(hwildfeu\)" , "tram@ietf.org" Subject: Re: [tram] Communication between app and network using STUN X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 09:58:11 -0000 --_000_F08F11F333F34D06B58631ECE4B920C3ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Oleg, That was an impressive quick read. Thanks for the interest. On 12 Feb 2014, at 10:10 am, Oleg Moskalenko > wrote: Question (or comment) on Section 6.3: Can the application be behind a NAT ? Can a NAT be involved ? Yes. That is the beauty of in-band STUN signalling. If yes, then all applications behind that NAT may have the same IP address,= from the STUN message receiver point of view. Then how the Session ID and = the priority works in such a case ? It wont. Unless we come up with something clever.. So the problem is if that you have a system that produces a main video str= eam from one IP and a presentation video stream from another IP? You would = like the network to know that you care more about the main video, and if pr= oblems occur it should preferably drop packets from the presentation stream= . And this should be up to the application to choose, in another situation = it might be the presentation video stream that is the most important (It mi= ght dynamically change during the conference as well). The main rationale for limiting it to the IP address was to reduce the ince= ntive to lie about the priorities. It does not get you better bandwidth, it= just tells the network what to which of your own packets to drop if there = is a problem. It might be worth having a stronger id to allow us to loosen = the IP address requirements. What I am afraid of is to open up for cross application priorities. That is= a rathole I would like to avoid for now. .-. P=E5l-Erik Oleg On Wed, Feb 12, 2014 at 12:51 AM, Pal Martinsen (palmarti) > wrote: Hi Tramsters, We published a draft today describing extensions to STUN that enables simpl= e communication between the endpoint and the network. Name: draft-martinsen-tram-discuss Revision: 00 Title: Differentiated prIorities and Status Code-points Using Stun= Signalling (DISCUSS) Document date: 2014-02-12 Group: Individual Submission Pages: 13 URL: http://www.ietf.org/internet-drafts/draft-martinsen-tram-di= scuss-00.txt Status: https://datatracker.ietf.org/doc/draft-martinsen-tram-discu= ss/ Htmlized: http://tools.ietf.org/html/draft-martinsen-tram-discuss-00 The main goals for now: - Make it easy for an application to communicate its intent to the network= (QoE) without needing access to the lower layers of the IP stack. Sending = a STUN packet would be an easy solution for the application. - Make it easy for the network to process information from the endpoint. ST= UN have nice characteristics that makes it easy for network elements to pic= k it up. - Create a tightly defined set of STUN attributes that does not leak unnece= ssary information. To describe the draft using established mechanisms; think of it as extended= DSCP markings with ECN capabilities sent in-band using STUN. I realize the TRAM agenda is packet, but hopefully we would fine time to di= scuss if this is something useful that fits under the TRAM charter. .-. P=E5l-Erik _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_F08F11F333F34D06B58631ECE4B920C3ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3A05DD1CEE47BF479D3731A92C209EAB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Oleg,

That was an impressive quick read. Thanks for the interest.

On 12 Feb 2014, at 10:10 am, Oleg Moskalenko <mom040267@gmail.com> wrote:

Question (or comment) on Section 6.3:

Can the application be behind a NAT ? Can a NAT be involved ?
Yes. That is the beauty of in-band STUN signalling.

If yes, then all applications behind that NAT may have the same IP add= ress, from the STUN message receiver point of view. Then how the Session ID= and the priority works in such a case ?

It wont. Unless we come up with something clever..

So the problem is if that you have a system that produces  a main= video stream from one IP and a presentation video stream from another IP? = You would like the network to know that you care more about the main video,= and if problems occur it should preferably drop packets from the presentation stream. And this should be up to the ap= plication to choose, in another situation it might be the presentation vide= o stream that is the most important (It might dynamically change during the= conference as well).

The main rationale for limiting it to the IP address was to reduce the= incentive to lie about the priorities. It does not get you better bandwidt= h, it just tells the network what to which of your own packets to drop if t= here is a problem. It might be worth having a stronger id to allow us to loosen the IP address requirements.

What I am afraid of is to open up for cross application priorities. Th= at is a rathole I would like to avoid for now. 

.-.
P=E5l-Erik


Oleg





On Wed, Feb 12, 2014 at 12:51 AM, Pal Martinsen = (palmarti) <palmarti@cisco.com> wrote:

Hi Tramsters,

We published a draft today describing extensions to STUN that enables simpl= e communication between the endpoint and the network.


Name:           draft-martinsen-tram-discuss
Revision:       00
Title:          Differentiated prIorities and Stat= us Code-points Using Stun Signalling (DISCUSS)
Document date:  2014-02-12
Group:          Individual Submission
Pages:          13
URL:            ht= tp://www.ietf.org/internet-drafts/draft-martinsen-tram-discuss-00.txt Status:         https://datatracker.ietf.org/doc/draft-martinsen-tram-discuss/
Htmlized:       http://tools.ietf.org/html/draft-martinsen-tram-discuss-00


The main goals for now:

 - Make it easy for an application to communicate its intent to the ne= twork (QoE) without needing access to the lower layers of the IP stack. Sen= ding a STUN packet would be an easy solution for the application.
- Make it easy for the network to process information from the endpoint. ST= UN have nice characteristics that makes it easy for network elements to pic= k it up.
- Create a tightly defined set of STUN attributes that does not leak unnece= ssary information.

To describe the draft using established mechanisms; think of it as extended= DSCP markings with ECN capabilities sent in-band using STUN.

I realize the TRAM agenda is packet, but hopefully we would fine time to di= scuss if this is something useful that fits under the TRAM charter.

.-.
P=E5l-Erik

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--_000_F08F11F333F34D06B58631ECE4B920C3ciscocom_-- From praspati@cisco.com Wed Feb 12 04:40:32 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1739B1A090C for ; Wed, 12 Feb 2014 04:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Pqe0S33kTJab for ; Wed, 12 Feb 2014 04:40:30 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE301A0980 for ; Wed, 12 Feb 2014 04:40:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=604; q=dns/txt; s=iport; t=1392208829; x=1393418429; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wOJTqruISXoztxZxlPyoJJA5QPQrnCqqYFWa3Oz3QMs=; b=FD0dqnq0OXPUlIK3MaV9s7VPr6prdvYLl2Bw1ujQfWhKGjD8hOjuiN3E b0NM/WqbTD4p0NBIkJUkR4wgwjieREaU5mBVAwWae4Uld/ueyEimXxAjI tRaxx5xQEuYtDZwtA0z9f21qJ37XjFz+RAKAu/uTPS8/ARd9nSqHk7rTM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFACdr+1KtJXHA/2dsb2JhbABaDoJ+OFe/KIERFnSCJQEBAQMBAQEBNzQbAgEIDigQJwslAgQBEod9CA3IeRePAIQ4BJgqkiGCbj+CKg X-IronPort-AV: E=Sophos;i="4.95,832,1384300800"; d="scan'208";a="19841584" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-6.cisco.com with ESMTP; 12 Feb 2014 12:40:29 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1CCeTA8018140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Feb 2014 12:40:29 GMT Received: from xmb-rcd-x07.cisco.com ([169.254.7.211]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 06:40:29 -0600 From: "Prashanth Patil (praspati)" To: Paul Kyzivat , "tram@ietf.org" Thread-Topic: [tram] Suggestion for draft-patil-tram-turn-serv-disc-00 Thread-Index: AQHPJ++cn7Fd3ZBWdEuHZb+5zMNNUA== Date: Wed, 12 Feb 2014 12:40:28 +0000 Message-ID: References: <52FA58B3.60005@alum.mit.edu> In-Reply-To: <52FA58B3.60005@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [72.163.206.113] Content-Type: text/plain; charset="us-ascii" Content-ID: <0A06D7B129DD224995F73F1BC39DA9CD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tram] Suggestion for draft-patil-tram-turn-serv-disc-00 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 12:40:32 -0000 On 2/11/14 10:36 PM, "Paul Kyzivat" wrote: >IMO there is another variant on Service Resolution: > >A target domain that wants to make itself more reachable could advertise >a TURN server via NAPTR on its domain name. > >So a caller of sip:foo@bar.com could use bar.com as one of the >"retrieved domain names" that are candidates for resolution. Yes, this could be a variant as well. Thanks, Prashanth > > Thanks, > Paul > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From juberti@google.com Wed Feb 12 09:46:44 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FB01A09B9 for ; Wed, 12 Feb 2014 09:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 zRJzHIL_fkjH for ; Wed, 12 Feb 2014 09:46:36 -0800 (PST) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEEA1A0695 for ; Wed, 12 Feb 2014 09:46:33 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id h16so11373755oag.10 for ; Wed, 12 Feb 2014 09:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dS2k40GkHQB8o4ilVCm73ZY58z+RxIQjkFF9zMiNBMw=; b=VEF7ZNNHQHDno9Mov7HReqGl+vBrLMwmhm7dWA1TsO18rrp6dFInuPGR/J4o9AVClV PwwSqhjTTTZY0G1Q5pLMgzS2dhRSDRtDzK41Dqh2ZbEL21raQEg/6FxsvgKP9nSFanIl M5Cd/LJVqZdSbMpjQcl/Mh9Wzq5mZldphpkyRvhZ7V39r0GNtRTUEgR4rBGg/mcoH+ze 1gVsp8VPuHSq7n83YhEC0F5OnF0fwCgmBWOc/WslasTQmEDo7w1H9EyhLVViuT3Y1qu6 HmPKrPB/fc7ChzcRx6C3OhrFZCu0l7nEQx7k4Iq2AE7oJYX7a1mz87Taef08Ro1fryxB 8Xxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=dS2k40GkHQB8o4ilVCm73ZY58z+RxIQjkFF9zMiNBMw=; b=BzIef3NrdO5rlUBhIlDXmFqY9aIArwxKIjdQJvROUxZdc5FOnt/aCnI+eTa6zUjYMS RedjlqRb8O7Z7kVHBV8BynJckG3d8b8YqZGrLynk1etyF1rVjN+djdFEu8s7W/zZ6TD1 u+Qb5EFyyg+Gc0ZMD9DG9oj5NMXz081o9jLHrHIpouq4OAw8pDSjl7/TYwufrq4Sct7V S33IaORZ433mFYaKx0Ry1uvk73Q2LDnl6iOtb0xCH5TVxZlo652iTSxF/7dPylZHdKzx xPoVSCF7iGuL7fTTpK7uqwTkm2Yj7QdB3sjElisMAgxeutDPsNjuFbh0Dc4RSk0XON0g yxpA== X-Gm-Message-State: ALoCoQmOTaJdGmjoRT/9eCnmmR4XLfDahqyDvA2lh7Wx6irDljJAGfgdFAvrIsmOnIQKz1tfk9iQyGCXRz5yKsfWLbOFbsqzCYSFkIPFHiImTy3ngHQ5Fl3e+RQxg/NFA42RRKRiZJR9lF4TmDRMrWvsB7GghCw5KymPrtwUfNsEaJvhrVPnWtmCJauHKSBkNHf6LxhyaIfL X-Received: by 10.60.231.194 with SMTP id ti2mr13667614oec.41.1392227192424; Wed, 12 Feb 2014 09:46:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.96.230 with HTTP; Wed, 12 Feb 2014 09:46:11 -0800 (PST) In-Reply-To: References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> From: Justin Uberti Date: Wed, 12 Feb 2014 09:46:11 -0800 Message-ID: To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: multipart/alternative; boundary=001a1136865840711104f23927d4 Cc: "tireddy@icisco.com" , Simon Perreault , Oleg Moskalenko , "tram@ietf.org" , Marc Blanchet , "Dan Wing \(dwing\)" , Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 17:46:44 -0000 --001a1136865840711104f23927d4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree. If TURN is indeed being provided for the user's benefit, the client's ICE logic (based on RTT or similar) should result in it preferring the TURN path. On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: > Yes, I believe the second case is rare, but would be better than a rat > race b/w administrators trying to block p2p traffic and force it through = a > TURN server and apps/endpoints finding smarter ways to bypass them. > > > > Muthu > > > > *From:* Oleg Moskalenko [mailto:mom040267@gmail.com] > *Sent:* Wednesday, February 12, 2014 1:07 PM > *To:* Muthu Arul Mozhi Perumal (mperumal) > *Cc:* Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; > tram@ietf.org; Dan Wing (dwing); Simon Perreault > > *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism > for enterprise and ISPs > > > > The TURN server has to be used when it is either the only option, or if i= t > provides a better path (I guess the second case is rather rare). > > > > On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) < > mperumal@cisco.com> wrote: > > +1 > > > > Forcing all traffic through a TURN server and expecting it would provide > the best user experience doesn't look the right approach. Instead, if a > path through a TURN server exists and does provide lower RTT, jitter etc, > being able to detect and use (or switch to) that path might be desirable.= . > > > > Muthu > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Wednesday, February 12, 2014 11:43 AM > *To:* Karl Stahl > *Cc:* tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); > Simon Perreault > *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism > for enterprise and ISPs > > > > Inline. > > > > On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl > wrote: > > Listening to this thread, I am afraid we are missing the very point and > necessity for this milestone! > > - There are severe NAT traversal and quality issues that should and can b= e > dealt with by a good auto-discovery mechanism and the right usage by the > turn client (the WebRTC browser) > > > > There are ways, not only: Enterprises or ISPs wishing to provide their > own TURN server, in an attempt to reduce so-called "triangle routing",nee= d > a new auto-discovery mechanism > > But also: - NSPs (Network Service Providers) want to provide a path where > the bandwidth of WebRTC is better coped with. > > - NSPs or Enterprises want to offer an Internet access quality pipe for > prioritized RTC (Real Time Communication) traffic. > > - Enterprises having restrictive firewalls, want to provide a UDP-path fo= r > WebRTC and possibly also for better quality where RTC do not compete with > data traffic. > > Also considering > > - Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4= G > OTT channels, all should be able to automatically offer their own optimal > TURN server > > > > This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80= =9D etc! It is not a > mistake, but the very need for this milestone! > > > > Again, it has not been demonstrated why TURN is the right technology here= , > compared to a more transparent flow identification tool like MALICE. We > don't force all HTTP requests to locate a HTTP proxy via anycast, I don't > see why we need to do the same for WebRTC. > > > > What are the hesitations raised here? > > > TURN primarily to identify WebRTC flows, as opposed to using it as a NA= T > traversal tool. This makes me concerned that we may be using the wrong > technology to solve the problem > > It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall > traversal problem associated with real-time communication (SIP at that > time). However, its largest flaw/problem is that quality things were not > (could not be?) considered. The method=E2=80=99s very idea (like all simi= lar > methods for getting RTC through ordinary NAT/Firewalls) is to fool the > media through a NAT/Firewall that is unaware of what is happening. Thus, > this is root of quality issues (and bandwidth allocation optimization) th= at > needs to be dealt with: Real-time traffic fighting with a data traffic > crowded congestion point. > > > > I think that "fooling" is an incorrect description. The NAT is supposed t= o > be transparent to the client. > > > > But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate > request for a suitable pipe for quality demanding real time traffic. J > > ICE is a pre-protocol you use because you want a path for real-time media > between parties. Here: The browser says knock knock, I want to get media > through (and of course with as good quality as required and possible). > > > > If the NAT/Firewall owner and network owner are allowed to see these > requests, they can help/assist in achieving the good media path. If they > are not aware, they cannot help! > > > > Hope this made it understandable on an overview level how this can become= =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D > > It is also the ONLY way I can see to achieve what we want to achieve and > should be the aim and requirement of this milestone. > > > > I am talking about general usage of WebRTC over Internet/mobile OTT (not > feeding WebRTC into application specific networks like IMS where other > methods may exist). > > > > This is good, not evil! > > > > If the hesitations are raised because of a belief/hope/wish that there ar= e > no or will not be severe quality issues =E2=80=9Cbecause it is all about > bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D et= c., I strongly object! > That is wrong and will be very detrimental for WebRTC usage. We already s= ee > it and I can give numerous examples of how much less quality demanding Vo= IP > is/is not handled quality wise and that it matters. And, what would be ba= d > considering quality issues and allowing/encouraging methods to deal with > them? > > > > If the hesitations are raised, because of suspicion that the methods we > may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to > protect income from carrier telephony traffic), I could understand and > would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At > least forward thinking carrier=E2=80=99s realize that already. Web RTC wi= ll happen. > Which customers want to pay for an access with blocked WebRTC? The > carrier=E2=80=99s offering/assuring good WebRTC will rather get the custo= mers and > income J. (Maybe the Web browser can detect and encourage this=E2=80=A6) > > > > If there are technical concerns of bad result, or better methods allowing > network providers and LAN managers to offer and inform the browser that > there are good media paths to be used, and that the web browser > automatically can chose those, then let us all understand those, so we ca= n > achieve what should be achieved by this milestone. > > > > Skype, Hangouts, Facetime are doing billions of minutes per week and the > Internet has not melted yet. If we need to do flow identification to allo= w > traffic to be prioritized, fine (see above regarding my preferred > approach), but forcing all WebRTC traffic through a MITM (TURN server) is= a > much bigger jump that I don't yet see the justification for. > > > > In short: TURN is a technology that is supposed to fade away with the mov= e > to IPv6. I don't think we want to make it a critical element of WebRTC. > > > > /Karl > > > > > > *Fr=C3=A5n:* Dan Wing [mailto:dwing@cisco.com] > *Skickat:* den 11 februari 2014 18:25 > *Till:* Marc Blanchet > *Kopia:* Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; > Simon Perreault > > > *=C3=84mne:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism= for > enterprise and ISPs > > > > > > On Feb 11, 2014, at 9:08 AM, Marc Blanchet > wrote: > > > > Le 2014-02-11 =C3=A0 00:39, Dan Wing a =C3=A9crit : > > > > > On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: > > > > Good to see there is a lot of interest for this milestone. But based on > the description here, it seems like we want to use TURN primarily to > identify WebRTC flows, as opposed to using it as a NAT traversal tool. Th= is > makes me concerned that we may be using the wrong technology to solve the > problem. > > > > +1. > > > > I would prefer allowing flows to establish themselves using their 'best' > path, and the best path is seldom through a TURN server. When we imagine > IPv6 in our future, we don't want to force an application-level proxy > (TURN) server on the path solely for traversing an IPv6 firewall. > > > > > > It seems this thread is conflating all the possible reasons / > justifications for TURN: > > * mobility > > * NAT traversal (both endpoints are behind endpoint-dependent mapping > NATs) > > * firewall traversal (firewall blocks UDP) > > * enhancing privacy > > > > Unfortunately the TURN server nor the endpoint really know which of those > use-cases is desired (by the user or by the IT network administrator) or > necessary (for the call to work at all). > > > > Dan, while I agree in principle, I doubt that a user could ever say "I > want mobility or I want NAT traversal". I think the user only want the ca= ll > to succeed, whatever the properties of its network point of attachment ar= e. > > > > So what can we do? Should the TURN server provide any and all services > the TURN client might possibly want, as that is what a robust TURN server > will do, and the endpoint should prefer TURN candidates over all others > because there might be some functionality / usefulness of TURN that the > user might gain through TURN (e.g., enhanced privacy)? > > > > -d > > > > > > > > This seems problematic. Perhaps we need a way to signal the desired > use-case ("trait"), or as Justin suggests, using a different technology f= or > some of these use-cases. > > > > -d > > > > > > > > > > On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl > wrote: > > Simon, > > Good questions - see inline below --> . > Some more thought is required! > > /Karl > > -----Ursprungligt meddelande----- > Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault > Skickat: den 10 februari 2014 15:16 > Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com > =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism f= or > enterprise and ISPs > > > Karl, > > It is great to see such enthusiasm! Thanks! > > I have a couple technical questions... > > Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > > - Note that to achieve some of the above points, TURN must be favored > > over STUN to enforce that the TURN-path actually is used. (The Anycast > > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) > > I understand the STUN vs TURN priority issue. But I don't see how anycast > affects it in any way. Can you please explain? > > --- Good point - I was a bit quick here (maybe too quick) > We have given this quite bit of thought, since even if a TURN server is > provided and discovered, CURRENT usage of ICE may suggest a candidate fro= m > the remote party that will make a connection without the need/usage of th= e > TURN server (that we wanted to be used for the good purposes listed). > > The only way we found around this, was to stop STUN through the IP defaul= t > gateway (like a restrictive Enterprise firewall does inhibiting ICE > connectivity, which others are concerned about...). Since the provisionin= g > of auto-discovery using the anycast mechanism, would be adding a route in= a > default gateway, adding a firewall rule to eat STUN packets would assure > that the provisioned TURN server actually becomes used (and not bypassed > "by accident"). (That was the thought behind the =E2=80=9Cautomatically= =E2=80=9D within > quotes.) > > BUT, since you brought up the question, assuming that we have the power t= o > enforce WebRTC usage of ICE, I believe a MUST requirement to use an > auto-discovered TURN server instead of STUN, would solve the same problem= . > However, thinking further (in relation to your next question - "anyone > could set up a badly-maintained" - enforcing such ICE usage may not be > good.) > > > > > - 3^rd The Anycast method below =E2=80=93 I see no problem > > > > It also has the advantage of encouraging (but not requiring) the > > STUN/TURN to be built in the default gateway or NAT/firewall/access > > router itself, with a second interface to a public IP address on the > > WAN side. (Current volume deployed, low cost NSP triple play modems > > usually have a quality assured level 2 or level 3 WAN pipe for just > > voice (and another for IPTV) =E2=80=93 The anycast discovered TURN-serv= er can > > be the access gateway to such quality pipe for WebRTC media, in a > > single NSP provided CPE, scaling from residential and up.) > > Suppose we define well-known anycast TURN server addresses. How would thi= s > not be subject to the same service quality issues that plagued 6to4? That > is, anyone could set up a badly-maintained, under-provisioned TURN server > and announce it over BGP to the world, as it was done for > 6to4 relays. Or just bad BGP outbound filter configuration. And how can w= e > prevent triangle routing? There is nothing guaranteeing that the anycast > server you see is being provided to you by your ISP, rather than a server > sitting on the other side of the planet. > > --- Good point - needs to be resolved. For this I don't have a ready > answer... > An auto-discovered TURN server must be trusted (whatever method it is > discovered by). We are trusting the one providing us with an IP address a= nd > default gateway anyway. It would be easy if we could reuse that trust, > instead of another mechanisms. > > Is there a good way for the browser to check that the anycast address is > not handled beyond the network service provider's default gateway? Ideas? > > > > > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > --001a1136865840711104f23927d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree. If TURN is indeed being provided for the user's= benefit, the client's ICE logic (based on RTT or similar) should resul= t in it preferring the TURN path.


<= div class=3D"gmail_quote"> On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) <mpe= rumal@cisco.com> wrote:

Yes, I believe the second case is rare, but would be bette= r than a rat race b/w administrators trying to block p2p traffic and force = it through a TURN server and apps/endpoints finding smarter ways to bypass them.

=C2=A0

Muthu

=C2=A0

From: Oleg Mos= kalenko [mailto:mo= m040267@gmail.com]
Sent: Wednesday, February 12, 2014 1:07 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simo= n Perreault


Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

=C2=A0

The TURN server has to be used when it is either the= only option, or if it provides a better path (I guess the second case is r= ather rare).

=C2=A0<= /p>

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi P= erumal (mperumal) <mperumal@cisco.com> wrote:

+1

=C2=A0

Forcing all traffic through a TURN server and expecting it= would provide the best user experience doesn't look the right approach. Instead, if a path through a TURN server exists and does provide= lower RTT, jitter etc, being able to detect and use (or switch to) that pa= th might be desirable..

=C2=A0

Muthu

=C2=A0

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl
Cc: tireddy@= icisco.com; Marc Blanchet; tram@ietf.org; Dan W= ing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

=C2=A0

Inline.

=C2=A0

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex= .se> wrote:

Listening to this thread, I am= afraid we are missing the very point and necessity for this milestone!

- There are severe NAT travers= al and quality issues that should and can be dealt with by a good auto-disc= overy mechanism and the right usage by the turn client (the WebRTC browser)

=C2=A0

There are ways, not only: Enterprises or ISPs wishing to provide their own TURN server, in an attemp= t to reduce so-called "triangle routing",need a new auto-discover= y mechanism

But also: - NSPs (Network Serv= ice Providers) want to provide a path where the bandwidth of WebRTC is bett= er coped with.

- NSPs or Enterprises want to = offer an Internet access quality pipe for prioritized RTC (Real Time Commun= ication) traffic.

- Enterprises having restricti= ve firewalls, want to provide a UDP-path for WebRTC and possibly also for better quality where RTC do not compete with data traffic. <= u>

Also considering=

- Mobility; It is common to mo= ve from a LAN to accessing via WiFi or 3G/4G OTT channels, all should be able to automatically offer their own optimal TURN server=

=C2=A0

This leads us into =C2=A0=E2=80=9CTURN=E2=80=A6to identify WebRTC flows= =E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

=C2=A0

Again, it has not been demonstrated why TURN is the = right technology here, compared to a more transparent flow identification t= ool like MALICE. We don't force all HTTP requests to locate a HTTP proxy via anycast, I don't see why we need to do the = same for WebRTC.=C2=A0

=C2=A0

What are the hesitations raise= d here?

> TURN primarily to identify WebRTC= flows, as opposed to using it as a NAT traversal tool. This makes me conce= rned that we may be using the wrong technology to solve the problem

It is correct that ICE/STUN/TU= RN was designed to address the NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw= /problem is that quality things were not (could not be?) considered. The me= thod=E2=80=99s very idea (like all similar methods for getting RTC through = ordinary NAT/Firewalls) is to fool the media through a NAT/Firewall that is unaware of what is happening. Thus, this is= root of quality issues (and bandwidth allocation optimization) that needs = to be dealt with: Real-time traffic fighting with a data traffic crowded co= ngestion point.

=C2=A0

I think that "fooling" is an incorrect des= cription. The NAT is supposed to be transparent to the client.

=C2=A0

But, a BLESSING of ICE/STUN/TU= RN is that it can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. J

ICE is a pre-protocol you use = because you want a path for real-time media between parties. Here: The brow= ser says knock knock, I want to get media through (and of course with as good = quality as required and possible).

=C2=A0

If the NAT/Firewall owner and = network owner are allowed to see these requests, they can help/assist in achieving the good media path. If they are not aware, they cannot help!

=C2=A0

Hope this made it understandab= le on an overview level how this can become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D

It is also the ONLY way I can = see to achieve what we want to achieve and should be the aim and requiremen= t of this milestone.

=C2=A0

I am talking about general usa= ge of WebRTC over Internet/mobile OTT (not feeding WebRTC into application specific networks like IMS where other methods may exist). <= u>

=C2=A0

This is good, not evil!=

=C2=A0

If the hesitations are raised = because of a belief/hope/wish that there are no or will not be severe quali= ty issues =E2=80=9Cbecause it is all about bandwidth=E2=80=9D, =E2=80=9Cit wi= ll resolve itself with time=E2=80=9D etc., I strongly object! That is wrong= and will be very detrimental for WebRTC usage. We already see it and I can= give numerous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad= considering quality issues and allowing/encouraging methods to deal with t= hem?

=C2=A0

If the hesitations are raised,= because of suspicion that the methods we may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to protect income from carrier telep= hony traffic), I could understand and would fight the same battle. But hope= fully, those days are (soon) over =E2=80=93 At least forward thinking carri= er=E2=80=99s realize that already. Web RTC will happen. Which customers want to pay for an access with blocked WebRTC? The= carrier=E2=80=99s offering/assuring good WebRTC will rather get the custom= ers and income J<= /span>. (Maybe the Web browser can detect and encoura= ge this=E2=80=A6)=C2=A0

=C2=A0

If there are technical concern= s of bad result, or better methods allowing network providers and LAN manag= ers to offer and inform the browser that there are good media paths to be used= , and that the web browser automatically can chose those, then let us all u= nderstand those, so we can achieve what should be achieved by this mileston= e.

=C2=A0

Skype, Hangouts, Facetime are doing billions of minu= tes per week and the Internet has not melted yet. If we need to do flow ide= ntification to allow traffic to be prioritized, fine (see above regarding my preferred approach), but forcing all WebRTC traffi= c through a MITM (TURN server) is a much bigger jump that I don't yet s= ee the justification for.

=C2=A0

In short: TURN is a technology that is supposed to f= ade away with the move to IPv6. I don't think we want to make it a crit= ical element of WebRTC.

=C2=A0

/Karl

=C2=A0

=C2=A0

Fr=C3=A5n: Dan= Wing [mailto:dwing@ci= sco.com]
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon Perreault


=C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechan= ism for enterprise and ISPs

=C2=A0

=C2=A0

On Feb 11, 2014, at 9:08 AM, Marc = Blanchet <marc.blanchet@viagenie.ca> wrote:

=C2= =A0

Le 2014-02-11 =C3=A0 00:39, Dan Wi= ng <dwing@cisco.com= > a =C3=A9crit :

=C2= =A0


On Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> wrote:=

=C2= =A0

Good to see there is a lot= of interest for this milestone. But based on the description here, it seem= s like we want to use TURN primarily to identify WebRTC flows, as opposed to= using it as a NAT traversal tool. This makes me concerned that we may be u= sing the wrong technology to solve the problem.

=C2=A0

+1.

=C2=A0

I would prefer allowing fl= ows to establish themselves using their 'best' path, and the best p= ath is seldom through a TURN server. =C2=A0When we imagine IPv6 in our future, we= don't want to force an application-level proxy (TURN) server on the pa= th solely for traversing an IPv6 firewall.

=C2=A0

=C2=A0

It seems this thread is co= nflating all the possible reasons / justifications for TURN:<= u>

=C2=A0 * mobility

=C2=A0 * NAT traversal (bo= th endpoints are behind endpoint-dependent mapping NATs)

=C2=A0 *=C2=A0firewall tra= versal (firewall blocks UDP)

=C2=A0 * enhancing privacy=

=C2=A0

Unfortunately the TURN ser= ver nor the endpoint really know which of those use-cases is desired (by th= e user or by the IT network administrator) or necessary (for the call to wor= k at all).

=C2=A0

Dan, while I agree in principle, I= doubt that a user could ever say "I want mobility or I want NAT trave= rsal". I think the user only want the call to succeed, whatever the properties of its network point of attachment are.

=C2=A0

So what can we do? =C2=A0Should th= e TURN server provide any and all services the TURN client might possibly w= ant, as that is what a robust TURN server will do, and the endpoint should prefer TURN candidates over all others because there might= be some functionality / usefulness of TURN that the user might gain throug= h TURN (e.g., enhanced privacy)?

=C2=A0

-d

=C2=A0

=C2=A0

=C2= =A0

=C2=A0This seems problemat= ic. =C2=A0Perhaps we need a way to signal the desired use-case ("trait= "), or as Justin suggests, using a different technology for some of these use-cases.=

=C2=A0

-d

=C2=A0

=C2=A0

=C2= =A0

=C2=A0

On Mon, Feb 10, 2014 at 3:= 18 PM, Karl Stahl=C2=A0<karl.stahl@intertex.se>=C2=A0wrote:=

Simon,

Good questions - see inline below --> .
Some more thought is required!

/Karl

-----Ursprungligt meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl;=C2=A0t= ram@ietf.org;=C2=A0tireddy@icisco.com
=C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for= enterprise and ISPs


Karl,

It is great to see such enthusiasm! Thanks!

I have a couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit :
> - Note that to achieve some of the above points, TURN must be favored<= br> > over STUN to enforce that the TURN-path actually is used. (The Anycast=
> method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.)
I understand the STUN vs TURN priority issue. But I don't see how anyca= st affects it in any way. Can you please explain?

--- Good point - I was a b= it quick here (maybe too quick)
We have given this quite bit of thought, since even if a TURN server is pro= vided and discovered, CURRENT usage of ICE may suggest a candidate from the= remote party that will make a connection without the need/usage of the TUR= N server (that we wanted to be used for the good purposes listed).

The only way we found around this, was to stop STUN through the IP default = gateway (like a restrictive Enterprise firewall does inhibiting ICE connect= ivity, which others are concerned about...). Since the provisioning of auto= -discovery using the anycast mechanism, would be adding a route in a default gateway, adding a firewall rule to ea= t STUN packets would assure that the provisioned TURN server actually becom= es used (and not bypassed "by accident"). (That was the thought b= ehind the =E2=80=9Cautomatically=E2=80=9D within quotes.)

BUT, since you brought up the question, assuming that we have the power to = enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-di= scovered TURN server instead of STUN, would solve the same problem. However= , thinking further (in relation to your next question - "anyone could set up a badly-maintained"= - enforcing such ICE usage may not be good.)



> - 3^rd The Anycast method below =E2=80=93 I see no problem
>
> It also has the advantage of encouraging (but not requiring) the
> STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered TURN-ser= ver can
> be the access gateway to such quality pipe for WebRTC media, in a
> single NSP provided CPE, scaling from residential and up.)

Suppose we define well-known anycast TURN server addresses. How would this = not be subject to the same service quality issues that plagued 6to4? That i= s, anyone could set up a badly-maintained, under-provisioned TURN server an= d announce it over BGP to the world, as it was done for
6to4 relays. Or just bad BGP outbound filter configuration. And how can we = prevent triangle routing? There is nothing guaranteeing that the anycast se= rver you see is being provided to you by your ISP, rather than a server sit= ting on the other side of the planet.

--- Good point - needs to = be resolved. For this I don't have a ready answer...
An auto-discovered TURN server must be trusted (whatever method it is disco= vered by). We are trusting the one providing us with an IP address and defa= ult gateway anyway. It would be easy if we could reuse that trust, instead = of another mechanisms.

Is there a good way for the browser to check that the anycast address is no= t handled beyond the network service provider's default gateway? Ideas?=




Thanks,
Simon
--
DTN made easy, lean, and smart -->=C2=A0http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0-->=C2=A0http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -->=C2= =A0http://numb.viage= nie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

=C2=A0

__________________________= _____________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


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

=C2=A0

=C2=A0

=C2=A0


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

=C2=A0


--001a1136865840711104f23927d4-- From andrew.hutton@unify.com Wed Feb 12 11:30:16 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65851A0631 for ; Wed, 12 Feb 2014 11:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 4rsjvFMm32GE for ; Wed, 12 Feb 2014 11:30:11 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 29DFB1A062C for ; Wed, 12 Feb 2014 11:30:10 -0800 (PST) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 74E8C1EB87B0; Wed, 12 Feb 2014 20:30:08 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.100]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0174.001; Wed, 12 Feb 2014 20:30:08 +0100 From: "Hutton, Andrew" To: Justin Uberti , "Muthu Arul Mozhi Perumal (mperumal)" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPKCjWFphKtERXaUGRovqHSSrR3g== Date: Wed, 12 Feb 2014 19:30:07 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17CF2EDD@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17CF2EDDMCHP04MSXglobal_" MIME-Version: 1.0 Cc: "tireddy@icisco.com" , Simon Perreault , Oleg Moskalenko , "tram@ietf.org" , Marc Blanchet , "Dan Wing \(dwing\)" , Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 19:30:17 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17CF2EDDMCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNhc2Ugd2hlcmUgdGhlIFRVUk4gc2VydmVyIGlzIHRoZSBvbmx5IG9wdGlvbiBtYXkgYmVj b21lIGNvbW1vbiB3aXRoaW4gZW50ZXJwcmlzZSBuZXR3b3JrcyBhbmQgdGhhdCBtaWdodCBiZSBk ZWxpYmVyYXRlIGVudGVycHJpc2UgcG9saWN5IGJlY2F1c2UgaXQgcHJvdmlkZXMgdGhlIGJldHRl ciBwYXRoIChVRFAgdGhyb3VnaCB0aGUgRi9XKSBhbmQgcHJvdGVjdHMgdGhlIHVzZXJzIGFuZCB0 aGUgbmV0d29yay4NCg0KQW5keQ0KDQoNCkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiAxMiBGZWJydWFyeSAy MDE0IDE3OjQ2DQpUbzogTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkNCkNjOiB0 aXJlZGR5QGljaXNjby5jb207IFNpbW9uIFBlcnJlYXVsdDsgT2xlZyBNb3NrYWxlbmtvOyB0cmFt QGlldGYub3JnOyBNYXJjIEJsYW5jaGV0OyBEYW4gV2luZyAoZHdpbmcpOyBLYXJsIFN0YWhsDQpT dWJqZWN0OiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVy eSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KQWdyZWUuIElmIFRVUk4gaXMg aW5kZWVkIGJlaW5nIHByb3ZpZGVkIGZvciB0aGUgdXNlcidzIGJlbmVmaXQsIHRoZSBjbGllbnQn cyBJQ0UgbG9naWMgKGJhc2VkIG9uIFJUVCBvciBzaW1pbGFyKSBzaG91bGQgcmVzdWx0IGluIGl0 IHByZWZlcnJpbmcgdGhlIFRVUk4gcGF0aC4NCg0KT24gV2VkLCBGZWIgMTIsIDIwMTQgYXQgMToy NyBBTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgPG1wZXJ1bWFsQGNpc2Nv LmNvbTxtYWlsdG86bXBlcnVtYWxAY2lzY28uY29tPj4gd3JvdGU6DQpZZXMsIEkgYmVsaWV2ZSB0 aGUgc2Vjb25kIGNhc2UgaXMgcmFyZSwgYnV0IHdvdWxkIGJlIGJldHRlciB0aGFuIGEgcmF0IHJh Y2UgYi93IGFkbWluaXN0cmF0b3JzIHRyeWluZyB0byBibG9jayBwMnAgdHJhZmZpYyBhbmQgZm9y Y2UgaXQgdGhyb3VnaCBhIFRVUk4gc2VydmVyIGFuZCBhcHBzL2VuZHBvaW50cyBmaW5kaW5nIHNt YXJ0ZXIgd2F5cyB0byBieXBhc3MgdGhlbS4NCg0KTXV0aHUNCg0KRnJvbTogT2xlZyBNb3NrYWxl bmtvIFttYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbTxtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNv bT5dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0IDE6MDcgUE0NClRvOiBNdXRo dSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KQ2M6IEp1c3RpbiBVYmVydGk7IEthcmwg U3RhaGw7IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tPjsgTWFy YyBCbGFuY2hldDsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IERhbiBXaW5n IChkd2luZyk7IFNpbW9uIFBlcnJlYXVsdA0KDQpTdWJqZWN0OiBSZTogW3RyYW1dIE1pbGVzdG9u ZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2Ug YW5kIElTUHMNCg0KVGhlIFRVUk4gc2VydmVyIGhhcyB0byBiZSB1c2VkIHdoZW4gaXQgaXMgZWl0 aGVyIHRoZSBvbmx5IG9wdGlvbiwgb3IgaWYgaXQgcHJvdmlkZXMgYSBiZXR0ZXIgcGF0aCAoSSBn dWVzcyB0aGUgc2Vjb25kIGNhc2UgaXMgcmF0aGVyIHJhcmUpLg0KDQpPbiBUdWUsIEZlYiAxMSwg MjAxNCBhdCAxMTozMiBQTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgPG1w ZXJ1bWFsQGNpc2NvLmNvbTxtYWlsdG86bXBlcnVtYWxAY2lzY28uY29tPj4gd3JvdGU6DQorMQ0K DQpGb3JjaW5nIGFsbCB0cmFmZmljIHRocm91Z2ggYSBUVVJOIHNlcnZlciBhbmQgZXhwZWN0aW5n IGl0IHdvdWxkIHByb3ZpZGUgdGhlIGJlc3QgdXNlciBleHBlcmllbmNlIGRvZXNuJ3QgbG9vayB0 aGUgcmlnaHQgYXBwcm9hY2guIEluc3RlYWQsIGlmIGEgcGF0aCB0aHJvdWdoIGEgVFVSTiBzZXJ2 ZXIgZXhpc3RzIGFuZCBkb2VzIHByb3ZpZGUgbG93ZXIgUlRULCBqaXR0ZXIgZXRjLCBiZWluZyBh YmxlIHRvIGRldGVjdCBhbmQgdXNlIChvciBzd2l0Y2ggdG8pIHRoYXQgcGF0aCBtaWdodCBiZSBk ZXNpcmFibGUuLg0KDQpNdXRodQ0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGll dGYub3JnPG1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSnVzdGlu IFViZXJ0aQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAxNCAxMTo0MyBBTQ0KVG86 IEthcmwgU3RhaGwNCkNjOiB0aXJlZGR5QGljaXNjby5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2Nv LmNvbT47IE1hcmMgQmxhbmNoZXQ7IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+ OyBEYW4gV2luZyAoZHdpbmcpOyBTaW1vbiBQZXJyZWF1bHQNClN1YmplY3Q6IFJlOiBbdHJhbV0g TWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50 ZXJwcmlzZSBhbmQgSVNQcw0KDQpJbmxpbmUuDQoNCk9uIFR1ZSwgRmViIDExLCAyMDE0IGF0IDI6 MzcgUE0sIEthcmwgU3RhaGwgPGthcmwuc3RhaGxAaW50ZXJ0ZXguc2U8bWFpbHRvOmthcmwuc3Rh aGxAaW50ZXJ0ZXguc2U+PiB3cm90ZToNCkxpc3RlbmluZyB0byB0aGlzIHRocmVhZCwgSSBhbSBh ZnJhaWQgd2UgYXJlIG1pc3NpbmcgdGhlIHZlcnkgcG9pbnQgYW5kIG5lY2Vzc2l0eSBmb3IgdGhp cyBtaWxlc3RvbmUhDQotIFRoZXJlIGFyZSBzZXZlcmUgTkFUIHRyYXZlcnNhbCBhbmQgcXVhbGl0 eSBpc3N1ZXMgdGhhdCBzaG91bGQgYW5kIGNhbiBiZSBkZWFsdCB3aXRoIGJ5IGEgZ29vZCBhdXRv LWRpc2NvdmVyeSBtZWNoYW5pc20gYW5kIHRoZSByaWdodCB1c2FnZSBieSB0aGUgdHVybiBjbGll bnQgKHRoZSBXZWJSVEMgYnJvd3NlcikNCg0KVGhlcmUgYXJlIHdheXMsIG5vdCBvbmx5OiBFbnRl cnByaXNlcyBvciBJU1BzIHdpc2hpbmcgdG8gcHJvdmlkZSB0aGVpciBvd24gVFVSTiBzZXJ2ZXIs IGluIGFuIGF0dGVtcHQgdG8gcmVkdWNlIHNvLWNhbGxlZCAidHJpYW5nbGUgcm91dGluZyIsbmVl ZCBhIG5ldyBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20NCkJ1dCBhbHNvOiAtIE5TUHMgKE5ldHdv cmsgU2VydmljZSBQcm92aWRlcnMpIHdhbnQgdG8gcHJvdmlkZSBhIHBhdGggd2hlcmUgdGhlIGJh bmR3aWR0aCBvZiBXZWJSVEMgaXMgYmV0dGVyIGNvcGVkIHdpdGguDQotIE5TUHMgb3IgRW50ZXJw cmlzZXMgd2FudCB0byBvZmZlciBhbiBJbnRlcm5ldCBhY2Nlc3MgcXVhbGl0eSBwaXBlIGZvciBw cmlvcml0aXplZCBSVEMgKFJlYWwgVGltZSBDb21tdW5pY2F0aW9uKSB0cmFmZmljLg0KLSBFbnRl cnByaXNlcyBoYXZpbmcgcmVzdHJpY3RpdmUgZmlyZXdhbGxzLCB3YW50IHRvIHByb3ZpZGUgYSBV RFAtcGF0aCBmb3IgV2ViUlRDIGFuZCBwb3NzaWJseSBhbHNvIGZvciBiZXR0ZXIgcXVhbGl0eSB3 aGVyZSBSVEMgZG8gbm90IGNvbXBldGUgd2l0aCBkYXRhIHRyYWZmaWMuDQpBbHNvIGNvbnNpZGVy aW5nDQotIE1vYmlsaXR5OyBJdCBpcyBjb21tb24gdG8gbW92ZSBmcm9tIGEgTEFOIHRvIGFjY2Vz c2luZyB2aWEgV2lGaSBvciAzRy80RyBPVFQgY2hhbm5lbHMsIGFsbCBzaG91bGQgYmUgYWJsZSB0 byBhdXRvbWF0aWNhbGx5IG9mZmVyIHRoZWlyIG93biBvcHRpbWFsIFRVUk4gc2VydmVyDQoNClRo aXMgbGVhZHMgdXMgaW50byAg4oCcVFVSTuKApnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnSBl dGMhIEl0IGlzIG5vdCBhIG1pc3Rha2UsIGJ1dCB0aGUgdmVyeSBuZWVkIGZvciB0aGlzIG1pbGVz dG9uZSENCg0KQWdhaW4sIGl0IGhhcyBub3QgYmVlbiBkZW1vbnN0cmF0ZWQgd2h5IFRVUk4gaXMg dGhlIHJpZ2h0IHRlY2hub2xvZ3kgaGVyZSwgY29tcGFyZWQgdG8gYSBtb3JlIHRyYW5zcGFyZW50 IGZsb3cgaWRlbnRpZmljYXRpb24gdG9vbCBsaWtlIE1BTElDRS4gV2UgZG9uJ3QgZm9yY2UgYWxs IEhUVFAgcmVxdWVzdHMgdG8gbG9jYXRlIGEgSFRUUCBwcm94eSB2aWEgYW55Y2FzdCwgSSBkb24n dCBzZWUgd2h5IHdlIG5lZWQgdG8gZG8gdGhlIHNhbWUgZm9yIFdlYlJUQy4NCg0KV2hhdCBhcmUg dGhlIGhlc2l0YXRpb25zIHJhaXNlZCBoZXJlPw0KPiBUVVJOIHByaW1hcmlseSB0byBpZGVudGlm eSBXZWJSVEMgZmxvd3MsIGFzIG9wcG9zZWQgdG8gdXNpbmcgaXQgYXMgYSBOQVQgdHJhdmVyc2Fs IHRvb2wuIFRoaXMgbWFrZXMgbWUgY29uY2VybmVkIHRoYXQgd2UgbWF5IGJlIHVzaW5nIHRoZSB3 cm9uZyB0ZWNobm9sb2d5IHRvIHNvbHZlIHRoZSBwcm9ibGVtDQpJdCBpcyBjb3JyZWN0IHRoYXQg SUNFL1NUVU4vVFVSTiB3YXMgZGVzaWduZWQgdG8gYWRkcmVzcyB0aGUgTkFUL0ZpcmV3YWxsIHRy YXZlcnNhbCBwcm9ibGVtIGFzc29jaWF0ZWQgd2l0aCByZWFsLXRpbWUgY29tbXVuaWNhdGlvbiAo U0lQIGF0IHRoYXQgdGltZSkuIEhvd2V2ZXIsIGl0cyBsYXJnZXN0IGZsYXcvcHJvYmxlbSBpcyB0 aGF0IHF1YWxpdHkgdGhpbmdzIHdlcmUgbm90IChjb3VsZCBub3QgYmU/KSBjb25zaWRlcmVkLiBU aGUgbWV0aG9k4oCZcyB2ZXJ5IGlkZWEgKGxpa2UgYWxsIHNpbWlsYXIgbWV0aG9kcyBmb3IgZ2V0 dGluZyBSVEMgdGhyb3VnaCBvcmRpbmFyeSBOQVQvRmlyZXdhbGxzKSBpcyB0byBmb29sIHRoZSBt ZWRpYSB0aHJvdWdoIGEgTkFUL0ZpcmV3YWxsIHRoYXQgaXMgdW5hd2FyZSBvZiB3aGF0IGlzIGhh cHBlbmluZy4gVGh1cywgdGhpcyBpcyByb290IG9mIHF1YWxpdHkgaXNzdWVzIChhbmQgYmFuZHdp ZHRoIGFsbG9jYXRpb24gb3B0aW1pemF0aW9uKSB0aGF0IG5lZWRzIHRvIGJlIGRlYWx0IHdpdGg6 IFJlYWwtdGltZSB0cmFmZmljIGZpZ2h0aW5nIHdpdGggYSBkYXRhIHRyYWZmaWMgY3Jvd2RlZCBj b25nZXN0aW9uIHBvaW50Lg0KDQpJIHRoaW5rIHRoYXQgImZvb2xpbmciIGlzIGFuIGluY29ycmVj dCBkZXNjcmlwdGlvbi4gVGhlIE5BVCBpcyBzdXBwb3NlZCB0byBiZSB0cmFuc3BhcmVudCB0byB0 aGUgY2xpZW50Lg0KDQpCdXQsIGEgQkxFU1NJTkcgb2YgSUNFL1NUVU4vVFVSTiBpcyB0aGF0IGl0 IGNhbiBiZSBzZWVuIGFzIGEgbGVnaXRpbWF0ZSByZXF1ZXN0IGZvciBhIHN1aXRhYmxlIHBpcGUg Zm9yIHF1YWxpdHkgZGVtYW5kaW5nIHJlYWwgdGltZSB0cmFmZmljLiDimLoNCklDRSBpcyBhIHBy ZS1wcm90b2NvbCB5b3UgdXNlIGJlY2F1c2UgeW91IHdhbnQgYSBwYXRoIGZvciByZWFsLXRpbWUg bWVkaWEgYmV0d2VlbiBwYXJ0aWVzLiBIZXJlOiBUaGUgYnJvd3NlciBzYXlzIGtub2NrIGtub2Nr LCBJIHdhbnQgdG8gZ2V0IG1lZGlhIHRocm91Z2ggKGFuZCBvZiBjb3Vyc2Ugd2l0aCBhcyBnb29k IHF1YWxpdHkgYXMgcmVxdWlyZWQgYW5kIHBvc3NpYmxlKS4NCg0KSWYgdGhlIE5BVC9GaXJld2Fs bCBvd25lciBhbmQgbmV0d29yayBvd25lciBhcmUgYWxsb3dlZCB0byBzZWUgdGhlc2UgcmVxdWVz dHMsIHRoZXkgY2FuIGhlbHAvYXNzaXN0IGluIGFjaGlldmluZyB0aGUgZ29vZCBtZWRpYSBwYXRo LiBJZiB0aGV5IGFyZSBub3QgYXdhcmUsIHRoZXkgY2Fubm90IGhlbHAhDQoNCkhvcGUgdGhpcyBt YWRlIGl0IHVuZGVyc3RhbmRhYmxlIG9uIGFuIG92ZXJ2aWV3IGxldmVsIGhvdyB0aGlzIGNhbiBi ZWNvbWUg4oCcVFVSTuKApnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnQ0KSXQgaXMgYWxzbyB0 aGUgT05MWSB3YXkgSSBjYW4gc2VlIHRvIGFjaGlldmUgd2hhdCB3ZSB3YW50IHRvIGFjaGlldmUg YW5kIHNob3VsZCBiZSB0aGUgYWltIGFuZCByZXF1aXJlbWVudCBvZiB0aGlzIG1pbGVzdG9uZS4N Cg0KSSBhbSB0YWxraW5nIGFib3V0IGdlbmVyYWwgdXNhZ2Ugb2YgV2ViUlRDIG92ZXIgSW50ZXJu ZXQvbW9iaWxlIE9UVCAobm90IGZlZWRpbmcgV2ViUlRDIGludG8gYXBwbGljYXRpb24gc3BlY2lm aWMgbmV0d29ya3MgbGlrZSBJTVMgd2hlcmUgb3RoZXIgbWV0aG9kcyBtYXkgZXhpc3QpLg0KDQpU aGlzIGlzIGdvb2QsIG5vdCBldmlsIQ0KDQpJZiB0aGUgaGVzaXRhdGlvbnMgYXJlIHJhaXNlZCBi ZWNhdXNlIG9mIGEgYmVsaWVmL2hvcGUvd2lzaCB0aGF0IHRoZXJlIGFyZSBubyBvciB3aWxsIG5v dCBiZSBzZXZlcmUgcXVhbGl0eSBpc3N1ZXMg4oCcYmVjYXVzZSBpdCBpcyBhbGwgYWJvdXQgYmFu ZHdpZHRo4oCdLCDigJxpdCB3aWxsIHJlc29sdmUgaXRzZWxmIHdpdGggdGltZeKAnSBldGMuLCBJ IHN0cm9uZ2x5IG9iamVjdCEgVGhhdCBpcyB3cm9uZyBhbmQgd2lsbCBiZSB2ZXJ5IGRldHJpbWVu dGFsIGZvciBXZWJSVEMgdXNhZ2UuIFdlIGFscmVhZHkgc2VlIGl0IGFuZCBJIGNhbiBnaXZlIG51 bWVyb3VzIGV4YW1wbGVzIG9mIGhvdyBtdWNoIGxlc3MgcXVhbGl0eSBkZW1hbmRpbmcgVm9JUCBp cy9pcyBub3QgaGFuZGxlZCBxdWFsaXR5IHdpc2UgYW5kIHRoYXQgaXQgbWF0dGVycy4gQW5kLCB3 aGF0IHdvdWxkIGJlIGJhZCBjb25zaWRlcmluZyBxdWFsaXR5IGlzc3VlcyBhbmQgYWxsb3dpbmcv ZW5jb3VyYWdpbmcgbWV0aG9kcyB0byBkZWFsIHdpdGggdGhlbT8NCg0KSWYgdGhlIGhlc2l0YXRp b25zIGFyZSByYWlzZWQsIGJlY2F1c2Ugb2Ygc3VzcGljaW9uIHRoYXQgdGhlIG1ldGhvZHMgd2Ug bWF5IHJlY29tbWVuZCBtYXkgYmUgbWlzdXNlZCB0byBzdG9wL2Jsb2NrL2Rlc3Ryb3kgV2ViUlRD IHVzYWdlIChlLmcuIHRvIHByb3RlY3QgaW5jb21lIGZyb20gY2FycmllciB0ZWxlcGhvbnkgdHJh ZmZpYyksIEkgY291bGQgdW5kZXJzdGFuZCBhbmQgd291bGQgZmlnaHQgdGhlIHNhbWUgYmF0dGxl LiBCdXQgaG9wZWZ1bGx5LCB0aG9zZSBkYXlzIGFyZSAoc29vbikgb3ZlciDigJMgQXQgbGVhc3Qg Zm9yd2FyZCB0aGlua2luZyBjYXJyaWVy4oCZcyByZWFsaXplIHRoYXQgYWxyZWFkeS4gV2ViIFJU QyB3aWxsIGhhcHBlbi4gV2hpY2ggY3VzdG9tZXJzIHdhbnQgdG8gcGF5IGZvciBhbiBhY2Nlc3Mg d2l0aCBibG9ja2VkIFdlYlJUQz8gVGhlIGNhcnJpZXLigJlzIG9mZmVyaW5nL2Fzc3VyaW5nIGdv b2QgV2ViUlRDIHdpbGwgcmF0aGVyIGdldCB0aGUgY3VzdG9tZXJzIGFuZCBpbmNvbWUg4pi6LiAo TWF5YmUgdGhlIFdlYiBicm93c2VyIGNhbiBkZXRlY3QgYW5kIGVuY291cmFnZSB0aGlz4oCmKQ0K DQpJZiB0aGVyZSBhcmUgdGVjaG5pY2FsIGNvbmNlcm5zIG9mIGJhZCByZXN1bHQsIG9yIGJldHRl ciBtZXRob2RzIGFsbG93aW5nIG5ldHdvcmsgcHJvdmlkZXJzIGFuZCBMQU4gbWFuYWdlcnMgdG8g b2ZmZXIgYW5kIGluZm9ybSB0aGUgYnJvd3NlciB0aGF0IHRoZXJlIGFyZSBnb29kIG1lZGlhIHBh dGhzIHRvIGJlIHVzZWQsIGFuZCB0aGF0IHRoZSB3ZWIgYnJvd3NlciBhdXRvbWF0aWNhbGx5IGNh biBjaG9zZSB0aG9zZSwgdGhlbiBsZXQgdXMgYWxsIHVuZGVyc3RhbmQgdGhvc2UsIHNvIHdlIGNh biBhY2hpZXZlIHdoYXQgc2hvdWxkIGJlIGFjaGlldmVkIGJ5IHRoaXMgbWlsZXN0b25lLg0KDQpT a3lwZSwgSGFuZ291dHMsIEZhY2V0aW1lIGFyZSBkb2luZyBiaWxsaW9ucyBvZiBtaW51dGVzIHBl ciB3ZWVrIGFuZCB0aGUgSW50ZXJuZXQgaGFzIG5vdCBtZWx0ZWQgeWV0LiBJZiB3ZSBuZWVkIHRv IGRvIGZsb3cgaWRlbnRpZmljYXRpb24gdG8gYWxsb3cgdHJhZmZpYyB0byBiZSBwcmlvcml0aXpl ZCwgZmluZSAoc2VlIGFib3ZlIHJlZ2FyZGluZyBteSBwcmVmZXJyZWQgYXBwcm9hY2gpLCBidXQg Zm9yY2luZyBhbGwgV2ViUlRDIHRyYWZmaWMgdGhyb3VnaCBhIE1JVE0gKFRVUk4gc2VydmVyKSBp cyBhIG11Y2ggYmlnZ2VyIGp1bXAgdGhhdCBJIGRvbid0IHlldCBzZWUgdGhlIGp1c3RpZmljYXRp b24gZm9yLg0KDQpJbiBzaG9ydDogVFVSTiBpcyBhIHRlY2hub2xvZ3kgdGhhdCBpcyBzdXBwb3Nl ZCB0byBmYWRlIGF3YXkgd2l0aCB0aGUgbW92ZSB0byBJUHY2LiBJIGRvbid0IHRoaW5rIHdlIHdh bnQgdG8gbWFrZSBpdCBhIGNyaXRpY2FsIGVsZW1lbnQgb2YgV2ViUlRDLg0KDQovS2FybA0KDQoN CkZyw6VuOiBEYW4gV2luZyBbbWFpbHRvOmR3aW5nQGNpc2NvLmNvbTxtYWlsdG86ZHdpbmdAY2lz Y28uY29tPl0NClNraWNrYXQ6IGRlbiAxMSBmZWJydWFyaSAyMDE0IDE4OjI1DQpUaWxsOiBNYXJj IEJsYW5jaGV0DQpLb3BpYTogSnVzdGluIFViZXJ0aTsgdGlyZWRkeUBpY2lzY28uY29tPG1haWx0 bzp0aXJlZGR5QGljaXNjby5jb20+OyBLYXJsIFN0YWhsOyB0cmFtQGlldGYub3JnPG1haWx0bzp0 cmFtQGlldGYub3JnPjsgU2ltb24gUGVycmVhdWx0DQoNCsOEbW5lOiBSZTogW3RyYW1dIE1pbGVz dG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJp c2UgYW5kIElTUHMNCg0KDQpPbiBGZWIgMTEsIDIwMTQsIGF0IDk6MDggQU0sIE1hcmMgQmxhbmNo ZXQgPG1hcmMuYmxhbmNoZXRAdmlhZ2VuaWUuY2E8bWFpbHRvOm1hcmMuYmxhbmNoZXRAdmlhZ2Vu aWUuY2E+PiB3cm90ZToNCg0KTGUgMjAxNC0wMi0xMSDDoCAwMDozOSwgRGFuIFdpbmcgPGR3aW5n QGNpc2NvLmNvbTxtYWlsdG86ZHdpbmdAY2lzY28uY29tPj4gYSDDqWNyaXQgOg0KDQoNCk9uIEZl YiAxMCwgMjAxNCwgYXQgNTozMCBQTSwgSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29t PG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KR29vZCB0byBzZWUgdGhlcmUg aXMgYSBsb3Qgb2YgaW50ZXJlc3QgZm9yIHRoaXMgbWlsZXN0b25lLiBCdXQgYmFzZWQgb24gdGhl IGRlc2NyaXB0aW9uIGhlcmUsIGl0IHNlZW1zIGxpa2Ugd2Ugd2FudCB0byB1c2UgVFVSTiBwcmlt YXJpbHkgdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dzLCBhcyBvcHBvc2VkIHRvIHVzaW5nIGl0IGFz IGEgTkFUIHRyYXZlcnNhbCB0b29sLiBUaGlzIG1ha2VzIG1lIGNvbmNlcm5lZCB0aGF0IHdlIG1h eSBiZSB1c2luZyB0aGUgd3JvbmcgdGVjaG5vbG9neSB0byBzb2x2ZSB0aGUgcHJvYmxlbS4NCg0K KzEuDQoNCkkgd291bGQgcHJlZmVyIGFsbG93aW5nIGZsb3dzIHRvIGVzdGFibGlzaCB0aGVtc2Vs dmVzIHVzaW5nIHRoZWlyICdiZXN0JyBwYXRoLCBhbmQgdGhlIGJlc3QgcGF0aCBpcyBzZWxkb20g dGhyb3VnaCBhIFRVUk4gc2VydmVyLiAgV2hlbiB3ZSBpbWFnaW5lIElQdjYgaW4gb3VyIGZ1dHVy ZSwgd2UgZG9uJ3Qgd2FudCB0byBmb3JjZSBhbiBhcHBsaWNhdGlvbi1sZXZlbCBwcm94eSAoVFVS Tikgc2VydmVyIG9uIHRoZSBwYXRoIHNvbGVseSBmb3IgdHJhdmVyc2luZyBhbiBJUHY2IGZpcmV3 YWxsLg0KDQoNCkl0IHNlZW1zIHRoaXMgdGhyZWFkIGlzIGNvbmZsYXRpbmcgYWxsIHRoZSBwb3Nz aWJsZSByZWFzb25zIC8ganVzdGlmaWNhdGlvbnMgZm9yIFRVUk46DQogICogbW9iaWxpdHkNCiAg KiBOQVQgdHJhdmVyc2FsIChib3RoIGVuZHBvaW50cyBhcmUgYmVoaW5kIGVuZHBvaW50LWRlcGVu ZGVudCBtYXBwaW5nIE5BVHMpDQogICogZmlyZXdhbGwgdHJhdmVyc2FsIChmaXJld2FsbCBibG9j a3MgVURQKQ0KICAqIGVuaGFuY2luZyBwcml2YWN5DQoNClVuZm9ydHVuYXRlbHkgdGhlIFRVUk4g c2VydmVyIG5vciB0aGUgZW5kcG9pbnQgcmVhbGx5IGtub3cgd2hpY2ggb2YgdGhvc2UgdXNlLWNh c2VzIGlzIGRlc2lyZWQgKGJ5IHRoZSB1c2VyIG9yIGJ5IHRoZSBJVCBuZXR3b3JrIGFkbWluaXN0 cmF0b3IpIG9yIG5lY2Vzc2FyeSAoZm9yIHRoZSBjYWxsIHRvIHdvcmsgYXQgYWxsKS4NCg0KRGFu LCB3aGlsZSBJIGFncmVlIGluIHByaW5jaXBsZSwgSSBkb3VidCB0aGF0IGEgdXNlciBjb3VsZCBl dmVyIHNheSAiSSB3YW50IG1vYmlsaXR5IG9yIEkgd2FudCBOQVQgdHJhdmVyc2FsIi4gSSB0aGlu ayB0aGUgdXNlciBvbmx5IHdhbnQgdGhlIGNhbGwgdG8gc3VjY2VlZCwgd2hhdGV2ZXIgdGhlIHBy b3BlcnRpZXMgb2YgaXRzIG5ldHdvcmsgcG9pbnQgb2YgYXR0YWNobWVudCBhcmUuDQoNClNvIHdo YXQgY2FuIHdlIGRvPyAgU2hvdWxkIHRoZSBUVVJOIHNlcnZlciBwcm92aWRlIGFueSBhbmQgYWxs IHNlcnZpY2VzIHRoZSBUVVJOIGNsaWVudCBtaWdodCBwb3NzaWJseSB3YW50LCBhcyB0aGF0IGlz IHdoYXQgYSByb2J1c3QgVFVSTiBzZXJ2ZXIgd2lsbCBkbywgYW5kIHRoZSBlbmRwb2ludCBzaG91 bGQgcHJlZmVyIFRVUk4gY2FuZGlkYXRlcyBvdmVyIGFsbCBvdGhlcnMgYmVjYXVzZSB0aGVyZSBt aWdodCBiZSBzb21lIGZ1bmN0aW9uYWxpdHkgLyB1c2VmdWxuZXNzIG9mIFRVUk4gdGhhdCB0aGUg dXNlciBtaWdodCBnYWluIHRocm91Z2ggVFVSTiAoZS5nLiwgZW5oYW5jZWQgcHJpdmFjeSk/DQoN Ci1kDQoNCg0KDQogVGhpcyBzZWVtcyBwcm9ibGVtYXRpYy4gIFBlcmhhcHMgd2UgbmVlZCBhIHdh eSB0byBzaWduYWwgdGhlIGRlc2lyZWQgdXNlLWNhc2UgKCJ0cmFpdCIpLCBvciBhcyBKdXN0aW4g c3VnZ2VzdHMsIHVzaW5nIGEgZGlmZmVyZW50IHRlY2hub2xvZ3kgZm9yIHNvbWUgb2YgdGhlc2Ug dXNlLWNhc2VzLg0KDQotZA0KDQoNCg0KDQpPbiBNb24sIEZlYiAxMCwgMjAxNCBhdCAzOjE4IFBN LCBLYXJsIFN0YWhsIDxrYXJsLnN0YWhsQGludGVydGV4LnNlPG1haWx0bzprYXJsLnN0YWhsQGlu dGVydGV4LnNlPj4gd3JvdGU6DQpTaW1vbiwNCg0KR29vZCBxdWVzdGlvbnMgLSBzZWUgaW5saW5l IGJlbG93IC0tPiAuDQpTb21lIG1vcmUgdGhvdWdodCBpcyByZXF1aXJlZCENCg0KL0thcmwNCg0K LS0tLS1VcnNwcnVuZ2xpZ3QgbWVkZGVsYW5kZS0tLS0tDQpGcsOlbjogdHJhbSBbbWFpbHRvOnRy YW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPl0gRsO2ciBT aW1vbiBQZXJyZWF1bHQNClNraWNrYXQ6IGRlbiAxMCBmZWJydWFyaSAyMDE0IDE1OjE2DQpUaWxs OiBLYXJsIFN0YWhsOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPjsgdGlyZWRk eUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGljaXNjby5jb20+DQrDhG1uZTogUmU6IFt0cmFt XSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBl bnRlcnByaXNlIGFuZCBJU1BzDQoNCkthcmwsDQoNCkl0IGlzIGdyZWF0IHRvIHNlZSBzdWNoIGVu dGh1c2lhc20hIFRoYW5rcyENCg0KSSBoYXZlIGEgY291cGxlIHRlY2huaWNhbCBxdWVzdGlvbnMu Li4NCg0KTGUgMjAxNC0wMi0wOCAwODoxMSwgS2FybCBTdGFobCBhIMOpY3JpdCA6DQo+IC0gTm90 ZSB0aGF0IHRvIGFjaGlldmUgc29tZSBvZiB0aGUgYWJvdmUgcG9pbnRzLCBUVVJOIG11c3QgYmUg ZmF2b3JlZA0KPiBvdmVyIFNUVU4gdG8gZW5mb3JjZSB0aGF0IHRoZSBUVVJOLXBhdGggYWN0dWFs bHkgaXMgdXNlZC4gKFRoZSBBbnljYXN0DQo+IG1ldGhvZCBzdWdnZXN0ZWQgYmVsb3csIOKAnGF1 dG9tYXRpY2FsbHnigJ0gZG9lcyB0aGlzLikNCg0KSSB1bmRlcnN0YW5kIHRoZSBTVFVOIHZzIFRV Uk4gcHJpb3JpdHkgaXNzdWUuIEJ1dCBJIGRvbid0IHNlZSBob3cgYW55Y2FzdCBhZmZlY3RzIGl0 IGluIGFueSB3YXkuIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4/DQotLS0gR29vZCBwb2ludCAtIEkg d2FzIGEgYml0IHF1aWNrIGhlcmUgKG1heWJlIHRvbyBxdWljaykNCldlIGhhdmUgZ2l2ZW4gdGhp cyBxdWl0ZSBiaXQgb2YgdGhvdWdodCwgc2luY2UgZXZlbiBpZiBhIFRVUk4gc2VydmVyIGlzIHBy b3ZpZGVkIGFuZCBkaXNjb3ZlcmVkLCBDVVJSRU5UIHVzYWdlIG9mIElDRSBtYXkgc3VnZ2VzdCBh IGNhbmRpZGF0ZSBmcm9tIHRoZSByZW1vdGUgcGFydHkgdGhhdCB3aWxsIG1ha2UgYSBjb25uZWN0 aW9uIHdpdGhvdXQgdGhlIG5lZWQvdXNhZ2Ugb2YgdGhlIFRVUk4gc2VydmVyICh0aGF0IHdlIHdh bnRlZCB0byBiZSB1c2VkIGZvciB0aGUgZ29vZCBwdXJwb3NlcyBsaXN0ZWQpLg0KDQpUaGUgb25s eSB3YXkgd2UgZm91bmQgYXJvdW5kIHRoaXMsIHdhcyB0byBzdG9wIFNUVU4gdGhyb3VnaCB0aGUg SVAgZGVmYXVsdCBnYXRld2F5IChsaWtlIGEgcmVzdHJpY3RpdmUgRW50ZXJwcmlzZSBmaXJld2Fs bCBkb2VzIGluaGliaXRpbmcgSUNFIGNvbm5lY3Rpdml0eSwgd2hpY2ggb3RoZXJzIGFyZSBjb25j ZXJuZWQgYWJvdXQuLi4pLiBTaW5jZSB0aGUgcHJvdmlzaW9uaW5nIG9mIGF1dG8tZGlzY292ZXJ5 IHVzaW5nIHRoZSBhbnljYXN0IG1lY2hhbmlzbSwgd291bGQgYmUgYWRkaW5nIGEgcm91dGUgaW4g YSBkZWZhdWx0IGdhdGV3YXksIGFkZGluZyBhIGZpcmV3YWxsIHJ1bGUgdG8gZWF0IFNUVU4gcGFj a2V0cyB3b3VsZCBhc3N1cmUgdGhhdCB0aGUgcHJvdmlzaW9uZWQgVFVSTiBzZXJ2ZXIgYWN0dWFs bHkgYmVjb21lcyB1c2VkIChhbmQgbm90IGJ5cGFzc2VkICJieSBhY2NpZGVudCIpLiAoVGhhdCB3 YXMgdGhlIHRob3VnaHQgYmVoaW5kIHRoZSDigJxhdXRvbWF0aWNhbGx54oCdIHdpdGhpbiBxdW90 ZXMuKQ0KDQpCVVQsIHNpbmNlIHlvdSBicm91Z2h0IHVwIHRoZSBxdWVzdGlvbiwgYXNzdW1pbmcg dGhhdCB3ZSBoYXZlIHRoZSBwb3dlciB0byBlbmZvcmNlIFdlYlJUQyB1c2FnZSBvZiBJQ0UsIEkg YmVsaWV2ZSBhIE1VU1QgcmVxdWlyZW1lbnQgdG8gdXNlIGFuIGF1dG8tZGlzY292ZXJlZCBUVVJO IHNlcnZlciBpbnN0ZWFkIG9mIFNUVU4sIHdvdWxkIHNvbHZlIHRoZSBzYW1lIHByb2JsZW0uIEhv d2V2ZXIsIHRoaW5raW5nIGZ1cnRoZXIgKGluIHJlbGF0aW9uIHRvIHlvdXIgbmV4dCBxdWVzdGlv biAtICJhbnlvbmUgY291bGQgc2V0IHVwIGEgYmFkbHktbWFpbnRhaW5lZCIgLSBlbmZvcmNpbmcg c3VjaCBJQ0UgdXNhZ2UgbWF5IG5vdCBiZSBnb29kLikNCg0KDQo+IC0gM15yZCBUaGUgQW55Y2Fz dCBtZXRob2QgYmVsb3cg4oCTIEkgc2VlIG5vIHByb2JsZW0NCj4NCj4gSXQgYWxzbyBoYXMgdGhl IGFkdmFudGFnZSBvZiBlbmNvdXJhZ2luZyAoYnV0IG5vdCByZXF1aXJpbmcpIHRoZQ0KPiBTVFVO L1RVUk4gdG8gYmUgYnVpbHQgaW4gdGhlIGRlZmF1bHQgZ2F0ZXdheSBvciBOQVQvZmlyZXdhbGwv YWNjZXNzDQo+IHJvdXRlciBpdHNlbGYsIHdpdGggYSBzZWNvbmQgaW50ZXJmYWNlIHRvIGEgcHVi bGljIElQIGFkZHJlc3Mgb24gdGhlDQo+IFdBTiBzaWRlLiAoQ3VycmVudCB2b2x1bWUgZGVwbG95 ZWQsIGxvdyBjb3N0IE5TUCB0cmlwbGUgcGxheSBtb2RlbXMNCj4gdXN1YWxseSBoYXZlIGEgcXVh bGl0eSBhc3N1cmVkIGxldmVsIDIgb3IgbGV2ZWwgMyBXQU4gcGlwZSBmb3IganVzdA0KPiB2b2lj ZSAoYW5kIGFub3RoZXIgZm9yIElQVFYpIOKAkyBUaGUgYW55Y2FzdCBkaXNjb3ZlcmVkIFRVUk4t c2VydmVyIGNhbg0KPiBiZSB0aGUgYWNjZXNzIGdhdGV3YXkgdG8gc3VjaCBxdWFsaXR5IHBpcGUg Zm9yIFdlYlJUQyBtZWRpYSwgaW4gYQ0KPiBzaW5nbGUgTlNQIHByb3ZpZGVkIENQRSwgc2NhbGlu ZyBmcm9tIHJlc2lkZW50aWFsIGFuZCB1cC4pDQoNClN1cHBvc2Ugd2UgZGVmaW5lIHdlbGwta25v d24gYW55Y2FzdCBUVVJOIHNlcnZlciBhZGRyZXNzZXMuIEhvdyB3b3VsZCB0aGlzIG5vdCBiZSBz dWJqZWN0IHRvIHRoZSBzYW1lIHNlcnZpY2UgcXVhbGl0eSBpc3N1ZXMgdGhhdCBwbGFndWVkIDZ0 bzQ/IFRoYXQgaXMsIGFueW9uZSBjb3VsZCBzZXQgdXAgYSBiYWRseS1tYWludGFpbmVkLCB1bmRl ci1wcm92aXNpb25lZCBUVVJOIHNlcnZlciBhbmQgYW5ub3VuY2UgaXQgb3ZlciBCR1AgdG8gdGhl IHdvcmxkLCBhcyBpdCB3YXMgZG9uZSBmb3INCjZ0bzQgcmVsYXlzLiBPciBqdXN0IGJhZCBCR1Ag b3V0Ym91bmQgZmlsdGVyIGNvbmZpZ3VyYXRpb24uIEFuZCBob3cgY2FuIHdlIHByZXZlbnQgdHJp YW5nbGUgcm91dGluZz8gVGhlcmUgaXMgbm90aGluZyBndWFyYW50ZWVpbmcgdGhhdCB0aGUgYW55 Y2FzdCBzZXJ2ZXIgeW91IHNlZSBpcyBiZWluZyBwcm92aWRlZCB0byB5b3UgYnkgeW91ciBJU1As IHJhdGhlciB0aGFuIGEgc2VydmVyIHNpdHRpbmcgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIHBs YW5ldC4NCi0tLSBHb29kIHBvaW50IC0gbmVlZHMgdG8gYmUgcmVzb2x2ZWQuIEZvciB0aGlzIEkg ZG9uJ3QgaGF2ZSBhIHJlYWR5IGFuc3dlci4uLg0KQW4gYXV0by1kaXNjb3ZlcmVkIFRVUk4gc2Vy dmVyIG11c3QgYmUgdHJ1c3RlZCAod2hhdGV2ZXIgbWV0aG9kIGl0IGlzIGRpc2NvdmVyZWQgYnkp LiBXZSBhcmUgdHJ1c3RpbmcgdGhlIG9uZSBwcm92aWRpbmcgdXMgd2l0aCBhbiBJUCBhZGRyZXNz IGFuZCBkZWZhdWx0IGdhdGV3YXkgYW55d2F5LiBJdCB3b3VsZCBiZSBlYXN5IGlmIHdlIGNvdWxk IHJldXNlIHRoYXQgdHJ1c3QsIGluc3RlYWQgb2YgYW5vdGhlciBtZWNoYW5pc21zLg0KDQpJcyB0 aGVyZSBhIGdvb2Qgd2F5IGZvciB0aGUgYnJvd3NlciB0byBjaGVjayB0aGF0IHRoZSBhbnljYXN0 IGFkZHJlc3MgaXMgbm90IGhhbmRsZWQgYmV5b25kIHRoZSBuZXR3b3JrIHNlcnZpY2UgcHJvdmlk ZXIncyBkZWZhdWx0IGdhdGV3YXk/IElkZWFzPw0KDQoNCg0KVGhhbmtzLA0KU2ltb24NCi0tDQpE VE4gbWFkZSBlYXN5LCBsZWFuLCBhbmQgc21hcnQgLS0+IGh0dHA6Ly9wb3N0ZWxsYXRpb24udmlh Z2VuaWUuY2E8aHR0cDovL3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5jYS8+DQpOQVQ2NC9ETlM2NCBv cGVuLXNvdXJjZSAgICAgICAgLS0+IGh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhPGh0dHA6Ly9l Y2R5c2lzLnZpYWdlbmllLmNhLz4NClNUVU4vVFVSTiBzZXJ2ZXIgICAgICAgICAgICAgICAtLT4g aHR0cDovL251bWIudmlhZ2VuaWUuY2E8aHR0cDovL251bWIudmlhZ2VuaWUuY2EvPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBs aXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxt YWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdHJhbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0 DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9y ZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHJhbQ0KDQoNCg== --_000_9F33F40F6F2CD847824537F3C4E37DDF17CF2EDDMCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgY2FzZSB3aGVyZSB0aGUg VFVSTiBzZXJ2ZXIgaXMgdGhlIG9ubHkgb3B0aW9uIG1heSBiZWNvbWUgY29tbW9uIHdpdGhpbiBl bnRlcnByaXNlIG5ldHdvcmtzIGFuZCB0aGF0IG1pZ2h0IGJlIGRlbGliZXJhdGUgZW50ZXJwcmlz ZSBwb2xpY3kgYmVjYXVzZSBpdCBwcm92aWRlcw0KIHRoZSBiZXR0ZXIgcGF0aCAoVURQIHRocm91 Z2ggdGhlIEYvVykgYW5kIHByb3RlY3RzIHRoZSB1c2VycyBhbmQgdGhlIG5ldHdvcmsuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0cmFtIFttYWlsdG86dHJhbS1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+ U2VudDo8L2I+IDEyIEZlYnJ1YXJ5IDIwMTQgMTc6NDY8YnI+DQo8Yj5Ubzo8L2I+IE11dGh1IEFy dWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpPGJyPg0KPGI+Q2M6PC9iPiB0aXJlZGR5QGljaXNj by5jb207IFNpbW9uIFBlcnJlYXVsdDsgT2xlZyBNb3NrYWxlbmtvOyB0cmFtQGlldGYub3JnOyBN YXJjIEJsYW5jaGV0OyBEYW4gV2luZyAoZHdpbmcpOyBLYXJsIFN0YWhsPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5 IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZS4gSWYgVFVSTiBpcyBpbmRlZWQg YmVpbmcgcHJvdmlkZWQgZm9yIHRoZSB1c2VyJ3MgYmVuZWZpdCwgdGhlIGNsaWVudCdzIElDRSBs b2dpYyAoYmFzZWQgb24gUlRUIG9yIHNpbWlsYXIpIHNob3VsZCByZXN1bHQgaW4gaXQgcHJlZmVy cmluZyB0aGUgVFVSTiBwYXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAxMiwgMjAx NCBhdCAxOjI3IEFNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1wZXJ1bWFsQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1wZXJ1bWFs QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5ZZXMsIEkgYmVsaWV2ZSB0aGUgc2Vjb25k IGNhc2UgaXMgcmFyZSwgYnV0IHdvdWxkIGJlIGJldHRlciB0aGFuIGEgcmF0IHJhY2UgYi93IGFk bWluaXN0cmF0b3JzIHRyeWluZyB0byBibG9jayBwMnAgdHJhZmZpYw0KIGFuZCBmb3JjZSBpdCB0 aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgYW5kIGFwcHMvZW5kcG9pbnRzIGZpbmRpbmcgc21hcnRlciB3 YXlzIHRvIGJ5cGFzcyB0aGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk11dGh1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBj bSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPbGVnIE1vc2th bGVua28gW21haWx0bzo8YSBocmVmPSJtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPm1vbTA0MDI2N0BnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQgMTowNyBQTTxicj4NCjxiPlRvOjwvYj4gTXV0aHUg QXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk8YnI+DQo8Yj5DYzo8L2I+IEp1c3RpbiBVYmVy dGk7IEthcmwgU3RhaGw7IDxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5jb20iIHRhcmdl dD0iX2JsYW5rIj4NCnRpcmVkZHlAaWNpc2NvLmNvbTwvYT47IE1hcmMgQmxhbmNoZXQ7IDxhIGhy ZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0cmFtQGlldGYub3Jn PC9hPjsgRGFuIFdpbmcgKGR3aW5nKTsgU2ltb24gUGVycmVhdWx0PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3Zlcnkg bWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRoZSBUVVJOIHNlcnZlciBoYXMgdG8gYmUgdXNlZCB3aGVuIGl0IGlzIGVpdGhlciB0aGUgb25s eSBvcHRpb24sIG9yIGlmIGl0IHByb3ZpZGVzIGEgYmV0dGVyIHBhdGggKEkgZ3Vlc3MgdGhlIHNl Y29uZCBjYXNlIGlzIHJhdGhlciByYXJlKS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+T24gVHVlLCBGZWIgMTEsIDIwMTQgYXQgMTE6MzIgUE0sIE11dGh1IEFydWwgTW96aGkg UGVydW1hbCAobXBlcnVtYWwpICZsdDs8YSBocmVmPSJtYWlsdG86bXBlcnVtYWxAY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+bXBlcnVtYWxAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiYjNDM7MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPkZvcmNpbmcgYWxsIHRyYWZmaWMgdGhyb3VnaCBhIFRVUk4gc2VydmVyIGFu ZCBleHBlY3RpbmcgaXQgd291bGQgcHJvdmlkZSB0aGUgYmVzdCB1c2VyIGV4cGVyaWVuY2UgZG9l c24ndCBsb29rIHRoZSByaWdodA0KIGFwcHJvYWNoLiBJbnN0ZWFkLCBpZiBhIHBhdGggdGhyb3Vn aCBhIFRVUk4gc2VydmVyIGV4aXN0cyBhbmQgZG9lcyBwcm92aWRlIGxvd2VyIFJUVCwgaml0dGVy IGV0YywgYmVpbmcgYWJsZSB0byBkZXRlY3QgYW5kIHVzZSAob3Igc3dpdGNoIHRvKSB0aGF0IHBh dGggbWlnaHQgYmUgZGVzaXJhYmxlLi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NdXRodTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj50cmFtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0 aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQg MTE6NDMgQU08YnI+DQo8Yj5Ubzo8L2I+IEthcmwgU3RhaGw8YnI+DQo8Yj5DYzo8L2I+IDxhIGhy ZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGlj aXNjby5jb208L2E+OyBNYXJjIEJsYW5jaGV0Ow0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj50cmFtQGlldGYub3JnPC9hPjsgRGFuIFdpbmcgKGR3aW5nKTsg U2ltb24gUGVycmVhdWx0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gTWlsZXN0b25l IDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBh bmQgSVNQczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbmxpbmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgRmViIDExLCAyMDE0IGF0IDI6MzcgUE0sIEthcmwgU3Rh aGwgJmx0OzxhIGhyZWY9Im1haWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlIiB0YXJnZXQ9Il9i bGFuayI+a2FybC5zdGFobEBpbnRlcnRleC5zZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Ymx1ZSI+TGlzdGVuaW5nIHRvIHRoaXMgdGhyZWFkLCBJIGFtIGFmcmFp ZCB3ZSBhcmUgbWlzc2luZyB0aGUgdmVyeSBwb2ludCBhbmQgbmVjZXNzaXR5IGZvciB0aGlzIG1p bGVzdG9uZSE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LSBUaGVyZSBhcmUgc2V2ZXJlIE5B VCB0cmF2ZXJzYWwgYW5kIHF1YWxpdHkgaXNzdWVzIHRoYXQgc2hvdWxkIGFuZCBjYW4gYmUgZGVh bHQgd2l0aCBieSBhIGdvb2QgYXV0by1kaXNjb3ZlcnkNCiBtZWNoYW5pc20gYW5kIHRoZSByaWdo dCB1c2FnZSBieSB0aGUgdHVybiBjbGllbnQgKHRoZSBXZWJSVEMgYnJvd3Nlcik8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlRoZXJl IGFyZSB3YXlzLCBub3Qgb25seToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RW50ZXJwcmlzZXMgb3IgSVNQ cyB3aXNoaW5nIHRvIHByb3ZpZGUgdGhlaXIgb3duIFRVUk4gc2VydmVyLCBpbiBhbiBhdHRlbXB0 IHRvIHJlZHVjZSBzby1jYWxsZWQgJnF1b3Q7dHJpYW5nbGUgcm91dGluZyZxdW90OyxuZWVkIGEg bmV3IGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5C dXQgYWxzbzogLSBOU1BzIChOZXR3b3JrIFNlcnZpY2UgUHJvdmlkZXJzKSB3YW50IHRvIHByb3Zp ZGUgYSBwYXRoIHdoZXJlIHRoZSBiYW5kd2lkdGggb2YgV2ViUlRDIGlzIGJldHRlcg0KIGNvcGVk IHdpdGguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIE5TUHMgb3IgRW50ZXJw cmlzZXMgd2FudCB0byBvZmZlciBhbiBJbnRlcm5ldCBhY2Nlc3MgcXVhbGl0eSBwaXBlIGZvciBw cmlvcml0aXplZCBSVEMgKFJlYWwgVGltZSBDb21tdW5pY2F0aW9uKQ0KIHRyYWZmaWMuIDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIEVudGVycHJpc2VzIGhhdmluZyByZXN0cmljdGl2ZSBm aXJld2FsbHMsIHdhbnQgdG8gcHJvdmlkZSBhIFVEUC1wYXRoIGZvciBXZWJSVEMgYW5kIHBvc3Np Ymx5IGFsc28gZm9yDQogYmV0dGVyIHF1YWxpdHkgd2hlcmUgUlRDIGRvIG5vdCBjb21wZXRlIHdp dGggZGF0YSB0cmFmZmljLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5BbHNv IGNvbnNpZGVyaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIE1vYmlsaXR5 OyBJdCBpcyBjb21tb24gdG8gbW92ZSBmcm9tIGEgTEFOIHRvIGFjY2Vzc2luZyB2aWEgV2lGaSBv ciAzRy80RyBPVFQgY2hhbm5lbHMsIGFsbCBzaG91bGQgYmUNCiBhYmxlIHRvIGF1dG9tYXRpY2Fs bHkgb2ZmZXIgdGhlaXIgb3duIG9wdGltYWwgVFVSTiBzZXJ2ZXI8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhpcyBs ZWFkcyB1cyBpbnRvDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 4oCcVFVSTuKApnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnQ0KPHNwYW4gc3R5bGU9ImNvbG9y OmJsdWUiPmV0YyEgSXQgaXMgbm90IGEgbWlzdGFrZSwgYnV0IHRoZSB2ZXJ5IG5lZWQgZm9yIHRo aXMgbWlsZXN0b25lITwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFnYWluLCBpdCBoYXMgbm90IGJl ZW4gZGVtb25zdHJhdGVkIHdoeSBUVVJOIGlzIHRoZSByaWdodCB0ZWNobm9sb2d5IGhlcmUsIGNv bXBhcmVkIHRvIGEgbW9yZSB0cmFuc3BhcmVudCBmbG93IGlkZW50aWZpY2F0aW9uIHRvb2wgbGlr ZSBNQUxJQ0UuIFdlIGRvbid0IGZvcmNlIGFsbCBIVFRQIHJlcXVlc3RzDQogdG8gbG9jYXRlIGEg SFRUUCBwcm94eSB2aWEgYW55Y2FzdCwgSSBkb24ndCBzZWUgd2h5IHdlIG5lZWQgdG8gZG8gdGhl IHNhbWUgZm9yIFdlYlJUQy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVl Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+V2hhdCBhcmUgdGhlIGhlc2l0YXRp b25zIHJhaXNlZCBoZXJlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgVFVSTiBwcmlt YXJpbHkgdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dzLCBhcyBvcHBvc2VkIHRvIHVzaW5nIGl0IGFz IGEgTkFUIHRyYXZlcnNhbCB0b29sLiBUaGlzIG1ha2VzIG1lIGNvbmNlcm5lZA0KIHRoYXQgd2Ug bWF5IGJlIHVzaW5nIHRoZSB3cm9uZyB0ZWNobm9sb2d5IHRvIHNvbHZlIHRoZSBwcm9ibGVtPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SXQgaXMgY29ycmVjdCB0aGF0IElDRS9T VFVOL1RVUk4gd2FzIGRlc2lnbmVkIHRvIGFkZHJlc3MgdGhlIE5BVC9GaXJld2FsbCB0cmF2ZXJz YWwgcHJvYmxlbSBhc3NvY2lhdGVkDQogd2l0aCByZWFsLXRpbWUgY29tbXVuaWNhdGlvbiAoU0lQ IGF0IHRoYXQgdGltZSkuIEhvd2V2ZXIsIGl0cyBsYXJnZXN0IGZsYXcvcHJvYmxlbSBpcyB0aGF0 IHF1YWxpdHkgdGhpbmdzIHdlcmUgbm90IChjb3VsZCBub3QgYmU/KSBjb25zaWRlcmVkLiBUaGUg bWV0aG9k4oCZcyB2ZXJ5IGlkZWEgKGxpa2UgYWxsIHNpbWlsYXIgbWV0aG9kcyBmb3IgZ2V0dGlu ZyBSVEMgdGhyb3VnaCBvcmRpbmFyeSBOQVQvRmlyZXdhbGxzKSBpcyB0byBmb29sIHRoZSBtZWRp YQ0KIHRocm91Z2ggYSBOQVQvRmlyZXdhbGwgdGhhdCBpcyB1bmF3YXJlIG9mIHdoYXQgaXMgaGFw cGVuaW5nLiBUaHVzLCB0aGlzIGlzIHJvb3Qgb2YgcXVhbGl0eSBpc3N1ZXMgKGFuZCBiYW5kd2lk dGggYWxsb2NhdGlvbiBvcHRpbWl6YXRpb24pIHRoYXQgbmVlZHMgdG8gYmUgZGVhbHQgd2l0aDog UmVhbC10aW1lIHRyYWZmaWMgZmlnaHRpbmcgd2l0aCBhIGRhdGEgdHJhZmZpYyBjcm93ZGVkIGNv bmdlc3Rpb24gcG9pbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRoaW5rIHRo YXQgJnF1b3Q7Zm9vbGluZyZxdW90OyBpcyBhbiBpbmNvcnJlY3QgZGVzY3JpcHRpb24uIFRoZSBO QVQgaXMgc3VwcG9zZWQgdG8gYmUgdHJhbnNwYXJlbnQgdG8gdGhlIGNsaWVudC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1 ZSI+QnV0LCBhIEJMRVNTSU5HIG9mIElDRS9TVFVOL1RVUk4gaXMgdGhhdCBpdCBjYW4gYmUgc2Vl biBhcyBhIGxlZ2l0aW1hdGUgcmVxdWVzdCBmb3IgYSBzdWl0YWJsZSBwaXBlIGZvcg0KIHF1YWxp dHkgZGVtYW5kaW5nIHJlYWwgdGltZSB0cmFmZmljLiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOmJsdWUiPko8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj5JQ0UgaXMgYSBwcmUtcHJvdG9jb2wgeW91IHVzZSBiZWNhdXNlIHlvdSB3YW50IGEg cGF0aCBmb3IgcmVhbC10aW1lIG1lZGlhIGJldHdlZW4gcGFydGllcy4gSGVyZTogVGhlIGJyb3dz ZXINCiBzYXlzIGtub2NrIGtub2NrLCBJIHdhbnQgdG8gZ2V0IG1lZGlhIHRocm91Z2ggKGFuZCBv ZiBjb3Vyc2Ugd2l0aCBhcyBnb29kIHF1YWxpdHkgYXMgcmVxdWlyZWQgYW5kIHBvc3NpYmxlKS4N Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+SWYgdGhlIE5BVC9GaXJld2FsbCBvd25lciBhbmQgbmV0d29yayBvd25lciBhcmUgYWxs b3dlZCB0byBzZWUgdGhlc2UgcmVxdWVzdHMsIHRoZXkgY2FuIGhlbHAvYXNzaXN0IGluDQogYWNo aWV2aW5nIHRoZSBnb29kIG1lZGlhIHBhdGguIElmIHRoZXkgYXJlIG5vdCBhd2FyZSwgdGhleSBj YW5ub3QgaGVscCE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SG9w ZSB0aGlzIG1hZGUgaXQgdW5kZXJzdGFuZGFibGUgb24gYW4gb3ZlcnZpZXcgbGV2ZWwgaG93IHRo aXMgY2FuIGJlY29tZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiDigJxU VVJO4oCmdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dz4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPkl0IGlzIGFsc28gdGhlIE9OTFkgd2F5IEkgY2FuIHNlZSB0byBhY2hpZXZlIHdoYXQgd2Ug d2FudCB0byBhY2hpZXZlIGFuZCBzaG91bGQgYmUgdGhlIGFpbSBhbmQgcmVxdWlyZW1lbnQNCiBv ZiB0aGlzIG1pbGVzdG9uZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkkgYW0gdGFsa2luZyBhYm91dCBnZW5lcmFsIHVzYWdlIG9m IFdlYlJUQyBvdmVyIEludGVybmV0L21vYmlsZSBPVFQgKG5vdCBmZWVkaW5nIFdlYlJUQyBpbnRv IGFwcGxpY2F0aW9uDQogc3BlY2lmaWMgbmV0d29ya3MgbGlrZSBJTVMgd2hlcmUgb3RoZXIgbWV0 aG9kcyBtYXkgZXhpc3QpLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlRoaXMgaXMgZ29vZCwgbm90IGV2aWwhPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JZiB0aGUg aGVzaXRhdGlvbnMgYXJlIHJhaXNlZCBiZWNhdXNlIG9mIGEgYmVsaWVmL2hvcGUvd2lzaCB0aGF0 IHRoZXJlIGFyZSBubyBvciB3aWxsIG5vdCBiZSBzZXZlcmUgcXVhbGl0eQ0KIGlzc3VlcyDigJxi ZWNhdXNlIGl0IGlzIGFsbCBhYm91dCBiYW5kd2lkdGjigJ0sIOKAnGl0IHdpbGwgcmVzb2x2ZSBp dHNlbGYgd2l0aCB0aW1l4oCdIGV0Yy4sIEkgc3Ryb25nbHkgb2JqZWN0ISBUaGF0IGlzIHdyb25n IGFuZCB3aWxsIGJlIHZlcnkgZGV0cmltZW50YWwgZm9yIFdlYlJUQyB1c2FnZS4gV2UgYWxyZWFk eSBzZWUgaXQgYW5kIEkgY2FuIGdpdmUgbnVtZXJvdXMgZXhhbXBsZXMgb2YgaG93IG11Y2ggbGVz cyBxdWFsaXR5IGRlbWFuZGluZyBWb0lQDQogaXMvaXMgbm90IGhhbmRsZWQgcXVhbGl0eSB3aXNl IGFuZCB0aGF0IGl0IG1hdHRlcnMuIEFuZCwgd2hhdCB3b3VsZCBiZSBiYWQgY29uc2lkZXJpbmcg cXVhbGl0eSBpc3N1ZXMgYW5kIGFsbG93aW5nL2VuY291cmFnaW5nIG1ldGhvZHMgdG8gZGVhbCB3 aXRoIHRoZW0/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPklmIHRo ZSBoZXNpdGF0aW9ucyBhcmUgcmFpc2VkLCBiZWNhdXNlIG9mIHN1c3BpY2lvbiB0aGF0IHRoZSBt ZXRob2RzIHdlIG1heSByZWNvbW1lbmQgbWF5IGJlIG1pc3VzZWQgdG8NCiBzdG9wL2Jsb2NrL2Rl c3Ryb3kgV2ViUlRDIHVzYWdlIChlLmcuIHRvIHByb3RlY3QgaW5jb21lIGZyb20gY2FycmllciB0 ZWxlcGhvbnkgdHJhZmZpYyksIEkgY291bGQgdW5kZXJzdGFuZCBhbmQgd291bGQgZmlnaHQgdGhl IHNhbWUgYmF0dGxlLiBCdXQgaG9wZWZ1bGx5LCB0aG9zZSBkYXlzIGFyZSAoc29vbikgb3ZlciDi gJMgQXQgbGVhc3QgZm9yd2FyZCB0aGlua2luZyBjYXJyaWVy4oCZcyByZWFsaXplIHRoYXQgYWxy ZWFkeS4gV2ViIFJUQyB3aWxsDQogaGFwcGVuLiBXaGljaCBjdXN0b21lcnMgd2FudCB0byBwYXkg Zm9yIGFuIGFjY2VzcyB3aXRoIGJsb2NrZWQgV2ViUlRDPyBUaGUgY2FycmllcuKAmXMgb2ZmZXJp bmcvYXNzdXJpbmcgZ29vZCBXZWJSVEMgd2lsbCByYXRoZXIgZ2V0IHRoZSBjdXN0b21lcnMgYW5k IGluY29tZQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OldpbmdkaW5ncztjb2xvcjpibHVlIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Ymx1ZSI+LiAoTWF5YmUgdGhlIFdlYiBicm93c2VyIGNhbiBkZXRlY3QgYW5kIGVuY291 cmFnZSB0aGlz4oCmKTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPklmIHRoZXJlIGFyZSB0ZWNobmljYWwgY29uY2Vy bnMgb2YgYmFkIHJlc3VsdCwgb3IgYmV0dGVyIG1ldGhvZHMgYWxsb3dpbmcgbmV0d29yayBwcm92 aWRlcnMgYW5kIExBTiBtYW5hZ2Vycw0KIHRvIG9mZmVyIGFuZCBpbmZvcm0gdGhlIGJyb3dzZXIg dGhhdCB0aGVyZSBhcmUgZ29vZCBtZWRpYSBwYXRocyB0byBiZSB1c2VkLCBhbmQgdGhhdCB0aGUg d2ViIGJyb3dzZXIgYXV0b21hdGljYWxseSBjYW4gY2hvc2UgdGhvc2UsIHRoZW4gbGV0IHVzIGFs bCB1bmRlcnN0YW5kIHRob3NlLCBzbyB3ZSBjYW4gYWNoaWV2ZSB3aGF0IHNob3VsZCBiZSBhY2hp ZXZlZCBieSB0aGlzIG1pbGVzdG9uZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNr eXBlLCBIYW5nb3V0cywgRmFjZXRpbWUgYXJlIGRvaW5nIGJpbGxpb25zIG9mIG1pbnV0ZXMgcGVy IHdlZWsgYW5kIHRoZSBJbnRlcm5ldCBoYXMgbm90IG1lbHRlZCB5ZXQuIElmIHdlIG5lZWQgdG8g ZG8gZmxvdyBpZGVudGlmaWNhdGlvbiB0byBhbGxvdyB0cmFmZmljIHRvIGJlIHByaW9yaXRpemVk LCBmaW5lDQogKHNlZSBhYm92ZSByZWdhcmRpbmcgbXkgcHJlZmVycmVkIGFwcHJvYWNoKSwgYnV0 IGZvcmNpbmcgYWxsIFdlYlJUQyB0cmFmZmljIHRocm91Z2ggYSBNSVRNIChUVVJOIHNlcnZlcikg aXMgYSBtdWNoIGJpZ2dlciBqdW1wIHRoYXQgSSBkb24ndCB5ZXQgc2VlIHRoZSBqdXN0aWZpY2F0 aW9uIGZvci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkluIHNob3J0OiBUVVJOIGlzIGEgdGVjaG5vbG9neSB0aGF0IGlzIHN1cHBvc2Vk IHRvIGZhZGUgYXdheSB3aXRoIHRoZSBtb3ZlIHRvIElQdjYuIEkgZG9uJ3QgdGhpbmsgd2Ugd2Fu dCB0byBtYWtlIGl0IGEgY3JpdGljYWwgZWxlbWVudCBvZiBXZWJSVEMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi9L YXJsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnLDpW46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IERhbiBXaW5nIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmR3aW5nQGNpc2NvLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmR3aW5nQGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5Ta2lja2F0OjwvYj4gZGVu IDExIGZlYnJ1YXJpIDIwMTQgMTg6MjU8YnI+DQo8Yj5UaWxsOjwvYj4gPC9zcGFuPjxzcGFuIGxh bmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TWFyYyBCbGFuY2hldDxicj4NCjxiPktvcGlh OjwvYj4gSnVzdGluIFViZXJ0aTsgPGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPg0KdGlyZWRkeUBpY2lzY28uY29tPC9hPjsgS2FybCBTdGFobDsgPGEg aHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRyYW1AaWV0Zi5v cmc8L2E+OyBTaW1vbiBQZXJyZWF1bHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPjxicj4NCjxiPsOEbW5l OjwvYj4gUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3Zlcnkg bWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJTViI+T24gRmViIDExLCAyMDE0LCBhdCA5OjA4IEFNLCBNYXJjIEJsYW5jaGV0ICZsdDs8 YSBocmVmPSJtYWlsdG86bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYSIgdGFyZ2V0PSJfYmxhbmsi Pm1hcmMuYmxhbmNoZXRAdmlhZ2VuaWUuY2E8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IlNWIj5MZSAyMDE0LTAyLTExIMOgIDAwOjM5LCBEYW4gV2luZyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmR3aW5nQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR3aW5nQGNpc2NvLmNvbTwv YT4mZ3Q7IGEgw6ljcml0IDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpPbiBGZWIgMTAsIDIwMTQsIGF0IDU6MzAgUE0sIEp1c3Rp biBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5qdWJlcnRpQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Hb29kIHRvIHNlZSB0aGVyZSBpcyBh IGxvdCBvZiBpbnRlcmVzdCBmb3IgdGhpcyBtaWxlc3RvbmUuIEJ1dCBiYXNlZCBvbiB0aGUgZGVz Y3JpcHRpb24gaGVyZSwgaXQgc2VlbXMNCiBsaWtlIHdlIHdhbnQgdG8gdXNlIFRVUk4gcHJpbWFy aWx5IHRvIGlkZW50aWZ5IFdlYlJUQyBmbG93cywgYXMgb3Bwb3NlZCB0byB1c2luZyBpdCBhcyBh IE5BVCB0cmF2ZXJzYWwgdG9vbC4gVGhpcyBtYWtlcyBtZSBjb25jZXJuZWQgdGhhdCB3ZSBtYXkg YmUgdXNpbmcgdGhlIHdyb25nIHRlY2hub2xvZ3kgdG8gc29sdmUgdGhlIHByb2JsZW0uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JiM0MzsxLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgd291bGQgcHJlZmVyIGFsbG93aW5nIGZsb3dzIHRvIGVz dGFibGlzaCB0aGVtc2VsdmVzIHVzaW5nIHRoZWlyICdiZXN0JyBwYXRoLCBhbmQgdGhlIGJlc3Qg cGF0aCBpcw0KIHNlbGRvbSB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIuICZuYnNwO1doZW4gd2UgaW1h Z2luZSBJUHY2IGluIG91ciBmdXR1cmUsIHdlIGRvbid0IHdhbnQgdG8gZm9yY2UgYW4gYXBwbGlj YXRpb24tbGV2ZWwgcHJveHkgKFRVUk4pIHNlcnZlciBvbiB0aGUgcGF0aCBzb2xlbHkgZm9yIHRy YXZlcnNpbmcgYW4gSVB2NiBmaXJld2FsbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5JdCBzZWVtcyB0aGlzIHRocmVhZCBpcyBjb25mbGF0aW5nIGFsbCB0aGUgcG9zc2libGUgcmVh c29ucyAvIGp1c3RpZmljYXRpb25zIGZvciBUVVJOOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAqIG1vYmlsaXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICogTkFUIHRyYXZlcnNhbCAoYm90aCBlbmRw b2ludHMgYXJlIGJlaGluZCBlbmRwb2ludC1kZXBlbmRlbnQgbWFwcGluZyBOQVRzKTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAqJm5ic3A7ZmlyZXdh bGwgdHJhdmVyc2FsIChmaXJld2FsbCBibG9ja3MgVURQKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAqIGVuaGFuY2luZyBwcml2YWN5PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VW5mb3J0dW5hdGVseSB0aGUgVFVSTiBzZXJ2 ZXIgbm9yIHRoZSBlbmRwb2ludCByZWFsbHkga25vdyB3aGljaCBvZiB0aG9zZSB1c2UtY2FzZXMg aXMgZGVzaXJlZCAoYnkgdGhlDQogdXNlciBvciBieSB0aGUgSVQgbmV0d29yayBhZG1pbmlzdHJh dG9yKSBvciBuZWNlc3NhcnkgKGZvciB0aGUgY2FsbCB0byB3b3JrIGF0IGFsbCkuDQo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPkRhbiwgd2hp bGUgSSBhZ3JlZSBpbiBwcmluY2lwbGUsIEkgZG91YnQgdGhhdCBhIHVzZXIgY291bGQgZXZlciBz YXkgJnF1b3Q7SSB3YW50IG1vYmlsaXR5IG9yIEkgd2FudCBOQVQgdHJhdmVyc2FsJnF1b3Q7LiBJ IHRoaW5rIHRoZSB1c2VyIG9ubHkgd2FudCB0aGUgY2FsbCB0byBzdWNjZWVkLCB3aGF0ZXZlcg0K IHRoZSBwcm9wZXJ0aWVzIG9mIGl0cyBuZXR3b3JrIHBvaW50IG9mIGF0dGFjaG1lbnQgYXJlLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IlNWIj5TbyB3aGF0IGNhbiB3ZSBkbz8gJm5ic3A7U2hvdWxkIHRoZSBUVVJOIHNlcnZlciBwcm92 aWRlIGFueSBhbmQgYWxsIHNlcnZpY2VzIHRoZSBUVVJOIGNsaWVudCBtaWdodCBwb3NzaWJseSB3 YW50LCBhcyB0aGF0IGlzIHdoYXQgYSByb2J1c3QgVFVSTiBzZXJ2ZXIgd2lsbCBkbywgYW5kIHRo ZQ0KIGVuZHBvaW50IHNob3VsZCBwcmVmZXIgVFVSTiBjYW5kaWRhdGVzIG92ZXIgYWxsIG90aGVy cyBiZWNhdXNlIHRoZXJlIG1pZ2h0IGJlIHNvbWUgZnVuY3Rpb25hbGl0eSAvIHVzZWZ1bG5lc3Mg b2YgVFVSTiB0aGF0IHRoZSB1c2VyIG1pZ2h0IGdhaW4gdGhyb3VnaCBUVVJOIChlLmcuLCBlbmhh bmNlZCBwcml2YWN5KT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IlNWIj4tZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7VGhpcyBzZWVtcyBwcm9ibGVtYXRpYy4gJm5ic3A7 UGVyaGFwcyB3ZSBuZWVkIGEgd2F5IHRvIHNpZ25hbCB0aGUgZGVzaXJlZCB1c2UtY2FzZSAoJnF1 b3Q7dHJhaXQmcXVvdDspLCBvciBhcyBKdXN0aW4NCiBzdWdnZXN0cywgdXNpbmcgYSBkaWZmZXJl bnQgdGVjaG5vbG9neSBmb3Igc29tZSBvZiB0aGVzZSB1c2UtY2FzZXMuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gTW9uLCBGZWIg MTAsIDIwMTQgYXQgMzoxOCBQTSwgS2FybCBTdGFobCZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86 a2FybC5zdGFobEBpbnRlcnRleC5zZSIgdGFyZ2V0PSJfYmxhbmsiPmthcmwuc3RhaGxAaW50ZXJ0 ZXguc2U8L2E+Jmd0OyZuYnNwO3dyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNp bW9uLDxicj4NCjxicj4NCkdvb2QgcXVlc3Rpb25zIC0gc2VlIGlubGluZSBiZWxvdyAtLSZndDsg Ljxicj4NClNvbWUgbW9yZSB0aG91Z2h0IGlzIHJlcXVpcmVkITxicj4NCjxicj4NCi9LYXJsPGJy Pg0KPGJyPg0KLS0tLS1VcnNwcnVuZ2xpZ3QgbWVkZGVsYW5kZS0tLS0tPGJyPg0KRnLDpW46IHRy YW0gW21haWx0bzo8YSBocmVmPSJtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+dHJhbS1ib3VuY2VzQGlldGYub3JnPC9hPl0gRsO2ciBTaW1vbiBQZXJyZWF1bHQ8 YnI+DQpTa2lja2F0OiBkZW4gMTAgZmVicnVhcmkgMjAxNCAxNToxNjxicj4NClRpbGw6IEthcmwg U3RhaGw7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij50cmFtQGlldGYub3JnPC9hPjsmbmJzcDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBpY2lzY28u Y29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBpY2lzY28uY29tPC9hPjxicj4NCsOEbW5lOiBS ZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5p c20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGJyPg0KS2FybCw8YnI+DQo8YnI+DQpJdCBpcyBncmVhdCB0byBzZWUgc3VjaCBlbnRodXNpYXNt ISBUaGFua3MhPGJyPg0KPGJyPg0KSSBoYXZlIGEgY291cGxlIHRlY2huaWNhbCBxdWVzdGlvbnMu Li48YnI+DQo8YnI+DQpMZSAyMDE0LTAyLTA4IDA4OjExLCBLYXJsIFN0YWhsIGEgw6ljcml0IDo8 YnI+DQomZ3Q7IC0gTm90ZSB0aGF0IHRvIGFjaGlldmUgc29tZSBvZiB0aGUgYWJvdmUgcG9pbnRz LCBUVVJOIG11c3QgYmUgZmF2b3JlZDxicj4NCiZndDsgb3ZlciBTVFVOIHRvIGVuZm9yY2UgdGhh dCB0aGUgVFVSTi1wYXRoIGFjdHVhbGx5IGlzIHVzZWQuIChUaGUgQW55Y2FzdDxicj4NCiZndDsg bWV0aG9kIHN1Z2dlc3RlZCBiZWxvdywg4oCcYXV0b21hdGljYWxseeKAnSBkb2VzIHRoaXMuKTxi cj4NCjxicj4NCkkgdW5kZXJzdGFuZCB0aGUgU1RVTiB2cyBUVVJOIHByaW9yaXR5IGlzc3VlLiBC dXQgSSBkb24ndCBzZWUgaG93IGFueWNhc3QgYWZmZWN0cyBpdCBpbiBhbnkgd2F5LiBDYW4geW91 IHBsZWFzZSBleHBsYWluPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS0t IEdvb2QgcG9pbnQgLSBJIHdhcyBhIGJpdCBxdWljayBoZXJlIChtYXliZSB0b28gcXVpY2spPGJy Pg0KV2UgaGF2ZSBnaXZlbiB0aGlzIHF1aXRlIGJpdCBvZiB0aG91Z2h0LCBzaW5jZSBldmVuIGlm IGEgVFVSTiBzZXJ2ZXIgaXMgcHJvdmlkZWQgYW5kIGRpc2NvdmVyZWQsIENVUlJFTlQgdXNhZ2Ug b2YgSUNFIG1heSBzdWdnZXN0IGEgY2FuZGlkYXRlIGZyb20gdGhlIHJlbW90ZSBwYXJ0eSB0aGF0 IHdpbGwgbWFrZSBhIGNvbm5lY3Rpb24gd2l0aG91dCB0aGUgbmVlZC91c2FnZSBvZiB0aGUgVFVS TiBzZXJ2ZXIgKHRoYXQgd2Ugd2FudGVkIHRvIGJlIHVzZWQNCiBmb3IgdGhlIGdvb2QgcHVycG9z ZXMgbGlzdGVkKS48YnI+DQo8YnI+DQpUaGUgb25seSB3YXkgd2UgZm91bmQgYXJvdW5kIHRoaXMs IHdhcyB0byBzdG9wIFNUVU4gdGhyb3VnaCB0aGUgSVAgZGVmYXVsdCBnYXRld2F5IChsaWtlIGEg cmVzdHJpY3RpdmUgRW50ZXJwcmlzZSBmaXJld2FsbCBkb2VzIGluaGliaXRpbmcgSUNFIGNvbm5l Y3Rpdml0eSwgd2hpY2ggb3RoZXJzIGFyZSBjb25jZXJuZWQgYWJvdXQuLi4pLiBTaW5jZSB0aGUg cHJvdmlzaW9uaW5nIG9mIGF1dG8tZGlzY292ZXJ5IHVzaW5nIHRoZSBhbnljYXN0IG1lY2hhbmlz bSwNCiB3b3VsZCBiZSBhZGRpbmcgYSByb3V0ZSBpbiBhIGRlZmF1bHQgZ2F0ZXdheSwgYWRkaW5n IGEgZmlyZXdhbGwgcnVsZSB0byBlYXQgU1RVTiBwYWNrZXRzIHdvdWxkIGFzc3VyZSB0aGF0IHRo ZSBwcm92aXNpb25lZCBUVVJOIHNlcnZlciBhY3R1YWxseSBiZWNvbWVzIHVzZWQgKGFuZCBub3Qg YnlwYXNzZWQgJnF1b3Q7YnkgYWNjaWRlbnQmcXVvdDspLiAoVGhhdCB3YXMgdGhlIHRob3VnaHQg YmVoaW5kIHRoZSDigJxhdXRvbWF0aWNhbGx54oCdIHdpdGhpbiBxdW90ZXMuKTxicj4NCjxicj4N CkJVVCwgc2luY2UgeW91IGJyb3VnaHQgdXAgdGhlIHF1ZXN0aW9uLCBhc3N1bWluZyB0aGF0IHdl IGhhdmUgdGhlIHBvd2VyIHRvIGVuZm9yY2UgV2ViUlRDIHVzYWdlIG9mIElDRSwgSSBiZWxpZXZl IGEgTVVTVCByZXF1aXJlbWVudCB0byB1c2UgYW4gYXV0by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVy IGluc3RlYWQgb2YgU1RVTiwgd291bGQgc29sdmUgdGhlIHNhbWUgcHJvYmxlbS4gSG93ZXZlciwg dGhpbmtpbmcgZnVydGhlciAoaW4gcmVsYXRpb24NCiB0byB5b3VyIG5leHQgcXVlc3Rpb24gLSAm cXVvdDthbnlvbmUgY291bGQgc2V0IHVwIGEgYmFkbHktbWFpbnRhaW5lZCZxdW90OyAtIGVuZm9y Y2luZyBzdWNoIElDRSB1c2FnZSBtYXkgbm90IGJlIGdvb2QuKTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQomZ3Q7IC0gM15yZCBUaGUgQW55Y2FzdCBtZXRob2QgYmVs b3cg4oCTIEkgc2VlIG5vIHByb2JsZW08YnI+DQomZ3Q7PGJyPg0KJmd0OyBJdCBhbHNvIGhhcyB0 aGUgYWR2YW50YWdlIG9mIGVuY291cmFnaW5nIChidXQgbm90IHJlcXVpcmluZykgdGhlPGJyPg0K Jmd0OyBTVFVOL1RVUk4gdG8gYmUgYnVpbHQgaW4gdGhlIGRlZmF1bHQgZ2F0ZXdheSBvciBOQVQv ZmlyZXdhbGwvYWNjZXNzPGJyPg0KJmd0OyByb3V0ZXIgaXRzZWxmLCB3aXRoIGEgc2Vjb25kIGlu dGVyZmFjZSB0byBhIHB1YmxpYyBJUCBhZGRyZXNzIG9uIHRoZTxicj4NCiZndDsgV0FOIHNpZGUu IChDdXJyZW50IHZvbHVtZSBkZXBsb3llZCwgbG93IGNvc3QgTlNQIHRyaXBsZSBwbGF5IG1vZGVt czxicj4NCiZndDsgdXN1YWxseSBoYXZlIGEgcXVhbGl0eSBhc3N1cmVkIGxldmVsIDIgb3IgbGV2 ZWwgMyBXQU4gcGlwZSBmb3IganVzdDxicj4NCiZndDsgdm9pY2UgKGFuZCBhbm90aGVyIGZvciBJ UFRWKSDigJMgVGhlIGFueWNhc3QgZGlzY292ZXJlZCBUVVJOLXNlcnZlciBjYW48YnI+DQomZ3Q7 IGJlIHRoZSBhY2Nlc3MgZ2F0ZXdheSB0byBzdWNoIHF1YWxpdHkgcGlwZSBmb3IgV2ViUlRDIG1l ZGlhLCBpbiBhPGJyPg0KJmd0OyBzaW5nbGUgTlNQIHByb3ZpZGVkIENQRSwgc2NhbGluZyBmcm9t IHJlc2lkZW50aWFsIGFuZCB1cC4pPGJyPg0KPGJyPg0KU3VwcG9zZSB3ZSBkZWZpbmUgd2VsbC1r bm93biBhbnljYXN0IFRVUk4gc2VydmVyIGFkZHJlc3Nlcy4gSG93IHdvdWxkIHRoaXMgbm90IGJl IHN1YmplY3QgdG8gdGhlIHNhbWUgc2VydmljZSBxdWFsaXR5IGlzc3VlcyB0aGF0IHBsYWd1ZWQg NnRvND8gVGhhdCBpcywgYW55b25lIGNvdWxkIHNldCB1cCBhIGJhZGx5LW1haW50YWluZWQsIHVu ZGVyLXByb3Zpc2lvbmVkIFRVUk4gc2VydmVyIGFuZCBhbm5vdW5jZSBpdCBvdmVyIEJHUCB0byB0 aGUgd29ybGQsDQogYXMgaXQgd2FzIGRvbmUgZm9yPGJyPg0KNnRvNCByZWxheXMuIE9yIGp1c3Qg YmFkIEJHUCBvdXRib3VuZCBmaWx0ZXIgY29uZmlndXJhdGlvbi4gQW5kIGhvdyBjYW4gd2UgcHJl dmVudCB0cmlhbmdsZSByb3V0aW5nPyBUaGVyZSBpcyBub3RoaW5nIGd1YXJhbnRlZWluZyB0aGF0 IHRoZSBhbnljYXN0IHNlcnZlciB5b3Ugc2VlIGlzIGJlaW5nIHByb3ZpZGVkIHRvIHlvdSBieSB5 b3VyIElTUCwgcmF0aGVyIHRoYW4gYSBzZXJ2ZXIgc2l0dGluZyBvbiB0aGUgb3RoZXIgc2lkZSBv ZiB0aGUgcGxhbmV0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS0tIEdv b2QgcG9pbnQgLSBuZWVkcyB0byBiZSByZXNvbHZlZC4gRm9yIHRoaXMgSSBkb24ndCBoYXZlIGEg cmVhZHkgYW5zd2VyLi4uPGJyPg0KQW4gYXV0by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVyIG11c3Qg YmUgdHJ1c3RlZCAod2hhdGV2ZXIgbWV0aG9kIGl0IGlzIGRpc2NvdmVyZWQgYnkpLiBXZSBhcmUg dHJ1c3RpbmcgdGhlIG9uZSBwcm92aWRpbmcgdXMgd2l0aCBhbiBJUCBhZGRyZXNzIGFuZCBkZWZh dWx0IGdhdGV3YXkgYW55d2F5LiBJdCB3b3VsZCBiZSBlYXN5IGlmIHdlIGNvdWxkIHJldXNlIHRo YXQgdHJ1c3QsIGluc3RlYWQgb2YgYW5vdGhlciBtZWNoYW5pc21zLjxicj4NCjxicj4NCklzIHRo ZXJlIGEgZ29vZCB3YXkgZm9yIHRoZSBicm93c2VyIHRvIGNoZWNrIHRoYXQgdGhlIGFueWNhc3Qg YWRkcmVzcyBpcyBub3QgaGFuZGxlZCBiZXlvbmQgdGhlIG5ldHdvcmsgc2VydmljZSBwcm92aWRl cidzIGRlZmF1bHQgZ2F0ZXdheT8gSWRlYXM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KU2ltb248YnI+DQot LTxicj4NCkRUTiBtYWRlIGVhc3ksIGxlYW4sIGFuZCBzbWFydCAtLSZndDsmbmJzcDs8YSBocmVm PSJodHRwOi8vcG9zdGVsbGF0aW9uLnZpYWdlbmllLmNhLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6 Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUuY2E8L2E+PGJyPg0KTkFUNjQvRE5TNjQgb3Blbi1zb3Vy Y2UgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LS0mZ3Q7Jm5ic3A7PGEgaHJlZj0iaHR0cDov L2VjZHlzaXMudmlhZ2VuaWUuY2EvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2VjZHlzaXMudmlh Z2VuaWUuY2E8L2E+PGJyPg0KU1RVTi9UVVJOIHNlcnZlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLS0mZ3Q7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL251 bWIudmlhZ2VuaWUuY2EvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL251bWIudmlhZ2VuaWUuY2E8 L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8L3Nw YW4+PHNwYW4gbGFuZz0iU1YiPjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+ DQo8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvc3Bh bj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJh bUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RyYW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF17CF2EDDMCHP04MSXglobal_-- From juberti@google.com Wed Feb 12 15:11:47 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F661A003D for ; Wed, 12 Feb 2014 15:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 DDgy-f1zW53H for ; Wed, 12 Feb 2014 15:11:41 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id DF27D1A0037 for ; Wed, 12 Feb 2014 15:11:26 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id ie18so7681426vcb.12 for ; Wed, 12 Feb 2014 15:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0y9pS8UsWKDRc59YSNfW5dMMrtuIT2hH5hsBukW+SYI=; b=eZo0UDPFwkbpZBaJKJ8Q7rOAkzBDMVzCS+8mwnXsGEUqUiACYYyS4HERzS94le9eM2 7i0SEasvVUAjR6odnZI21GOQfoWr0hMDOWKRLP8ke0Rbims7UP20zusg9XEXSIvDh2pT ZoTqv657EV3WHhAXoFrNQlzzehLiT9tYEkpWxX46XhMuHc9MqhSW4W2YJux00Dh5ljt/ PozzBJrlMm+BqkVA2il9JnXmTHxgqxaAt5zDo2FO2yT6NiWHWJUOQVhI2eUEvkToWxtl ek7lZTA28dSTzxywQpEVk2E5aA9k3Smo2apOagp4GVGjSuaOliYuQMFpIrr83IhwWyvm lekQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0y9pS8UsWKDRc59YSNfW5dMMrtuIT2hH5hsBukW+SYI=; b=S4Tw3dWWH7TaDxXUYDI57rzH8iHJ2tA5df/ccLxLccU3NNl8P7pickIXs1NhV8D2YJ rMxT5FajSxKu5KxlE1eB0CszGqGACyenGDsq4qp3XQxEjpMbBnPeClI/F3tDUW6xzGfO Gqv9gqWbD8bidlxckadtqhFTLvAhYPIGha6rOmmRLae2FsHG9rnqzih9jnqgX1FjW3cE BI1CoqLjRgEEfjZP6A8h5IYb278l1X/ge17KsVd4c4v0KG5yLFahX4CCnaV3tjTMWERy qz5/Pr2/ByN49HtgbNF8lc9cduz1kCemtKwpJhbh54Ia9/kZ8VFEStfKBP27jX32ZUW1 0LPA== X-Gm-Message-State: ALoCoQmmjAFsLi0TyAP4Df1mGRXad5c4O48+uX/hsRBmXLmp5/FGKpZgzPPoAeuA2Q81MY41yhcnb0jubK2IUoPRFq8dQL+m28oXuiz4A1XYFEcwh86w5qhBSQDQH2NDRx6KJcm1TH2raf9yYdpP+OiCHFLHHkLiXrcGb5QGaLbgzXpuob16TsZiv+CBpZgOmWnWNEmuSozT X-Received: by 10.58.97.171 with SMTP id eb11mr69489veb.64.1392246685630; Wed, 12 Feb 2014 15:11:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Wed, 12 Feb 2014 15:11:05 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17CF2EDD@MCHP04MSX.global-ad.net> References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> <9F33F40F6F2CD847824537F3C4E37DDF17CF2EDD@MCHP04MSX.global-ad.net> From: Justin Uberti Date: Wed, 12 Feb 2014 15:11:05 -0800 Message-ID: To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=089e013a16442320e604f23db165 Cc: "tireddy@icisco.com" , Simon Perreault , Oleg Moskalenko , "tram@ietf.org" , "Muthu Arul Mozhi Perumal \(mperumal\)" , Marc Blanchet , "Dan Wing \(dwing\)" , Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 23:11:47 -0000 --089e013a16442320e604f23db165 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed, but enterprises are already doing this with HTTP proxies, so the precedent (and mechanisms that can be used) are much clearer. On Wed, Feb 12, 2014 at 11:30 AM, Hutton, Andrew w= rote: > The case where the TURN server is the only option may become common > within enterprise networks and that might be deliberate enterprise policy > because it provides the better path (UDP through the F/W) and protects th= e > users and the network. > > > > Andy > > > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* 12 February 2014 17:46 > > *To:* Muthu Arul Mozhi Perumal (mperumal) > *Cc:* tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org= ; > Marc Blanchet; Dan Wing (dwing); Karl Stahl > > *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism > for enterprise and ISPs > > > > Agree. If TURN is indeed being provided for the user's benefit, the > client's ICE logic (based on RTT or similar) should result in it preferri= ng > the TURN path. > > > > On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) < > mperumal@cisco.com> wrote: > > Yes, I believe the second case is rare, but would be better than a rat > race b/w administrators trying to block p2p traffic and force it through = a > TURN server and apps/endpoints finding smarter ways to bypass them. > > > > Muthu > > > > *From:* Oleg Moskalenko [mailto:mom040267@gmail.com] > *Sent:* Wednesday, February 12, 2014 1:07 PM > *To:* Muthu Arul Mozhi Perumal (mperumal) > *Cc:* Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; > tram@ietf.org; Dan Wing (dwing); Simon Perreault > > > *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism > for enterprise and ISPs > > > > The TURN server has to be used when it is either the only option, or if i= t > provides a better path (I guess the second case is rather rare). > > > > On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) < > mperumal@cisco.com> wrote: > > +1 > > > > Forcing all traffic through a TURN server and expecting it would provide > the best user experience doesn't look the right approach. Instead, if a > path through a TURN server exists and does provide lower RTT, jitter etc, > being able to detect and use (or switch to) that path might be desirable.= . > > > > Muthu > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Wednesday, February 12, 2014 11:43 AM > *To:* Karl Stahl > *Cc:* tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); > Simon Perreault > *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism > for enterprise and ISPs > > > > Inline. > > > > On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl > wrote: > > Listening to this thread, I am afraid we are missing the very point and > necessity for this milestone! > > - There are severe NAT traversal and quality issues that should and can b= e > dealt with by a good auto-discovery mechanism and the right usage by the > turn client (the WebRTC browser) > > > > There are ways, not only: Enterprises or ISPs wishing to provide their > own TURN server, in an attempt to reduce so-called "triangle routing",nee= d > a new auto-discovery mechanism > > But also: - NSPs (Network Service Providers) want to provide a path where > the bandwidth of WebRTC is better coped with. > > - NSPs or Enterprises want to offer an Internet access quality pipe for > prioritized RTC (Real Time Communication) traffic. > > - Enterprises having restrictive firewalls, want to provide a UDP-path fo= r > WebRTC and possibly also for better quality where RTC do not compete with > data traffic. > > Also considering > > - Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4= G > OTT channels, all should be able to automatically offer their own optimal > TURN server > > > > This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80= =9D etc! It is not a > mistake, but the very need for this milestone! > > > > Again, it has not been demonstrated why TURN is the right technology here= , > compared to a more transparent flow identification tool like MALICE. We > don't force all HTTP requests to locate a HTTP proxy via anycast, I don't > see why we need to do the same for WebRTC. > > > > What are the hesitations raised here? > > > TURN primarily to identify WebRTC flows, as opposed to using it as a NA= T > traversal tool. This makes me concerned that we may be using the wrong > technology to solve the problem > > It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall > traversal problem associated with real-time communication (SIP at that > time). However, its largest flaw/problem is that quality things were not > (could not be?) considered. The method=E2=80=99s very idea (like all simi= lar > methods for getting RTC through ordinary NAT/Firewalls) is to fool the > media through a NAT/Firewall that is unaware of what is happening. Thus, > this is root of quality issues (and bandwidth allocation optimization) th= at > needs to be dealt with: Real-time traffic fighting with a data traffic > crowded congestion point. > > > > I think that "fooling" is an incorrect description. The NAT is supposed t= o > be transparent to the client. > > > > But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate > request for a suitable pipe for quality demanding real time traffic. J > > ICE is a pre-protocol you use because you want a path for real-time media > between parties. Here: The browser says knock knock, I want to get media > through (and of course with as good quality as required and possible). > > > > If the NAT/Firewall owner and network owner are allowed to see these > requests, they can help/assist in achieving the good media path. If they > are not aware, they cannot help! > > > > Hope this made it understandable on an overview level how this can become= =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D > > It is also the ONLY way I can see to achieve what we want to achieve and > should be the aim and requirement of this milestone. > > > > I am talking about general usage of WebRTC over Internet/mobile OTT (not > feeding WebRTC into application specific networks like IMS where other > methods may exist). > > > > This is good, not evil! > > > > If the hesitations are raised because of a belief/hope/wish that there ar= e > no or will not be severe quality issues =E2=80=9Cbecause it is all about > bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D et= c., I strongly object! > That is wrong and will be very detrimental for WebRTC usage. We already s= ee > it and I can give numerous examples of how much less quality demanding Vo= IP > is/is not handled quality wise and that it matters. And, what would be ba= d > considering quality issues and allowing/encouraging methods to deal with > them? > > > > If the hesitations are raised, because of suspicion that the methods we > may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to > protect income from carrier telephony traffic), I could understand and > would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At > least forward thinking carrier=E2=80=99s realize that already. Web RTC wi= ll happen. > Which customers want to pay for an access with blocked WebRTC? The > carrier=E2=80=99s offering/assuring good WebRTC will rather get the custo= mers and > income J. (Maybe the Web browser can detect and encourage this=E2=80=A6) > > > > If there are technical concerns of bad result, or better methods allowing > network providers and LAN managers to offer and inform the browser that > there are good media paths to be used, and that the web browser > automatically can chose those, then let us all understand those, so we ca= n > achieve what should be achieved by this milestone. > > > > Skype, Hangouts, Facetime are doing billions of minutes per week and the > Internet has not melted yet. If we need to do flow identification to allo= w > traffic to be prioritized, fine (see above regarding my preferred > approach), but forcing all WebRTC traffic through a MITM (TURN server) is= a > much bigger jump that I don't yet see the justification for. > > > > In short: TURN is a technology that is supposed to fade away with the mov= e > to IPv6. I don't think we want to make it a critical element of WebRTC. > > > > /Karl > > > > > > *Fr=C3=A5n:* Dan Wing [mailto:dwing@cisco.com] > *Skickat:* den 11 februari 2014 18:25 > *Till:* Marc Blanchet > *Kopia:* Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; > Simon Perreault > > > *=C3=84mne:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism= for > enterprise and ISPs > > > > > > On Feb 11, 2014, at 9:08 AM, Marc Blanchet > wrote: > > > > Le 2014-02-11 =C3=A0 00:39, Dan Wing a =C3=A9crit : > > > > > On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: > > > > Good to see there is a lot of interest for this milestone. But based on > the description here, it seems like we want to use TURN primarily to > identify WebRTC flows, as opposed to using it as a NAT traversal tool. Th= is > makes me concerned that we may be using the wrong technology to solve the > problem. > > > > +1. > > > > I would prefer allowing flows to establish themselves using their 'best' > path, and the best path is seldom through a TURN server. When we imagine > IPv6 in our future, we don't want to force an application-level proxy > (TURN) server on the path solely for traversing an IPv6 firewall. > > > > > > It seems this thread is conflating all the possible reasons / > justifications for TURN: > > * mobility > > * NAT traversal (both endpoints are behind endpoint-dependent mapping > NATs) > > * firewall traversal (firewall blocks UDP) > > * enhancing privacy > > > > Unfortunately the TURN server nor the endpoint really know which of those > use-cases is desired (by the user or by the IT network administrator) or > necessary (for the call to work at all). > > > > Dan, while I agree in principle, I doubt that a user could ever say "I > want mobility or I want NAT traversal". I think the user only want the ca= ll > to succeed, whatever the properties of its network point of attachment ar= e. > > > > So what can we do? Should the TURN server provide any and all services > the TURN client might possibly want, as that is what a robust TURN server > will do, and the endpoint should prefer TURN candidates over all others > because there might be some functionality / usefulness of TURN that the > user might gain through TURN (e.g., enhanced privacy)? > > > > -d > > > > > > > > This seems problematic. Perhaps we need a way to signal the desired > use-case ("trait"), or as Justin suggests, using a different technology f= or > some of these use-cases. > > > > -d > > > > > > > > > > On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl > wrote: > > Simon, > > Good questions - see inline below --> . > Some more thought is required! > > /Karl > > -----Ursprungligt meddelande----- > Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault > Skickat: den 10 februari 2014 15:16 > Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com > =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism f= or > enterprise and ISPs > > > Karl, > > It is great to see such enthusiasm! Thanks! > > I have a couple technical questions... > > Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > > - Note that to achieve some of the above points, TURN must be favored > > over STUN to enforce that the TURN-path actually is used. (The Anycast > > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) > > I understand the STUN vs TURN priority issue. But I don't see how anycast > affects it in any way. Can you please explain? > > --- Good point - I was a bit quick here (maybe too quick) > We have given this quite bit of thought, since even if a TURN server is > provided and discovered, CURRENT usage of ICE may suggest a candidate fro= m > the remote party that will make a connection without the need/usage of th= e > TURN server (that we wanted to be used for the good purposes listed). > > The only way we found around this, was to stop STUN through the IP defaul= t > gateway (like a restrictive Enterprise firewall does inhibiting ICE > connectivity, which others are concerned about...). Since the provisionin= g > of auto-discovery using the anycast mechanism, would be adding a route in= a > default gateway, adding a firewall rule to eat STUN packets would assure > that the provisioned TURN server actually becomes used (and not bypassed > "by accident"). (That was the thought behind the =E2=80=9Cautomatically= =E2=80=9D within > quotes.) > > BUT, since you brought up the question, assuming that we have the power t= o > enforce WebRTC usage of ICE, I believe a MUST requirement to use an > auto-discovered TURN server instead of STUN, would solve the same problem= . > However, thinking further (in relation to your next question - "anyone > could set up a badly-maintained" - enforcing such ICE usage may not be > good.) > > > > > - 3^rd The Anycast method below =E2=80=93 I see no problem > > > > It also has the advantage of encouraging (but not requiring) the > > STUN/TURN to be built in the default gateway or NAT/firewall/access > > router itself, with a second interface to a public IP address on the > > WAN side. (Current volume deployed, low cost NSP triple play modems > > usually have a quality assured level 2 or level 3 WAN pipe for just > > voice (and another for IPTV) =E2=80=93 The anycast discovered TURN-serv= er can > > be the access gateway to such quality pipe for WebRTC media, in a > > single NSP provided CPE, scaling from residential and up.) > > Suppose we define well-known anycast TURN server addresses. How would thi= s > not be subject to the same service quality issues that plagued 6to4? That > is, anyone could set up a badly-maintained, under-provisioned TURN server > and announce it over BGP to the world, as it was done for > 6to4 relays. Or just bad BGP outbound filter configuration. And how can w= e > prevent triangle routing? There is nothing guaranteeing that the anycast > server you see is being provided to you by your ISP, rather than a server > sitting on the other side of the planet. > > --- Good point - needs to be resolved. For this I don't have a ready > answer... > An auto-discovered TURN server must be trusted (whatever method it is > discovered by). We are trusting the one providing us with an IP address a= nd > default gateway anyway. It would be easy if we could reuse that trust, > instead of another mechanisms. > > Is there a good way for the browser to check that the anycast address is > not handled beyond the network service provider's default gateway? Ideas? > > > > > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > --089e013a16442320e604f23db165 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed, but enterprises are already doing this with HTTP p= roxies, so the precedent (and mechanisms that can be used) are much clearer= .


On Wed= , Feb 12, 2014 at 11:30 AM, Hutton, Andrew <andrew.hutton@unify.com<= /a>> wrote:

The case where the TURN s= erver is the only option may become common within enterprise networks and t= hat might be deliberate enterprise policy because it provides the better path (UDP through the F/W) and protects the users and the netwo= rk.

=C2=A0

Andy=

=C2=A0

=C2=A0

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Justin Uberti
Sent: 12 February 2014 17:46


To: Muthu Arul Mozhi Perumal (mperumal)
Cc: ti= reddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing = (dwing); Karl Stahl

Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

=C2=A0

Agree. If TURN is indeed being provided for the user= 's benefit, the client's ICE logic (based on RTT or similar) should= result in it preferring the TURN path.

=C2=A0<= /p>

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Pe= rumal (mperumal) <mperumal@cisco.com> wrote:

Yes, I believe the second case is rare, but would be bette= r than a rat race b/w administrators trying to block p2p traffic and force it through a TURN server and apps/endpoints finding smarter ways= to bypass them.

=C2=A0

Muthu

=C2=A0

From: Oleg Mos= kalenko [mailto:mo= m040267@gmail.com]
Sent: Wednesday, February 12, 2014 1:07 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault


Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

=C2=A0

The TURN server has to be used when it is either the= only option, or if it provides a better path (I guess the second case is r= ather rare).

=C2=A0<= /p>

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi P= erumal (mperumal) <mperumal@cisco.com> wrote:

+1

=C2=A0

Forcing all traffic through a TURN server and expecting it= would provide the best user experience doesn't look the right approach. Instead, if a path through a TURN server exists and does provide= lower RTT, jitter etc, being able to detect and use (or switch to) that pa= th might be desirable..

=C2=A0

Muthu

=C2=A0

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl
Cc: tireddy@= icisco.com; Marc Blanchet; tram@ietf.org; Dan W= ing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

=C2=A0

Inline.

=C2=A0

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex= .se> wrote:

Listening to this thread, I am= afraid we are missing the very point and necessity for this milestone!

- There are severe NAT travers= al and quality issues that should and can be dealt with by a good auto-disc= overy mechanism and the right usage by the turn client (the WebRTC browser)

=C2=A0

There are ways, not only: Enterprises or ISPs wishing to provide their own TURN server, in an attemp= t to reduce so-called "triangle routing",need a new auto-discover= y mechanism

But also: - NSPs (Network Serv= ice Providers) want to provide a path where the bandwidth of WebRTC is bett= er coped with.

- NSPs or Enterprises want to = offer an Internet access quality pipe for prioritized RTC (Real Time Commun= ication) traffic.

- Enterprises having restricti= ve firewalls, want to provide a UDP-path for WebRTC and possibly also for better quality where RTC do not compete with data traffic. <= u>

Also considering=

- Mobility; It is common to mo= ve from a LAN to accessing via WiFi or 3G/4G OTT channels, all should be able to automatically offer their own optimal TURN server=

=C2=A0

This leads us into =C2=A0=E2=80=9CTURN=E2=80=A6to identify WebRTC flows= =E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

=C2=A0

Again, it has not been demonstrated why TURN is the = right technology here, compared to a more transparent flow identification t= ool like MALICE. We don't force all HTTP requests to locate a HTTP proxy via anycast, I don't see why we need to do the = same for WebRTC.=C2=A0

=C2=A0

What are the hesitations raise= d here?

> TURN primarily to identify WebRTC= flows, as opposed to using it as a NAT traversal tool. This makes me conce= rned that we may be using the wrong technology to solve the problem

It is correct that ICE/STUN/TU= RN was designed to address the NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw= /problem is that quality things were not (could not be?) considered. The me= thod=E2=80=99s very idea (like all similar methods for getting RTC through = ordinary NAT/Firewalls) is to fool the media through a NAT/Firewall that is unaware of what is happening. Thus, this is= root of quality issues (and bandwidth allocation optimization) that needs = to be dealt with: Real-time traffic fighting with a data traffic crowded co= ngestion point.

=C2=A0

I think that "fooling" is an incorrect des= cription. The NAT is supposed to be transparent to the client.

=C2=A0

But, a BLESSING of ICE/STUN/TU= RN is that it can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. J

ICE is a pre-protocol you use = because you want a path for real-time media between parties. Here: The brow= ser says knock knock, I want to get media through (and of course with as good = quality as required and possible).

=C2=A0

If the NAT/Firewall owner and = network owner are allowed to see these requests, they can help/assist in achieving the good media path. If they are not aware, they cannot help!

=C2=A0

Hope this made it understandab= le on an overview level how this can become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D

It is also the ONLY way I can = see to achieve what we want to achieve and should be the aim and requiremen= t of this milestone.

=C2=A0

I am talking about general usa= ge of WebRTC over Internet/mobile OTT (not feeding WebRTC into application specific networks like IMS where other methods may exist). <= u>

=C2=A0

This is good, not evil!=

=C2=A0

If the hesitations are raised = because of a belief/hope/wish that there are no or will not be severe quali= ty issues =E2=80=9Cbecause it is all about bandwidth=E2=80=9D, =E2=80=9Cit wi= ll resolve itself with time=E2=80=9D etc., I strongly object! That is wrong= and will be very detrimental for WebRTC usage. We already see it and I can= give numerous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad= considering quality issues and allowing/encouraging methods to deal with t= hem?

=C2=A0

If the hesitations are raised,= because of suspicion that the methods we may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to protect income from carrier telep= hony traffic), I could understand and would fight the same battle. But hope= fully, those days are (soon) over =E2=80=93 At least forward thinking carri= er=E2=80=99s realize that already. Web RTC will happen. Which customers want to pay for an access with blocked WebRTC? The= carrier=E2=80=99s offering/assuring good WebRTC will rather get the custom= ers and income J<= /span>. (Maybe the Web browser can detect and encoura= ge this=E2=80=A6)=C2=A0

=C2=A0

If there are technical concern= s of bad result, or better methods allowing network providers and LAN manag= ers to offer and inform the browser that there are good media paths to be used= , and that the web browser automatically can chose those, then let us all u= nderstand those, so we can achieve what should be achieved by this mileston= e.

=C2=A0

Skype, Hangouts, Facetime are doing billions of minu= tes per week and the Internet has not melted yet. If we need to do flow ide= ntification to allow traffic to be prioritized, fine (see above regarding my preferred approach), but forcing all WebRTC traffi= c through a MITM (TURN server) is a much bigger jump that I don't yet s= ee the justification for.

=C2=A0

In short: TURN is a technology that is supposed to f= ade away with the move to IPv6. I don't think we want to make it a crit= ical element of WebRTC.

=C2=A0

/Karl

=C2=A0

=C2=A0

Fr=C3=A5n: Dan= Wing [mailto:dwing@ci= sco.com]
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon Perreault


=C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechan= ism for enterprise and ISPs

=C2=A0

=C2=A0

On Feb 11, 2014, at 9:08 AM, Marc = Blanchet <marc.blanchet@viagenie.ca> wrote:

=C2= =A0

Le 2014-02-11 =C3=A0 00:39, Dan Wi= ng <dwing@cisco.com= > a =C3=A9crit :

=C2= =A0


On Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> wrote:=

=C2= =A0

Good to see there is a lot= of interest for this milestone. But based on the description here, it seem= s like we want to use TURN primarily to identify WebRTC flows, as opposed to= using it as a NAT traversal tool. This makes me concerned that we may be u= sing the wrong technology to solve the problem.

=C2=A0

+1.

=C2=A0

I would prefer allowing fl= ows to establish themselves using their 'best' path, and the best p= ath is seldom through a TURN server. =C2=A0When we imagine IPv6 in our future, we= don't want to force an application-level proxy (TURN) server on the pa= th solely for traversing an IPv6 firewall.

=C2=A0

=C2=A0

It seems this thread is co= nflating all the possible reasons / justifications for TURN:<= u>

=C2=A0 * mobility

=C2=A0 * NAT traversal (bo= th endpoints are behind endpoint-dependent mapping NATs)

=C2=A0 *=C2=A0firewall tra= versal (firewall blocks UDP)

=C2=A0 * enhancing privacy=

=C2=A0

Unfortunately the TURN ser= ver nor the endpoint really know which of those use-cases is desired (by th= e user or by the IT network administrator) or necessary (for the call to wor= k at all).

=C2=A0

Dan, while I agree in principle, I= doubt that a user could ever say "I want mobility or I want NAT trave= rsal". I think the user only want the call to succeed, whatever the properties of its network point of attachment are.

=C2=A0

So what can we do? =C2=A0Should th= e TURN server provide any and all services the TURN client might possibly w= ant, as that is what a robust TURN server will do, and the endpoint should prefer TURN candidates over all others because there might= be some functionality / usefulness of TURN that the user might gain throug= h TURN (e.g., enhanced privacy)?

=C2=A0

-d

=C2=A0

=C2=A0

=C2= =A0

=C2=A0This seems problemat= ic. =C2=A0Perhaps we need a way to signal the desired use-case ("trait= "), or as Justin suggests, using a different technology for some of these use-cases.=

=C2=A0

-d

=C2=A0

=C2=A0

=C2= =A0

=C2=A0

On Mon, Feb 10, 2014 at 3:= 18 PM, Karl Stahl=C2=A0<karl.stahl@intertex.se>=C2=A0wrote:=

Simon,

Good questions - see inline below --> .
Some more thought is required!

/Karl

-----Ursprungligt meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl;=C2=A0t= ram@ietf.org;=C2=A0tireddy@icisco.com
=C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for= enterprise and ISPs


Karl,

It is great to see such enthusiasm! Thanks!

I have a couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit :
> - Note that to achieve some of the above points, TURN must be favored<= br> > over STUN to enforce that the TURN-path actually is used. (The Anycast=
> method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.)
I understand the STUN vs TURN priority issue. But I don't see how anyca= st affects it in any way. Can you please explain?

--- Good point - I was a b= it quick here (maybe too quick)
We have given this quite bit of thought, since even if a TURN server is pro= vided and discovered, CURRENT usage of ICE may suggest a candidate from the= remote party that will make a connection without the need/usage of the TUR= N server (that we wanted to be used for the good purposes listed).

The only way we found around this, was to stop STUN through the IP default = gateway (like a restrictive Enterprise firewall does inhibiting ICE connect= ivity, which others are concerned about...). Since the provisioning of auto= -discovery using the anycast mechanism, would be adding a route in a default gateway, adding a firewall rule to ea= t STUN packets would assure that the provisioned TURN server actually becom= es used (and not bypassed "by accident"). (That was the thought b= ehind the =E2=80=9Cautomatically=E2=80=9D within quotes.)

BUT, since you brought up the question, assuming that we have the power to = enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-di= scovered TURN server instead of STUN, would solve the same problem. However= , thinking further (in relation to your next question - "anyone could set up a badly-maintained"= - enforcing such ICE usage may not be good.)



> - 3^rd The Anycast method below =E2=80=93 I see no problem
>
> It also has the advantage of encouraging (but not requiring) the
> STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered TURN-ser= ver can
> be the access gateway to such quality pipe for WebRTC media, in a
> single NSP provided CPE, scaling from residential and up.)

Suppose we define well-known anycast TURN server addresses. How would this = not be subject to the same service quality issues that plagued 6to4? That i= s, anyone could set up a badly-maintained, under-provisioned TURN server an= d announce it over BGP to the world, as it was done for
6to4 relays. Or just bad BGP outbound filter configuration. And how can we = prevent triangle routing? There is nothing guaranteeing that the anycast se= rver you see is being provided to you by your ISP, rather than a server sit= ting on the other side of the planet.

--- Good point - needs to = be resolved. For this I don't have a ready answer...
An auto-discovered TURN server must be trusted (whatever method it is disco= vered by). We are trusting the one providing us with an IP address and defa= ult gateway anyway. It would be easy if we could reuse that trust, instead = of another mechanisms.

Is there a good way for the browser to check that the anycast address is no= t handled beyond the network service provider's default gateway? Ideas?=




Thanks,
Simon
--
DTN made easy, lean, and smart -->=C2=A0http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0-->=C2=A0http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -->=C2= =A0http://numb.viage= nie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

=C2=A0

__________________________= _____________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


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

=C2=A0

=C2=A0

=C2=A0


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

=C2=A0

=C2=A0


--089e013a16442320e604f23db165-- From tireddy@cisco.com Wed Feb 12 19:40:13 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BD31A00AF for ; Wed, 12 Feb 2014 19:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 PW5DsrShcUr2 for ; Wed, 12 Feb 2014 19:40:05 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E721C1A00AB for ; Wed, 12 Feb 2014 19:40:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=87982; q=dns/txt; s=iport; t=1392262804; x=1393472404; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=oSQeXFiDZ7BURdXJJybOLPc6HUDQdYEXxz22QxLCltQ=; b=Ah/zU2oNhcuqxNPH4GYbtN3SahpVNAwYGpjkXDZovyY/CD+YltjD85yj fXwRcqUb2VglktZMIb84TfrjRkalX7St6WKch9pem+UPp17K8Bd8ouZdK go2cExV2kosI8F3eE2SLGUx9k+qGbdFBWYEQ5OhAWPy2o6LRzidizmTa3 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAHAO09/FKtJV2c/2dsb2JhbABPCoJGRDhXgwCnYowDiFQYfxZ0giUBAQEDAQEBARcBCAQGOgUCBAQICwIBCBEEAQELFgEGAwICAh8GCxQJCAIEARIIh2kDCQgNpXuZWQ2IPBeMX4EuEA4dFhcKAYJvNYEUBJY/gx6LLIVDgW+BPoFxOQ X-IronPort-AV: E=Sophos;i="4.95,836,1384300800"; d="scan'208,217";a="303685705" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 13 Feb 2014 03:40:03 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1D3e2CC003095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 03:40:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Wed, 12 Feb 2014 21:40:02 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Hutton, Andrew" , "tram@ietf.org" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPJ7mltnD+pGokzkuj47s9ptfvbZqxnjCAgAABbgCAAB7xgIAAizSAgAAdCoCAACQrEA== Date: Thu, 13 Feb 2014 03:40:01 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242AD1F4@xmb-rcd-x10.cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> <9F33F40F6F2CD847824537F3C4E37DDF17CF2EDD@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17CF2EDD@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.43.47] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242AD1F4xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 03:40:13 -0000 --_000_913383AAA69FF945B8F946018B75898A242AD1F4xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhlcmUgYXJlIG90aGVyIHdheXMgdG8gc29sdmUgdGhlIHByb2JsZW0gZm9y IGV4YW1wbGUgdXNpbmcgUENQLiBDYW4geW91IGNsYXJpZnkgaG93IGRlcGxveWluZyBhIFRVUk4g c2VydmVyIGluIHRoZSBFbnRlcnByaXNlIHByb3RlY3RzIHRoZSB1c2VycyBhbmQgdGhlIG5ldHdv cmsgPw0KDQotVGlydS4NCkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBIdXR0b24sIEFuZHJldw0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDEz LCAyMDE0IDE6MDAgQU0NClRvOiBKdXN0aW4gVWJlcnRpOyBNdXRodSBBcnVsIE1vemhpIFBlcnVt YWwgKG1wZXJ1bWFsKQ0KQ2M6IHRpcmVkZHlAaWNpc2NvLmNvbTsgU2ltb24gUGVycmVhdWx0OyBP bGVnIE1vc2thbGVua287IHRyYW1AaWV0Zi5vcmc7IE1hcmMgQmxhbmNoZXQ7IERhbiBXaW5nIChk d2luZyk7IEthcmwgU3RhaGwNClN1YmplY3Q6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4g c2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0K DQpUaGUgY2FzZSB3aGVyZSB0aGUgVFVSTiBzZXJ2ZXIgaXMgdGhlIG9ubHkgb3B0aW9uIG1heSBi ZWNvbWUgY29tbW9uIHdpdGhpbiBlbnRlcnByaXNlIG5ldHdvcmtzIGFuZCB0aGF0IG1pZ2h0IGJl IGRlbGliZXJhdGUgZW50ZXJwcmlzZSBwb2xpY3kgYmVjYXVzZSBpdCBwcm92aWRlcyB0aGUgYmV0 dGVyIHBhdGggKFVEUCB0aHJvdWdoIHRoZSBGL1cpIGFuZCBwcm90ZWN0cyB0aGUgdXNlcnMgYW5k IHRoZSBuZXR3b3JrLg0KDQpBbmR5DQoNCg0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IDEyIEZlYnJ1YXJ5 IDIwMTQgMTc6NDYNClRvOiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KQ2M6 IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tPjsgU2ltb24gUGVy cmVhdWx0OyBPbGVnIE1vc2thbGVua287IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5v cmc+OyBNYXJjIEJsYW5jaGV0OyBEYW4gV2luZyAoZHdpbmcpOyBLYXJsIFN0YWhsDQpTdWJqZWN0 OiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNo YW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KQWdyZWUuIElmIFRVUk4gaXMgaW5kZWVk IGJlaW5nIHByb3ZpZGVkIGZvciB0aGUgdXNlcidzIGJlbmVmaXQsIHRoZSBjbGllbnQncyBJQ0Ug bG9naWMgKGJhc2VkIG9uIFJUVCBvciBzaW1pbGFyKSBzaG91bGQgcmVzdWx0IGluIGl0IHByZWZl cnJpbmcgdGhlIFRVUk4gcGF0aC4NCg0KT24gV2VkLCBGZWIgMTIsIDIwMTQgYXQgMToyNyBBTSwg TXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgPG1wZXJ1bWFsQGNpc2NvLmNvbTxt YWlsdG86bXBlcnVtYWxAY2lzY28uY29tPj4gd3JvdGU6DQpZZXMsIEkgYmVsaWV2ZSB0aGUgc2Vj b25kIGNhc2UgaXMgcmFyZSwgYnV0IHdvdWxkIGJlIGJldHRlciB0aGFuIGEgcmF0IHJhY2UgYi93 IGFkbWluaXN0cmF0b3JzIHRyeWluZyB0byBibG9jayBwMnAgdHJhZmZpYyBhbmQgZm9yY2UgaXQg dGhyb3VnaCBhIFRVUk4gc2VydmVyIGFuZCBhcHBzL2VuZHBvaW50cyBmaW5kaW5nIHNtYXJ0ZXIg d2F5cyB0byBieXBhc3MgdGhlbS4NCg0KTXV0aHUNCg0KRnJvbTogT2xlZyBNb3NrYWxlbmtvIFtt YWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbTxtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbT5dDQpT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0IDE6MDcgUE0NClRvOiBNdXRodSBBcnVs IE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KQ2M6IEp1c3RpbiBVYmVydGk7IEthcmwgU3RhaGw7 IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tPjsgTWFyYyBCbGFu Y2hldDsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IERhbiBXaW5nIChkd2lu Zyk7IFNpbW9uIFBlcnJlYXVsdA0KDQpTdWJqZWN0OiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBU VVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElT UHMNCg0KVGhlIFRVUk4gc2VydmVyIGhhcyB0byBiZSB1c2VkIHdoZW4gaXQgaXMgZWl0aGVyIHRo ZSBvbmx5IG9wdGlvbiwgb3IgaWYgaXQgcHJvdmlkZXMgYSBiZXR0ZXIgcGF0aCAoSSBndWVzcyB0 aGUgc2Vjb25kIGNhc2UgaXMgcmF0aGVyIHJhcmUpLg0KDQpPbiBUdWUsIEZlYiAxMSwgMjAxNCBh dCAxMTozMiBQTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgPG1wZXJ1bWFs QGNpc2NvLmNvbTxtYWlsdG86bXBlcnVtYWxAY2lzY28uY29tPj4gd3JvdGU6DQorMQ0KDQpGb3Jj aW5nIGFsbCB0cmFmZmljIHRocm91Z2ggYSBUVVJOIHNlcnZlciBhbmQgZXhwZWN0aW5nIGl0IHdv dWxkIHByb3ZpZGUgdGhlIGJlc3QgdXNlciBleHBlcmllbmNlIGRvZXNuJ3QgbG9vayB0aGUgcmln aHQgYXBwcm9hY2guIEluc3RlYWQsIGlmIGEgcGF0aCB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgZXhp c3RzIGFuZCBkb2VzIHByb3ZpZGUgbG93ZXIgUlRULCBqaXR0ZXIgZXRjLCBiZWluZyBhYmxlIHRv IGRldGVjdCBhbmQgdXNlIChvciBzd2l0Y2ggdG8pIHRoYXQgcGF0aCBtaWdodCBiZSBkZXNpcmFi bGUuLg0KDQpNdXRodQ0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0 aQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAxNCAxMTo0MyBBTQ0KVG86IEthcmwg U3RhaGwNCkNjOiB0aXJlZGR5QGljaXNjby5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT47 IE1hcmMgQmxhbmNoZXQ7IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+OyBEYW4g V2luZyAoZHdpbmcpOyBTaW1vbiBQZXJyZWF1bHQNClN1YmplY3Q6IFJlOiBbdHJhbV0gTWlsZXN0 b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlz ZSBhbmQgSVNQcw0KDQpJbmxpbmUuDQoNCk9uIFR1ZSwgRmViIDExLCAyMDE0IGF0IDI6MzcgUE0s IEthcmwgU3RhaGwgPGthcmwuc3RhaGxAaW50ZXJ0ZXguc2U8bWFpbHRvOmthcmwuc3RhaGxAaW50 ZXJ0ZXguc2U+PiB3cm90ZToNCkxpc3RlbmluZyB0byB0aGlzIHRocmVhZCwgSSBhbSBhZnJhaWQg d2UgYXJlIG1pc3NpbmcgdGhlIHZlcnkgcG9pbnQgYW5kIG5lY2Vzc2l0eSBmb3IgdGhpcyBtaWxl c3RvbmUhDQotIFRoZXJlIGFyZSBzZXZlcmUgTkFUIHRyYXZlcnNhbCBhbmQgcXVhbGl0eSBpc3N1 ZXMgdGhhdCBzaG91bGQgYW5kIGNhbiBiZSBkZWFsdCB3aXRoIGJ5IGEgZ29vZCBhdXRvLWRpc2Nv dmVyeSBtZWNoYW5pc20gYW5kIHRoZSByaWdodCB1c2FnZSBieSB0aGUgdHVybiBjbGllbnQgKHRo ZSBXZWJSVEMgYnJvd3NlcikNCg0KVGhlcmUgYXJlIHdheXMsIG5vdCBvbmx5OiBFbnRlcnByaXNl cyBvciBJU1BzIHdpc2hpbmcgdG8gcHJvdmlkZSB0aGVpciBvd24gVFVSTiBzZXJ2ZXIsIGluIGFu IGF0dGVtcHQgdG8gcmVkdWNlIHNvLWNhbGxlZCAidHJpYW5nbGUgcm91dGluZyIsbmVlZCBhIG5l dyBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20NCkJ1dCBhbHNvOiAtIE5TUHMgKE5ldHdvcmsgU2Vy dmljZSBQcm92aWRlcnMpIHdhbnQgdG8gcHJvdmlkZSBhIHBhdGggd2hlcmUgdGhlIGJhbmR3aWR0 aCBvZiBXZWJSVEMgaXMgYmV0dGVyIGNvcGVkIHdpdGguDQotIE5TUHMgb3IgRW50ZXJwcmlzZXMg d2FudCB0byBvZmZlciBhbiBJbnRlcm5ldCBhY2Nlc3MgcXVhbGl0eSBwaXBlIGZvciBwcmlvcml0 aXplZCBSVEMgKFJlYWwgVGltZSBDb21tdW5pY2F0aW9uKSB0cmFmZmljLg0KLSBFbnRlcnByaXNl cyBoYXZpbmcgcmVzdHJpY3RpdmUgZmlyZXdhbGxzLCB3YW50IHRvIHByb3ZpZGUgYSBVRFAtcGF0 aCBmb3IgV2ViUlRDIGFuZCBwb3NzaWJseSBhbHNvIGZvciBiZXR0ZXIgcXVhbGl0eSB3aGVyZSBS VEMgZG8gbm90IGNvbXBldGUgd2l0aCBkYXRhIHRyYWZmaWMuDQpBbHNvIGNvbnNpZGVyaW5nDQot IE1vYmlsaXR5OyBJdCBpcyBjb21tb24gdG8gbW92ZSBmcm9tIGEgTEFOIHRvIGFjY2Vzc2luZyB2 aWEgV2lGaSBvciAzRy80RyBPVFQgY2hhbm5lbHMsIGFsbCBzaG91bGQgYmUgYWJsZSB0byBhdXRv bWF0aWNhbGx5IG9mZmVyIHRoZWlyIG93biBvcHRpbWFsIFRVUk4gc2VydmVyDQoNClRoaXMgbGVh ZHMgdXMgaW50byAg4oCcVFVSTuKApnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnSBldGMhIEl0 IGlzIG5vdCBhIG1pc3Rha2UsIGJ1dCB0aGUgdmVyeSBuZWVkIGZvciB0aGlzIG1pbGVzdG9uZSEN Cg0KQWdhaW4sIGl0IGhhcyBub3QgYmVlbiBkZW1vbnN0cmF0ZWQgd2h5IFRVUk4gaXMgdGhlIHJp Z2h0IHRlY2hub2xvZ3kgaGVyZSwgY29tcGFyZWQgdG8gYSBtb3JlIHRyYW5zcGFyZW50IGZsb3cg aWRlbnRpZmljYXRpb24gdG9vbCBsaWtlIE1BTElDRS4gV2UgZG9uJ3QgZm9yY2UgYWxsIEhUVFAg cmVxdWVzdHMgdG8gbG9jYXRlIGEgSFRUUCBwcm94eSB2aWEgYW55Y2FzdCwgSSBkb24ndCBzZWUg d2h5IHdlIG5lZWQgdG8gZG8gdGhlIHNhbWUgZm9yIFdlYlJUQy4NCg0KV2hhdCBhcmUgdGhlIGhl c2l0YXRpb25zIHJhaXNlZCBoZXJlPw0KPiBUVVJOIHByaW1hcmlseSB0byBpZGVudGlmeSBXZWJS VEMgZmxvd3MsIGFzIG9wcG9zZWQgdG8gdXNpbmcgaXQgYXMgYSBOQVQgdHJhdmVyc2FsIHRvb2wu IFRoaXMgbWFrZXMgbWUgY29uY2VybmVkIHRoYXQgd2UgbWF5IGJlIHVzaW5nIHRoZSB3cm9uZyB0 ZWNobm9sb2d5IHRvIHNvbHZlIHRoZSBwcm9ibGVtDQpJdCBpcyBjb3JyZWN0IHRoYXQgSUNFL1NU VU4vVFVSTiB3YXMgZGVzaWduZWQgdG8gYWRkcmVzcyB0aGUgTkFUL0ZpcmV3YWxsIHRyYXZlcnNh bCBwcm9ibGVtIGFzc29jaWF0ZWQgd2l0aCByZWFsLXRpbWUgY29tbXVuaWNhdGlvbiAoU0lQIGF0 IHRoYXQgdGltZSkuIEhvd2V2ZXIsIGl0cyBsYXJnZXN0IGZsYXcvcHJvYmxlbSBpcyB0aGF0IHF1 YWxpdHkgdGhpbmdzIHdlcmUgbm90IChjb3VsZCBub3QgYmU/KSBjb25zaWRlcmVkLiBUaGUgbWV0 aG9k4oCZcyB2ZXJ5IGlkZWEgKGxpa2UgYWxsIHNpbWlsYXIgbWV0aG9kcyBmb3IgZ2V0dGluZyBS VEMgdGhyb3VnaCBvcmRpbmFyeSBOQVQvRmlyZXdhbGxzKSBpcyB0byBmb29sIHRoZSBtZWRpYSB0 aHJvdWdoIGEgTkFUL0ZpcmV3YWxsIHRoYXQgaXMgdW5hd2FyZSBvZiB3aGF0IGlzIGhhcHBlbmlu Zy4gVGh1cywgdGhpcyBpcyByb290IG9mIHF1YWxpdHkgaXNzdWVzIChhbmQgYmFuZHdpZHRoIGFs bG9jYXRpb24gb3B0aW1pemF0aW9uKSB0aGF0IG5lZWRzIHRvIGJlIGRlYWx0IHdpdGg6IFJlYWwt dGltZSB0cmFmZmljIGZpZ2h0aW5nIHdpdGggYSBkYXRhIHRyYWZmaWMgY3Jvd2RlZCBjb25nZXN0 aW9uIHBvaW50Lg0KDQpJIHRoaW5rIHRoYXQgImZvb2xpbmciIGlzIGFuIGluY29ycmVjdCBkZXNj cmlwdGlvbi4gVGhlIE5BVCBpcyBzdXBwb3NlZCB0byBiZSB0cmFuc3BhcmVudCB0byB0aGUgY2xp ZW50Lg0KDQpCdXQsIGEgQkxFU1NJTkcgb2YgSUNFL1NUVU4vVFVSTiBpcyB0aGF0IGl0IGNhbiBi ZSBzZWVuIGFzIGEgbGVnaXRpbWF0ZSByZXF1ZXN0IGZvciBhIHN1aXRhYmxlIHBpcGUgZm9yIHF1 YWxpdHkgZGVtYW5kaW5nIHJlYWwgdGltZSB0cmFmZmljLiDimLoNCklDRSBpcyBhIHByZS1wcm90 b2NvbCB5b3UgdXNlIGJlY2F1c2UgeW91IHdhbnQgYSBwYXRoIGZvciByZWFsLXRpbWUgbWVkaWEg YmV0d2VlbiBwYXJ0aWVzLiBIZXJlOiBUaGUgYnJvd3NlciBzYXlzIGtub2NrIGtub2NrLCBJIHdh bnQgdG8gZ2V0IG1lZGlhIHRocm91Z2ggKGFuZCBvZiBjb3Vyc2Ugd2l0aCBhcyBnb29kIHF1YWxp dHkgYXMgcmVxdWlyZWQgYW5kIHBvc3NpYmxlKS4NCg0KSWYgdGhlIE5BVC9GaXJld2FsbCBvd25l ciBhbmQgbmV0d29yayBvd25lciBhcmUgYWxsb3dlZCB0byBzZWUgdGhlc2UgcmVxdWVzdHMsIHRo ZXkgY2FuIGhlbHAvYXNzaXN0IGluIGFjaGlldmluZyB0aGUgZ29vZCBtZWRpYSBwYXRoLiBJZiB0 aGV5IGFyZSBub3QgYXdhcmUsIHRoZXkgY2Fubm90IGhlbHAhDQoNCkhvcGUgdGhpcyBtYWRlIGl0 IHVuZGVyc3RhbmRhYmxlIG9uIGFuIG92ZXJ2aWV3IGxldmVsIGhvdyB0aGlzIGNhbiBiZWNvbWUg 4oCcVFVSTuKApnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnQ0KSXQgaXMgYWxzbyB0aGUgT05M WSB3YXkgSSBjYW4gc2VlIHRvIGFjaGlldmUgd2hhdCB3ZSB3YW50IHRvIGFjaGlldmUgYW5kIHNo b3VsZCBiZSB0aGUgYWltIGFuZCByZXF1aXJlbWVudCBvZiB0aGlzIG1pbGVzdG9uZS4NCg0KSSBh bSB0YWxraW5nIGFib3V0IGdlbmVyYWwgdXNhZ2Ugb2YgV2ViUlRDIG92ZXIgSW50ZXJuZXQvbW9i aWxlIE9UVCAobm90IGZlZWRpbmcgV2ViUlRDIGludG8gYXBwbGljYXRpb24gc3BlY2lmaWMgbmV0 d29ya3MgbGlrZSBJTVMgd2hlcmUgb3RoZXIgbWV0aG9kcyBtYXkgZXhpc3QpLg0KDQpUaGlzIGlz IGdvb2QsIG5vdCBldmlsIQ0KDQpJZiB0aGUgaGVzaXRhdGlvbnMgYXJlIHJhaXNlZCBiZWNhdXNl IG9mIGEgYmVsaWVmL2hvcGUvd2lzaCB0aGF0IHRoZXJlIGFyZSBubyBvciB3aWxsIG5vdCBiZSBz ZXZlcmUgcXVhbGl0eSBpc3N1ZXMg4oCcYmVjYXVzZSBpdCBpcyBhbGwgYWJvdXQgYmFuZHdpZHRo 4oCdLCDigJxpdCB3aWxsIHJlc29sdmUgaXRzZWxmIHdpdGggdGltZeKAnSBldGMuLCBJIHN0cm9u Z2x5IG9iamVjdCEgVGhhdCBpcyB3cm9uZyBhbmQgd2lsbCBiZSB2ZXJ5IGRldHJpbWVudGFsIGZv ciBXZWJSVEMgdXNhZ2UuIFdlIGFscmVhZHkgc2VlIGl0IGFuZCBJIGNhbiBnaXZlIG51bWVyb3Vz IGV4YW1wbGVzIG9mIGhvdyBtdWNoIGxlc3MgcXVhbGl0eSBkZW1hbmRpbmcgVm9JUCBpcy9pcyBu b3QgaGFuZGxlZCBxdWFsaXR5IHdpc2UgYW5kIHRoYXQgaXQgbWF0dGVycy4gQW5kLCB3aGF0IHdv dWxkIGJlIGJhZCBjb25zaWRlcmluZyBxdWFsaXR5IGlzc3VlcyBhbmQgYWxsb3dpbmcvZW5jb3Vy YWdpbmcgbWV0aG9kcyB0byBkZWFsIHdpdGggdGhlbT8NCg0KSWYgdGhlIGhlc2l0YXRpb25zIGFy ZSByYWlzZWQsIGJlY2F1c2Ugb2Ygc3VzcGljaW9uIHRoYXQgdGhlIG1ldGhvZHMgd2UgbWF5IHJl Y29tbWVuZCBtYXkgYmUgbWlzdXNlZCB0byBzdG9wL2Jsb2NrL2Rlc3Ryb3kgV2ViUlRDIHVzYWdl IChlLmcuIHRvIHByb3RlY3QgaW5jb21lIGZyb20gY2FycmllciB0ZWxlcGhvbnkgdHJhZmZpYyks IEkgY291bGQgdW5kZXJzdGFuZCBhbmQgd291bGQgZmlnaHQgdGhlIHNhbWUgYmF0dGxlLiBCdXQg aG9wZWZ1bGx5LCB0aG9zZSBkYXlzIGFyZSAoc29vbikgb3ZlciDigJMgQXQgbGVhc3QgZm9yd2Fy ZCB0aGlua2luZyBjYXJyaWVy4oCZcyByZWFsaXplIHRoYXQgYWxyZWFkeS4gV2ViIFJUQyB3aWxs IGhhcHBlbi4gV2hpY2ggY3VzdG9tZXJzIHdhbnQgdG8gcGF5IGZvciBhbiBhY2Nlc3Mgd2l0aCBi bG9ja2VkIFdlYlJUQz8gVGhlIGNhcnJpZXLigJlzIG9mZmVyaW5nL2Fzc3VyaW5nIGdvb2QgV2Vi UlRDIHdpbGwgcmF0aGVyIGdldCB0aGUgY3VzdG9tZXJzIGFuZCBpbmNvbWUg4pi6LiAoTWF5YmUg dGhlIFdlYiBicm93c2VyIGNhbiBkZXRlY3QgYW5kIGVuY291cmFnZSB0aGlz4oCmKQ0KDQpJZiB0 aGVyZSBhcmUgdGVjaG5pY2FsIGNvbmNlcm5zIG9mIGJhZCByZXN1bHQsIG9yIGJldHRlciBtZXRo b2RzIGFsbG93aW5nIG5ldHdvcmsgcHJvdmlkZXJzIGFuZCBMQU4gbWFuYWdlcnMgdG8gb2ZmZXIg YW5kIGluZm9ybSB0aGUgYnJvd3NlciB0aGF0IHRoZXJlIGFyZSBnb29kIG1lZGlhIHBhdGhzIHRv IGJlIHVzZWQsIGFuZCB0aGF0IHRoZSB3ZWIgYnJvd3NlciBhdXRvbWF0aWNhbGx5IGNhbiBjaG9z ZSB0aG9zZSwgdGhlbiBsZXQgdXMgYWxsIHVuZGVyc3RhbmQgdGhvc2UsIHNvIHdlIGNhbiBhY2hp ZXZlIHdoYXQgc2hvdWxkIGJlIGFjaGlldmVkIGJ5IHRoaXMgbWlsZXN0b25lLg0KDQpTa3lwZSwg SGFuZ291dHMsIEZhY2V0aW1lIGFyZSBkb2luZyBiaWxsaW9ucyBvZiBtaW51dGVzIHBlciB3ZWVr IGFuZCB0aGUgSW50ZXJuZXQgaGFzIG5vdCBtZWx0ZWQgeWV0LiBJZiB3ZSBuZWVkIHRvIGRvIGZs b3cgaWRlbnRpZmljYXRpb24gdG8gYWxsb3cgdHJhZmZpYyB0byBiZSBwcmlvcml0aXplZCwgZmlu ZSAoc2VlIGFib3ZlIHJlZ2FyZGluZyBteSBwcmVmZXJyZWQgYXBwcm9hY2gpLCBidXQgZm9yY2lu ZyBhbGwgV2ViUlRDIHRyYWZmaWMgdGhyb3VnaCBhIE1JVE0gKFRVUk4gc2VydmVyKSBpcyBhIG11 Y2ggYmlnZ2VyIGp1bXAgdGhhdCBJIGRvbid0IHlldCBzZWUgdGhlIGp1c3RpZmljYXRpb24gZm9y Lg0KDQpJbiBzaG9ydDogVFVSTiBpcyBhIHRlY2hub2xvZ3kgdGhhdCBpcyBzdXBwb3NlZCB0byBm YWRlIGF3YXkgd2l0aCB0aGUgbW92ZSB0byBJUHY2LiBJIGRvbid0IHRoaW5rIHdlIHdhbnQgdG8g bWFrZSBpdCBhIGNyaXRpY2FsIGVsZW1lbnQgb2YgV2ViUlRDLg0KDQovS2FybA0KDQoNCkZyw6Vu OiBEYW4gV2luZyBbbWFpbHRvOmR3aW5nQGNpc2NvLmNvbTxtYWlsdG86ZHdpbmdAY2lzY28uY29t Pl0NClNraWNrYXQ6IGRlbiAxMSBmZWJydWFyaSAyMDE0IDE4OjI1DQpUaWxsOiBNYXJjIEJsYW5j aGV0DQpLb3BpYTogSnVzdGluIFViZXJ0aTsgdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJl ZGR5QGljaXNjby5jb20+OyBLYXJsIFN0YWhsOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGll dGYub3JnPjsgU2ltb24gUGVycmVhdWx0DQoNCsOEbW5lOiBSZTogW3RyYW1dIE1pbGVzdG9uZSAz OiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5k IElTUHMNCg0KDQpPbiBGZWIgMTEsIDIwMTQsIGF0IDk6MDggQU0sIE1hcmMgQmxhbmNoZXQgPG1h cmMuYmxhbmNoZXRAdmlhZ2VuaWUuY2E8bWFpbHRvOm1hcmMuYmxhbmNoZXRAdmlhZ2VuaWUuY2E+ PiB3cm90ZToNCg0KTGUgMjAxNC0wMi0xMSDDoCAwMDozOSwgRGFuIFdpbmcgPGR3aW5nQGNpc2Nv LmNvbTxtYWlsdG86ZHdpbmdAY2lzY28uY29tPj4gYSDDqWNyaXQgOg0KDQoNCk9uIEZlYiAxMCwg MjAxNCwgYXQgNTozMCBQTSwgSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29tPG1haWx0 bzpqdWJlcnRpQGdvb2dsZS5jb20+PiB3cm90ZToNCg0KR29vZCB0byBzZWUgdGhlcmUgaXMgYSBs b3Qgb2YgaW50ZXJlc3QgZm9yIHRoaXMgbWlsZXN0b25lLiBCdXQgYmFzZWQgb24gdGhlIGRlc2Ny aXB0aW9uIGhlcmUsIGl0IHNlZW1zIGxpa2Ugd2Ugd2FudCB0byB1c2UgVFVSTiBwcmltYXJpbHkg dG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dzLCBhcyBvcHBvc2VkIHRvIHVzaW5nIGl0IGFzIGEgTkFU IHRyYXZlcnNhbCB0b29sLiBUaGlzIG1ha2VzIG1lIGNvbmNlcm5lZCB0aGF0IHdlIG1heSBiZSB1 c2luZyB0aGUgd3JvbmcgdGVjaG5vbG9neSB0byBzb2x2ZSB0aGUgcHJvYmxlbS4NCg0KKzEuDQoN Ckkgd291bGQgcHJlZmVyIGFsbG93aW5nIGZsb3dzIHRvIGVzdGFibGlzaCB0aGVtc2VsdmVzIHVz aW5nIHRoZWlyICdiZXN0JyBwYXRoLCBhbmQgdGhlIGJlc3QgcGF0aCBpcyBzZWxkb20gdGhyb3Vn aCBhIFRVUk4gc2VydmVyLiAgV2hlbiB3ZSBpbWFnaW5lIElQdjYgaW4gb3VyIGZ1dHVyZSwgd2Ug ZG9uJ3Qgd2FudCB0byBmb3JjZSBhbiBhcHBsaWNhdGlvbi1sZXZlbCBwcm94eSAoVFVSTikgc2Vy dmVyIG9uIHRoZSBwYXRoIHNvbGVseSBmb3IgdHJhdmVyc2luZyBhbiBJUHY2IGZpcmV3YWxsLg0K DQoNCkl0IHNlZW1zIHRoaXMgdGhyZWFkIGlzIGNvbmZsYXRpbmcgYWxsIHRoZSBwb3NzaWJsZSBy ZWFzb25zIC8ganVzdGlmaWNhdGlvbnMgZm9yIFRVUk46DQogICogbW9iaWxpdHkNCiAgKiBOQVQg dHJhdmVyc2FsIChib3RoIGVuZHBvaW50cyBhcmUgYmVoaW5kIGVuZHBvaW50LWRlcGVuZGVudCBt YXBwaW5nIE5BVHMpDQogICogZmlyZXdhbGwgdHJhdmVyc2FsIChmaXJld2FsbCBibG9ja3MgVURQ KQ0KICAqIGVuaGFuY2luZyBwcml2YWN5DQoNClVuZm9ydHVuYXRlbHkgdGhlIFRVUk4gc2VydmVy IG5vciB0aGUgZW5kcG9pbnQgcmVhbGx5IGtub3cgd2hpY2ggb2YgdGhvc2UgdXNlLWNhc2VzIGlz IGRlc2lyZWQgKGJ5IHRoZSB1c2VyIG9yIGJ5IHRoZSBJVCBuZXR3b3JrIGFkbWluaXN0cmF0b3Ip IG9yIG5lY2Vzc2FyeSAoZm9yIHRoZSBjYWxsIHRvIHdvcmsgYXQgYWxsKS4NCg0KRGFuLCB3aGls ZSBJIGFncmVlIGluIHByaW5jaXBsZSwgSSBkb3VidCB0aGF0IGEgdXNlciBjb3VsZCBldmVyIHNh eSAiSSB3YW50IG1vYmlsaXR5IG9yIEkgd2FudCBOQVQgdHJhdmVyc2FsIi4gSSB0aGluayB0aGUg dXNlciBvbmx5IHdhbnQgdGhlIGNhbGwgdG8gc3VjY2VlZCwgd2hhdGV2ZXIgdGhlIHByb3BlcnRp ZXMgb2YgaXRzIG5ldHdvcmsgcG9pbnQgb2YgYXR0YWNobWVudCBhcmUuDQoNClNvIHdoYXQgY2Fu IHdlIGRvPyAgU2hvdWxkIHRoZSBUVVJOIHNlcnZlciBwcm92aWRlIGFueSBhbmQgYWxsIHNlcnZp Y2VzIHRoZSBUVVJOIGNsaWVudCBtaWdodCBwb3NzaWJseSB3YW50LCBhcyB0aGF0IGlzIHdoYXQg YSByb2J1c3QgVFVSTiBzZXJ2ZXIgd2lsbCBkbywgYW5kIHRoZSBlbmRwb2ludCBzaG91bGQgcHJl ZmVyIFRVUk4gY2FuZGlkYXRlcyBvdmVyIGFsbCBvdGhlcnMgYmVjYXVzZSB0aGVyZSBtaWdodCBi ZSBzb21lIGZ1bmN0aW9uYWxpdHkgLyB1c2VmdWxuZXNzIG9mIFRVUk4gdGhhdCB0aGUgdXNlciBt aWdodCBnYWluIHRocm91Z2ggVFVSTiAoZS5nLiwgZW5oYW5jZWQgcHJpdmFjeSk/DQoNCi1kDQoN Cg0KDQogVGhpcyBzZWVtcyBwcm9ibGVtYXRpYy4gIFBlcmhhcHMgd2UgbmVlZCBhIHdheSB0byBz aWduYWwgdGhlIGRlc2lyZWQgdXNlLWNhc2UgKCJ0cmFpdCIpLCBvciBhcyBKdXN0aW4gc3VnZ2Vz dHMsIHVzaW5nIGEgZGlmZmVyZW50IHRlY2hub2xvZ3kgZm9yIHNvbWUgb2YgdGhlc2UgdXNlLWNh c2VzLg0KDQotZA0KDQoNCg0KDQpPbiBNb24sIEZlYiAxMCwgMjAxNCBhdCAzOjE4IFBNLCBLYXJs IFN0YWhsIDxrYXJsLnN0YWhsQGludGVydGV4LnNlPG1haWx0bzprYXJsLnN0YWhsQGludGVydGV4 LnNlPj4gd3JvdGU6DQpTaW1vbiwNCg0KR29vZCBxdWVzdGlvbnMgLSBzZWUgaW5saW5lIGJlbG93 IC0tPiAuDQpTb21lIG1vcmUgdGhvdWdodCBpcyByZXF1aXJlZCENCg0KL0thcmwNCg0KLS0tLS1V cnNwcnVuZ2xpZ3QgbWVkZGVsYW5kZS0tLS0tDQpGcsOlbjogdHJhbSBbbWFpbHRvOnRyYW0tYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPl0gRsO2ciBTaW1vbiBQ ZXJyZWF1bHQNClNraWNrYXQ6IGRlbiAxMCBmZWJydWFyaSAyMDE0IDE1OjE2DQpUaWxsOiBLYXJs IFN0YWhsOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPjsgdGlyZWRkeUBpY2lz Y28uY29tPG1haWx0bzp0aXJlZGR5QGljaXNjby5jb20+DQrDhG1uZTogUmU6IFt0cmFtXSBNaWxl c3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnBy aXNlIGFuZCBJU1BzDQoNCkthcmwsDQoNCkl0IGlzIGdyZWF0IHRvIHNlZSBzdWNoIGVudGh1c2lh c20hIFRoYW5rcyENCg0KSSBoYXZlIGEgY291cGxlIHRlY2huaWNhbCBxdWVzdGlvbnMuLi4NCg0K TGUgMjAxNC0wMi0wOCAwODoxMSwgS2FybCBTdGFobCBhIMOpY3JpdCA6DQo+IC0gTm90ZSB0aGF0 IHRvIGFjaGlldmUgc29tZSBvZiB0aGUgYWJvdmUgcG9pbnRzLCBUVVJOIG11c3QgYmUgZmF2b3Jl ZA0KPiBvdmVyIFNUVU4gdG8gZW5mb3JjZSB0aGF0IHRoZSBUVVJOLXBhdGggYWN0dWFsbHkgaXMg dXNlZC4gKFRoZSBBbnljYXN0DQo+IG1ldGhvZCBzdWdnZXN0ZWQgYmVsb3csIOKAnGF1dG9tYXRp Y2FsbHnigJ0gZG9lcyB0aGlzLikNCg0KSSB1bmRlcnN0YW5kIHRoZSBTVFVOIHZzIFRVUk4gcHJp b3JpdHkgaXNzdWUuIEJ1dCBJIGRvbid0IHNlZSBob3cgYW55Y2FzdCBhZmZlY3RzIGl0IGluIGFu eSB3YXkuIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4/DQotLS0gR29vZCBwb2ludCAtIEkgd2FzIGEg Yml0IHF1aWNrIGhlcmUgKG1heWJlIHRvbyBxdWljaykNCldlIGhhdmUgZ2l2ZW4gdGhpcyBxdWl0 ZSBiaXQgb2YgdGhvdWdodCwgc2luY2UgZXZlbiBpZiBhIFRVUk4gc2VydmVyIGlzIHByb3ZpZGVk IGFuZCBkaXNjb3ZlcmVkLCBDVVJSRU5UIHVzYWdlIG9mIElDRSBtYXkgc3VnZ2VzdCBhIGNhbmRp ZGF0ZSBmcm9tIHRoZSByZW1vdGUgcGFydHkgdGhhdCB3aWxsIG1ha2UgYSBjb25uZWN0aW9uIHdp dGhvdXQgdGhlIG5lZWQvdXNhZ2Ugb2YgdGhlIFRVUk4gc2VydmVyICh0aGF0IHdlIHdhbnRlZCB0 byBiZSB1c2VkIGZvciB0aGUgZ29vZCBwdXJwb3NlcyBsaXN0ZWQpLg0KDQpUaGUgb25seSB3YXkg d2UgZm91bmQgYXJvdW5kIHRoaXMsIHdhcyB0byBzdG9wIFNUVU4gdGhyb3VnaCB0aGUgSVAgZGVm YXVsdCBnYXRld2F5IChsaWtlIGEgcmVzdHJpY3RpdmUgRW50ZXJwcmlzZSBmaXJld2FsbCBkb2Vz IGluaGliaXRpbmcgSUNFIGNvbm5lY3Rpdml0eSwgd2hpY2ggb3RoZXJzIGFyZSBjb25jZXJuZWQg YWJvdXQuLi4pLiBTaW5jZSB0aGUgcHJvdmlzaW9uaW5nIG9mIGF1dG8tZGlzY292ZXJ5IHVzaW5n IHRoZSBhbnljYXN0IG1lY2hhbmlzbSwgd291bGQgYmUgYWRkaW5nIGEgcm91dGUgaW4gYSBkZWZh dWx0IGdhdGV3YXksIGFkZGluZyBhIGZpcmV3YWxsIHJ1bGUgdG8gZWF0IFNUVU4gcGFja2V0cyB3 b3VsZCBhc3N1cmUgdGhhdCB0aGUgcHJvdmlzaW9uZWQgVFVSTiBzZXJ2ZXIgYWN0dWFsbHkgYmVj b21lcyB1c2VkIChhbmQgbm90IGJ5cGFzc2VkICJieSBhY2NpZGVudCIpLiAoVGhhdCB3YXMgdGhl IHRob3VnaHQgYmVoaW5kIHRoZSDigJxhdXRvbWF0aWNhbGx54oCdIHdpdGhpbiBxdW90ZXMuKQ0K DQpCVVQsIHNpbmNlIHlvdSBicm91Z2h0IHVwIHRoZSBxdWVzdGlvbiwgYXNzdW1pbmcgdGhhdCB3 ZSBoYXZlIHRoZSBwb3dlciB0byBlbmZvcmNlIFdlYlJUQyB1c2FnZSBvZiBJQ0UsIEkgYmVsaWV2 ZSBhIE1VU1QgcmVxdWlyZW1lbnQgdG8gdXNlIGFuIGF1dG8tZGlzY292ZXJlZCBUVVJOIHNlcnZl ciBpbnN0ZWFkIG9mIFNUVU4sIHdvdWxkIHNvbHZlIHRoZSBzYW1lIHByb2JsZW0uIEhvd2V2ZXIs IHRoaW5raW5nIGZ1cnRoZXIgKGluIHJlbGF0aW9uIHRvIHlvdXIgbmV4dCBxdWVzdGlvbiAtICJh bnlvbmUgY291bGQgc2V0IHVwIGEgYmFkbHktbWFpbnRhaW5lZCIgLSBlbmZvcmNpbmcgc3VjaCBJ Q0UgdXNhZ2UgbWF5IG5vdCBiZSBnb29kLikNCg0KDQo+IC0gM15yZCBUaGUgQW55Y2FzdCBtZXRo b2QgYmVsb3cg4oCTIEkgc2VlIG5vIHByb2JsZW0NCj4NCj4gSXQgYWxzbyBoYXMgdGhlIGFkdmFu dGFnZSBvZiBlbmNvdXJhZ2luZyAoYnV0IG5vdCByZXF1aXJpbmcpIHRoZQ0KPiBTVFVOL1RVUk4g dG8gYmUgYnVpbHQgaW4gdGhlIGRlZmF1bHQgZ2F0ZXdheSBvciBOQVQvZmlyZXdhbGwvYWNjZXNz DQo+IHJvdXRlciBpdHNlbGYsIHdpdGggYSBzZWNvbmQgaW50ZXJmYWNlIHRvIGEgcHVibGljIElQ IGFkZHJlc3Mgb24gdGhlDQo+IFdBTiBzaWRlLiAoQ3VycmVudCB2b2x1bWUgZGVwbG95ZWQsIGxv dyBjb3N0IE5TUCB0cmlwbGUgcGxheSBtb2RlbXMNCj4gdXN1YWxseSBoYXZlIGEgcXVhbGl0eSBh c3N1cmVkIGxldmVsIDIgb3IgbGV2ZWwgMyBXQU4gcGlwZSBmb3IganVzdA0KPiB2b2ljZSAoYW5k IGFub3RoZXIgZm9yIElQVFYpIOKAkyBUaGUgYW55Y2FzdCBkaXNjb3ZlcmVkIFRVUk4tc2VydmVy IGNhbg0KPiBiZSB0aGUgYWNjZXNzIGdhdGV3YXkgdG8gc3VjaCBxdWFsaXR5IHBpcGUgZm9yIFdl YlJUQyBtZWRpYSwgaW4gYQ0KPiBzaW5nbGUgTlNQIHByb3ZpZGVkIENQRSwgc2NhbGluZyBmcm9t IHJlc2lkZW50aWFsIGFuZCB1cC4pDQoNClN1cHBvc2Ugd2UgZGVmaW5lIHdlbGwta25vd24gYW55 Y2FzdCBUVVJOIHNlcnZlciBhZGRyZXNzZXMuIEhvdyB3b3VsZCB0aGlzIG5vdCBiZSBzdWJqZWN0 IHRvIHRoZSBzYW1lIHNlcnZpY2UgcXVhbGl0eSBpc3N1ZXMgdGhhdCBwbGFndWVkIDZ0bzQ/IFRo YXQgaXMsIGFueW9uZSBjb3VsZCBzZXQgdXAgYSBiYWRseS1tYWludGFpbmVkLCB1bmRlci1wcm92 aXNpb25lZCBUVVJOIHNlcnZlciBhbmQgYW5ub3VuY2UgaXQgb3ZlciBCR1AgdG8gdGhlIHdvcmxk LCBhcyBpdCB3YXMgZG9uZSBmb3INCjZ0bzQgcmVsYXlzLiBPciBqdXN0IGJhZCBCR1Agb3V0Ym91 bmQgZmlsdGVyIGNvbmZpZ3VyYXRpb24uIEFuZCBob3cgY2FuIHdlIHByZXZlbnQgdHJpYW5nbGUg cm91dGluZz8gVGhlcmUgaXMgbm90aGluZyBndWFyYW50ZWVpbmcgdGhhdCB0aGUgYW55Y2FzdCBz ZXJ2ZXIgeW91IHNlZSBpcyBiZWluZyBwcm92aWRlZCB0byB5b3UgYnkgeW91ciBJU1AsIHJhdGhl ciB0aGFuIGEgc2VydmVyIHNpdHRpbmcgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIHBsYW5ldC4N Ci0tLSBHb29kIHBvaW50IC0gbmVlZHMgdG8gYmUgcmVzb2x2ZWQuIEZvciB0aGlzIEkgZG9uJ3Qg aGF2ZSBhIHJlYWR5IGFuc3dlci4uLg0KQW4gYXV0by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVyIG11 c3QgYmUgdHJ1c3RlZCAod2hhdGV2ZXIgbWV0aG9kIGl0IGlzIGRpc2NvdmVyZWQgYnkpLiBXZSBh cmUgdHJ1c3RpbmcgdGhlIG9uZSBwcm92aWRpbmcgdXMgd2l0aCBhbiBJUCBhZGRyZXNzIGFuZCBk ZWZhdWx0IGdhdGV3YXkgYW55d2F5LiBJdCB3b3VsZCBiZSBlYXN5IGlmIHdlIGNvdWxkIHJldXNl IHRoYXQgdHJ1c3QsIGluc3RlYWQgb2YgYW5vdGhlciBtZWNoYW5pc21zLg0KDQpJcyB0aGVyZSBh IGdvb2Qgd2F5IGZvciB0aGUgYnJvd3NlciB0byBjaGVjayB0aGF0IHRoZSBhbnljYXN0IGFkZHJl c3MgaXMgbm90IGhhbmRsZWQgYmV5b25kIHRoZSBuZXR3b3JrIHNlcnZpY2UgcHJvdmlkZXIncyBk ZWZhdWx0IGdhdGV3YXk/IElkZWFzPw0KDQoNCg0KVGhhbmtzLA0KU2ltb24NCi0tDQpEVE4gbWFk ZSBlYXN5LCBsZWFuLCBhbmQgc21hcnQgLS0+IGh0dHA6Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUu Y2E8aHR0cDovL3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5jYS8+DQpOQVQ2NC9ETlM2NCBvcGVuLXNv dXJjZSAgICAgICAgLS0+IGh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhPGh0dHA6Ly9lY2R5c2lz LnZpYWdlbmllLmNhLz4NClNUVU4vVFVSTiBzZXJ2ZXIgICAgICAgICAgICAgICAtLT4gaHR0cDov L251bWIudmlhZ2VuaWUuY2E8aHR0cDovL251bWIudmlhZ2VuaWUuY2EvPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0 cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90cmFtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86 dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJh bQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJh bSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFt QGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90cmFtDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWls dG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHJhbQ0KDQoNCg== --_000_913383AAA69FF945B8F946018B75898A242AD1F4xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhl cmUgYXJlIG90aGVyIHdheXMgdG8gc29sdmUgdGhlIHByb2JsZW0gZm9yIGV4YW1wbGUgdXNpbmcg UENQLiBDYW4geW91IGNsYXJpZnkgaG93IGRlcGxveWluZyBhIFRVUk4gc2VydmVyIGluIHRoZSBF bnRlcnByaXNlIHByb3RlY3RzIHRoZSB1c2VycyBhbmQgdGhlIG5ldHdvcmsNCiA/IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+LVRpcnUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5IdXR0b24sIEFuZHJldzxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVi cnVhcnkgMTMsIDIwMTQgMTowMCBBTTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFViZXJ0aTsgTXV0 aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk8YnI+DQo8Yj5DYzo8L2I+IHRpcmVkZHlA aWNpc2NvLmNvbTsgU2ltb24gUGVycmVhdWx0OyBPbGVnIE1vc2thbGVua287IHRyYW1AaWV0Zi5v cmc7IE1hcmMgQmxhbmNoZXQ7IERhbiBXaW5nIChkd2luZyk7IEthcmwgU3RhaGw8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNj b3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoZSBjYXNlIHdoZXJlIHRoZSBUVVJOIHNlcnZlciBpcyB0aGUgb25s eSBvcHRpb24gbWF5IGJlY29tZSBjb21tb24gd2l0aGluIGVudGVycHJpc2UgbmV0d29ya3MgYW5k IHRoYXQgbWlnaHQgYmUgZGVsaWJlcmF0ZSBlbnRlcnByaXNlIHBvbGljeSBiZWNhdXNlIGl0IHBy b3ZpZGVzDQogdGhlIGJldHRlciBwYXRoIChVRFAgdGhyb3VnaCB0aGUgRi9XKSBhbmQgcHJvdGVj dHMgdGhlIHVzZXJzIGFuZCB0aGUgbmV0d29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IHRyYW0gWzxhIGhyZWY9Im1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5K dXN0aW4gVWJlcnRpPGJyPg0KPGI+U2VudDo8L2I+IDEyIEZlYnJ1YXJ5IDIwMTQgMTc6NDY8YnI+ DQo8Yj5Ubzo8L2I+IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpPGJyPg0KPGI+ Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tIj50aXJlZGR5QGljaXNj by5jb208L2E+OyBTaW1vbiBQZXJyZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsNCjxhIGhyZWY9Im1h aWx0bzp0cmFtQGlldGYub3JnIj50cmFtQGlldGYub3JnPC9hPjsgTWFyYyBCbGFuY2hldDsgRGFu IFdpbmcgKGR3aW5nKTsgS2FybCBTdGFobDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1d IE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVu dGVycHJpc2UgYW5kIElTUHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWdyZWUuIElmIFRVUk4gaXMgaW5kZWVkIGJlaW5nIHByb3ZpZGVkIGZv ciB0aGUgdXNlcidzIGJlbmVmaXQsIHRoZSBjbGllbnQncyBJQ0UgbG9naWMgKGJhc2VkIG9uIFJU VCBvciBzaW1pbGFyKSBzaG91bGQgcmVzdWx0IGluIGl0IHByZWZlcnJpbmcgdGhlIFRVUk4gcGF0 aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgMTIsIDIwMTQgYXQgMToyNyBBTSwgTXV0 aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgJmx0OzxhIGhyZWY9Im1haWx0bzptcGVy dW1hbEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tcGVydW1hbEBjaXNjby5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+WWVzLCBJIGJlbGlldmUgdGhlIHNlY29uZCBjYXNlIGlzIHJhcmUsIGJ1 dCB3b3VsZCBiZSBiZXR0ZXIgdGhhbiBhIHJhdCByYWNlIGIvdyBhZG1pbmlzdHJhdG9ycyB0cnlp bmcgdG8gYmxvY2sgcDJwIHRyYWZmaWMNCiBhbmQgZm9yY2UgaXQgdGhyb3VnaCBhIFRVUk4gc2Vy dmVyIGFuZCBhcHBzL2VuZHBvaW50cyBmaW5kaW5nIHNtYXJ0ZXIgd2F5cyB0byBieXBhc3MgdGhl bS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5NdXRodTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tb20wNDAy NjdAZ21haWwuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5 IDEyLCAyMDE0IDE6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IE11dGh1IEFydWwgTW96aGkgUGVydW1h bCAobXBlcnVtYWwpPGJyPg0KPGI+Q2M6PC9iPiBKdXN0aW4gVWJlcnRpOyBLYXJsIFN0YWhsOyA8 YSBocmVmPSJtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+DQp0aXJl ZGR5QGljaXNjby5jb208L2E+OyBNYXJjIEJsYW5jaGV0OyA8YSBocmVmPSJtYWlsdG86dHJhbUBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdHJhbUBpZXRmLm9yZzwvYT47IERhbiBXaW5nIChk d2luZyk7IFNpbW9uIFBlcnJlYXVsdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0g TWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50 ZXJwcmlzZSBhbmQgSVNQczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgVFVSTiBzZXJ2ZXIg aGFzIHRvIGJlIHVzZWQgd2hlbiBpdCBpcyBlaXRoZXIgdGhlIG9ubHkgb3B0aW9uLCBvciBpZiBp dCBwcm92aWRlcyBhIGJldHRlciBwYXRoIChJIGd1ZXNzIHRoZSBzZWNvbmQgY2FzZSBpcyByYXRo ZXIgcmFyZSkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgRmVi IDExLCAyMDE0IGF0IDExOjMyIFBNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFs KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wZXJ1bWFsQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1wZXJ1bWFsQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mIzQzOzE8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gb3Jj aW5nIGFsbCB0cmFmZmljIHRocm91Z2ggYSBUVVJOIHNlcnZlciBhbmQgZXhwZWN0aW5nIGl0IHdv dWxkIHByb3ZpZGUgdGhlIGJlc3QgdXNlciBleHBlcmllbmNlIGRvZXNuJ3QgbG9vayB0aGUgcmln aHQNCiBhcHByb2FjaC4gSW5zdGVhZCwgaWYgYSBwYXRoIHRocm91Z2ggYSBUVVJOIHNlcnZlciBl eGlzdHMgYW5kIGRvZXMgcHJvdmlkZSBsb3dlciBSVFQsIGppdHRlciBldGMsIGJlaW5nIGFibGUg dG8gZGV0ZWN0IGFuZCB1c2UgKG9yIHN3aXRjaCB0bykgdGhhdCBwYXRoIG1pZ2h0IGJlIGRlc2ly YWJsZS4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+TXV0aHU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRyYW0gW21haWx0bzo8YSBocmVmPSJt YWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbS1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0IDExOjQzIEFNPGJyPg0KPGI+ VG86PC9iPiBLYXJsIFN0YWhsPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dGlyZWRk eUBpY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+dGlyZWRkeUBpY2lzY28uY29tPC9hPjsgTWFy YyBCbGFuY2hldDsNCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+dHJhbUBpZXRmLm9yZzwvYT47IERhbiBXaW5nIChkd2luZyk7IFNpbW9uIFBlcnJlYXVsdDxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBh dXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBUdWUsIEZlYiAxMSwgMjAxNCBhdCAyOjM3IFBNLCBLYXJsIFN0YWhsICZsdDs8YSBocmVmPSJt YWlsdG86a2FybC5zdGFobEBpbnRlcnRleC5zZSIgdGFyZ2V0PSJfYmxhbmsiPmthcmwuc3RhaGxA aW50ZXJ0ZXguc2U8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPkxpc3RlbmluZyB0byB0aGlzIHRocmVhZCwgSSBhbSBhZnJhaWQgd2UgYXJlIG1pc3Npbmcg dGhlIHZlcnkgcG9pbnQgYW5kIG5lY2Vzc2l0eSBmb3IgdGhpcyBtaWxlc3RvbmUhPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPi0gVGhlcmUgYXJlIHNldmVyZSBOQVQgdHJhdmVyc2FsIGFuZCBx dWFsaXR5IGlzc3VlcyB0aGF0IHNob3VsZCBhbmQgY2FuIGJlIGRlYWx0IHdpdGggYnkgYSBnb29k IGF1dG8tZGlzY292ZXJ5DQogbWVjaGFuaXNtIGFuZCB0aGUgcmlnaHQgdXNhZ2UgYnkgdGhlIHR1 cm4gY2xpZW50ICh0aGUgV2ViUlRDIGJyb3dzZXIpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5UaGVyZSBhcmUgd2F5cywgbm90IG9u bHk6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPkVudGVycHJpc2VzIG9yIElTUHMgd2lzaGluZyB0byBwcm92 aWRlIHRoZWlyIG93biBUVVJOIHNlcnZlciwgaW4gYW4gYXR0ZW1wdCB0byByZWR1Y2Ugc28tY2Fs bGVkICZxdW90O3RyaWFuZ2xlIHJvdXRpbmcmcXVvdDssbmVlZCBhIG5ldyBhdXRvLWRpc2NvdmVy eSBtZWNoYW5pc208L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+QnV0IGFsc286IC0gTlNQcyAo TmV0d29yayBTZXJ2aWNlIFByb3ZpZGVycykgd2FudCB0byBwcm92aWRlIGEgcGF0aCB3aGVyZSB0 aGUgYmFuZHdpZHRoIG9mIFdlYlJUQyBpcyBiZXR0ZXINCiBjb3BlZCB3aXRoLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LSBOU1BzIG9yIEVudGVycHJpc2VzIHdhbnQgdG8gb2Zm ZXIgYW4gSW50ZXJuZXQgYWNjZXNzIHF1YWxpdHkgcGlwZSBmb3IgcHJpb3JpdGl6ZWQgUlRDIChS ZWFsIFRpbWUgQ29tbXVuaWNhdGlvbikNCiB0cmFmZmljLiA8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+LSBFbnRlcnByaXNlcyBoYXZpbmcgcmVzdHJpY3RpdmUgZmlyZXdhbGxzLCB3YW50IHRv IHByb3ZpZGUgYSBVRFAtcGF0aCBmb3IgV2ViUlRDIGFuZCBwb3NzaWJseSBhbHNvIGZvcg0KIGJl dHRlciBxdWFsaXR5IHdoZXJlIFJUQyBkbyBub3QgY29tcGV0ZSB3aXRoIGRhdGEgdHJhZmZpYy4g PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+QWxzbyBjb25zaWRlcmluZzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LSBNb2JpbGl0eTsgSXQgaXMgY29tbW9uIHRv IG1vdmUgZnJvbSBhIExBTiB0byBhY2Nlc3NpbmcgdmlhIFdpRmkgb3IgM0cvNEcgT1RUIGNoYW5u ZWxzLCBhbGwgc2hvdWxkIGJlDQogYWJsZSB0byBhdXRvbWF0aWNhbGx5IG9mZmVyIHRoZWlyIG93 biBvcHRpbWFsIFRVUk4gc2VydmVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlRoaXMgbGVhZHMgdXMgaW50bw0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO+KAnFRVUk7igKZ0byBpZGVu dGlmeSBXZWJSVEMgZmxvd3PigJ0NCjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj5ldGMhIEl0IGlz IG5vdCBhIG1pc3Rha2UsIGJ1dCB0aGUgdmVyeSBuZWVkIGZvciB0aGlzIG1pbGVzdG9uZSE8L3Nw YW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5BZ2FpbiwgaXQgaGFzIG5vdCBiZWVuIGRlbW9uc3RyYXRlZCB3 aHkgVFVSTiBpcyB0aGUgcmlnaHQgdGVjaG5vbG9neSBoZXJlLCBjb21wYXJlZCB0byBhIG1vcmUg dHJhbnNwYXJlbnQgZmxvdyBpZGVudGlmaWNhdGlvbiB0b29sIGxpa2UgTUFMSUNFLiBXZSBkb24n dCBmb3JjZSBhbGwgSFRUUCByZXF1ZXN0cw0KIHRvIGxvY2F0ZSBhIEhUVFAgcHJveHkgdmlhIGFu eWNhc3QsIEkgZG9uJ3Qgc2VlIHdoeSB3ZSBuZWVkIHRvIGRvIHRoZSBzYW1lIGZvciBXZWJSVEMu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPldoYXQgYXJlIHRoZSBoZXNpdGF0aW9ucyByYWlzZWQgaGVyZT88 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7IFRVUk4gcHJpbWFyaWx5IHRvIGlkZW50aWZ5 IFdlYlJUQyBmbG93cywgYXMgb3Bwb3NlZCB0byB1c2luZyBpdCBhcyBhIE5BVCB0cmF2ZXJzYWwg dG9vbC4gVGhpcyBtYWtlcyBtZSBjb25jZXJuZWQNCiB0aGF0IHdlIG1heSBiZSB1c2luZyB0aGUg d3JvbmcgdGVjaG5vbG9neSB0byBzb2x2ZSB0aGUgcHJvYmxlbTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsdWUiPkl0IGlzIGNvcnJlY3QgdGhhdCBJQ0UvU1RVTi9UVVJOIHdhcyBkZXNp Z25lZCB0byBhZGRyZXNzIHRoZSBOQVQvRmlyZXdhbGwgdHJhdmVyc2FsIHByb2JsZW0gYXNzb2Np YXRlZA0KIHdpdGggcmVhbC10aW1lIGNvbW11bmljYXRpb24gKFNJUCBhdCB0aGF0IHRpbWUpLiBI b3dldmVyLCBpdHMgbGFyZ2VzdCBmbGF3L3Byb2JsZW0gaXMgdGhhdCBxdWFsaXR5IHRoaW5ncyB3 ZXJlIG5vdCAoY291bGQgbm90IGJlPykgY29uc2lkZXJlZC4gVGhlIG1ldGhvZOKAmXMgdmVyeSBp ZGVhIChsaWtlIGFsbCBzaW1pbGFyIG1ldGhvZHMgZm9yIGdldHRpbmcgUlRDIHRocm91Z2ggb3Jk aW5hcnkgTkFUL0ZpcmV3YWxscykgaXMgdG8gZm9vbCB0aGUgbWVkaWENCiB0aHJvdWdoIGEgTkFU L0ZpcmV3YWxsIHRoYXQgaXMgdW5hd2FyZSBvZiB3aGF0IGlzIGhhcHBlbmluZy4gVGh1cywgdGhp cyBpcyByb290IG9mIHF1YWxpdHkgaXNzdWVzIChhbmQgYmFuZHdpZHRoIGFsbG9jYXRpb24gb3B0 aW1pemF0aW9uKSB0aGF0IG5lZWRzIHRvIGJlIGRlYWx0IHdpdGg6IFJlYWwtdGltZSB0cmFmZmlj IGZpZ2h0aW5nIHdpdGggYSBkYXRhIHRyYWZmaWMgY3Jvd2RlZCBjb25nZXN0aW9uIHBvaW50Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0aGF0ICZxdW90O2Zvb2xpbmcm cXVvdDsgaXMgYW4gaW5jb3JyZWN0IGRlc2NyaXB0aW9uLiBUaGUgTkFUIGlzIHN1cHBvc2VkIHRv IGJlIHRyYW5zcGFyZW50IHRvIHRoZSBjbGllbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkJ1dCwgYSBCTEVTU0lO RyBvZiBJQ0UvU1RVTi9UVVJOIGlzIHRoYXQgaXQgY2FuIGJlIHNlZW4gYXMgYSBsZWdpdGltYXRl IHJlcXVlc3QgZm9yIGEgc3VpdGFibGUgcGlwZSBmb3INCiBxdWFsaXR5IGRlbWFuZGluZyByZWFs IHRpbWUgdHJhZmZpYy4gPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibHVlIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SUNFIGlzIGEg cHJlLXByb3RvY29sIHlvdSB1c2UgYmVjYXVzZSB5b3Ugd2FudCBhIHBhdGggZm9yIHJlYWwtdGlt ZSBtZWRpYSBiZXR3ZWVuIHBhcnRpZXMuIEhlcmU6IFRoZSBicm93c2VyDQogc2F5cyBrbm9jayBr bm9jaywgSSB3YW50IHRvIGdldCBtZWRpYSB0aHJvdWdoIChhbmQgb2YgY291cnNlIHdpdGggYXMg Z29vZCBxdWFsaXR5IGFzIHJlcXVpcmVkIGFuZCBwb3NzaWJsZSkuDQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPklmIHRoZSBOQVQv RmlyZXdhbGwgb3duZXIgYW5kIG5ldHdvcmsgb3duZXIgYXJlIGFsbG93ZWQgdG8gc2VlIHRoZXNl IHJlcXVlc3RzLCB0aGV5IGNhbiBoZWxwL2Fzc2lzdCBpbg0KIGFjaGlldmluZyB0aGUgZ29vZCBt ZWRpYSBwYXRoLiBJZiB0aGV5IGFyZSBub3QgYXdhcmUsIHRoZXkgY2Fubm90IGhlbHAhPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1 ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkhvcGUgdGhpcyBtYWRlIGl0IHVu ZGVyc3RhbmRhYmxlIG9uIGFuIG92ZXJ2aWV3IGxldmVsIGhvdyB0aGlzIGNhbiBiZWNvbWU8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQog4oCcVFVSTuKApnRvIGlkZW50aWZ5 IFdlYlJUQyBmbG93c+KAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JdCBpcyBhbHNvIHRo ZSBPTkxZIHdheSBJIGNhbiBzZWUgdG8gYWNoaWV2ZSB3aGF0IHdlIHdhbnQgdG8gYWNoaWV2ZSBh bmQgc2hvdWxkIGJlIHRoZSBhaW0gYW5kIHJlcXVpcmVtZW50DQogb2YgdGhpcyBtaWxlc3RvbmUu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj5JIGFtIHRhbGtpbmcgYWJvdXQgZ2VuZXJhbCB1c2FnZSBvZiBXZWJSVEMgb3ZlciBJbnRl cm5ldC9tb2JpbGUgT1RUIChub3QgZmVlZGluZyBXZWJSVEMgaW50byBhcHBsaWNhdGlvbg0KIHNw ZWNpZmljIG5ldHdvcmtzIGxpa2UgSU1TIHdoZXJlIG90aGVyIG1ldGhvZHMgbWF5IGV4aXN0KS4g PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj5UaGlzIGlzIGdvb2QsIG5vdCBldmlsITwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SWYgdGhlIGhlc2l0YXRpb25zIGFyZSBy YWlzZWQgYmVjYXVzZSBvZiBhIGJlbGllZi9ob3BlL3dpc2ggdGhhdCB0aGVyZSBhcmUgbm8gb3Ig d2lsbCBub3QgYmUgc2V2ZXJlIHF1YWxpdHkNCiBpc3N1ZXMg4oCcYmVjYXVzZSBpdCBpcyBhbGwg YWJvdXQgYmFuZHdpZHRo4oCdLCDigJxpdCB3aWxsIHJlc29sdmUgaXRzZWxmIHdpdGggdGltZeKA nSBldGMuLCBJIHN0cm9uZ2x5IG9iamVjdCEgVGhhdCBpcyB3cm9uZyBhbmQgd2lsbCBiZSB2ZXJ5 IGRldHJpbWVudGFsIGZvciBXZWJSVEMgdXNhZ2UuIFdlIGFscmVhZHkgc2VlIGl0IGFuZCBJIGNh biBnaXZlIG51bWVyb3VzIGV4YW1wbGVzIG9mIGhvdyBtdWNoIGxlc3MgcXVhbGl0eSBkZW1hbmRp bmcgVm9JUA0KIGlzL2lzIG5vdCBoYW5kbGVkIHF1YWxpdHkgd2lzZSBhbmQgdGhhdCBpdCBtYXR0 ZXJzLiBBbmQsIHdoYXQgd291bGQgYmUgYmFkIGNvbnNpZGVyaW5nIHF1YWxpdHkgaXNzdWVzIGFu ZCBhbGxvd2luZy9lbmNvdXJhZ2luZyBtZXRob2RzIHRvIGRlYWwgd2l0aCB0aGVtPzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JZiB0aGUgaGVzaXRhdGlvbnMgYXJl IHJhaXNlZCwgYmVjYXVzZSBvZiBzdXNwaWNpb24gdGhhdCB0aGUgbWV0aG9kcyB3ZSBtYXkgcmVj b21tZW5kIG1heSBiZSBtaXN1c2VkIHRvDQogc3RvcC9ibG9jay9kZXN0cm95IFdlYlJUQyB1c2Fn ZSAoZS5nLiB0byBwcm90ZWN0IGluY29tZSBmcm9tIGNhcnJpZXIgdGVsZXBob255IHRyYWZmaWMp LCBJIGNvdWxkIHVuZGVyc3RhbmQgYW5kIHdvdWxkIGZpZ2h0IHRoZSBzYW1lIGJhdHRsZS4gQnV0 IGhvcGVmdWxseSwgdGhvc2UgZGF5cyBhcmUgKHNvb24pIG92ZXIg4oCTIEF0IGxlYXN0IGZvcndh cmQgdGhpbmtpbmcgY2FycmllcuKAmXMgcmVhbGl6ZSB0aGF0IGFscmVhZHkuIFdlYiBSVEMgd2ls bA0KIGhhcHBlbi4gV2hpY2ggY3VzdG9tZXJzIHdhbnQgdG8gcGF5IGZvciBhbiBhY2Nlc3Mgd2l0 aCBibG9ja2VkIFdlYlJUQz8gVGhlIGNhcnJpZXLigJlzIG9mZmVyaW5nL2Fzc3VyaW5nIGdvb2Qg V2ViUlRDIHdpbGwgcmF0aGVyIGdldCB0aGUgY3VzdG9tZXJzIGFuZCBpbmNvbWUNCjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6 Ymx1ZSI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi4gKE1h eWJlIHRoZSBXZWIgYnJvd3NlciBjYW4gZGV0ZWN0IGFuZCBlbmNvdXJhZ2UgdGhpc+KApik8L3Nw YW4+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj5JZiB0aGVyZSBhcmUgdGVjaG5pY2FsIGNvbmNlcm5zIG9mIGJhZCByZXN1bHQs IG9yIGJldHRlciBtZXRob2RzIGFsbG93aW5nIG5ldHdvcmsgcHJvdmlkZXJzIGFuZCBMQU4gbWFu YWdlcnMNCiB0byBvZmZlciBhbmQgaW5mb3JtIHRoZSBicm93c2VyIHRoYXQgdGhlcmUgYXJlIGdv b2QgbWVkaWEgcGF0aHMgdG8gYmUgdXNlZCwgYW5kIHRoYXQgdGhlIHdlYiBicm93c2VyIGF1dG9t YXRpY2FsbHkgY2FuIGNob3NlIHRob3NlLCB0aGVuIGxldCB1cyBhbGwgdW5kZXJzdGFuZCB0aG9z ZSwgc28gd2UgY2FuIGFjaGlldmUgd2hhdCBzaG91bGQgYmUgYWNoaWV2ZWQgYnkgdGhpcyBtaWxl c3RvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ta3lwZSwgSGFuZ291dHMsIEZh Y2V0aW1lIGFyZSBkb2luZyBiaWxsaW9ucyBvZiBtaW51dGVzIHBlciB3ZWVrIGFuZCB0aGUgSW50 ZXJuZXQgaGFzIG5vdCBtZWx0ZWQgeWV0LiBJZiB3ZSBuZWVkIHRvIGRvIGZsb3cgaWRlbnRpZmlj YXRpb24gdG8gYWxsb3cgdHJhZmZpYyB0byBiZSBwcmlvcml0aXplZCwgZmluZQ0KIChzZWUgYWJv dmUgcmVnYXJkaW5nIG15IHByZWZlcnJlZCBhcHByb2FjaCksIGJ1dCBmb3JjaW5nIGFsbCBXZWJS VEMgdHJhZmZpYyB0aHJvdWdoIGEgTUlUTSAoVFVSTiBzZXJ2ZXIpIGlzIGEgbXVjaCBiaWdnZXIg anVtcCB0aGF0IEkgZG9uJ3QgeWV0IHNlZSB0aGUganVzdGlmaWNhdGlvbiBmb3IuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiBzaG9y dDogVFVSTiBpcyBhIHRlY2hub2xvZ3kgdGhhdCBpcyBzdXBwb3NlZCB0byBmYWRlIGF3YXkgd2l0 aCB0aGUgbW92ZSB0byBJUHY2LiBJIGRvbid0IHRoaW5rIHdlIHdhbnQgdG8gbWFrZSBpdCBhIGNy aXRpY2FsIGVsZW1lbnQgb2YgV2ViUlRDLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4vS2FybDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyw6Vu Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBEYW4gV2luZyBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzpkd2luZ0BjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5kd2luZ0Bj aXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2tpY2thdDo8L2I+IGRlbiAxMSBmZWJydWFyaSAyMDE0 IDE4OjI1PGJyPg0KPGI+VGlsbDo8L2I+IDwvc3Bhbj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPk1hcmMgQmxhbmNoZXQ8YnI+DQo8Yj5Lb3BpYTo8L2I+IEp1c3RpbiBVYmVy dGk7IDxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj4N CnRpcmVkZHlAaWNpc2NvLmNvbTwvYT47IEthcmwgU3RhaGw7IDxhIGhyZWY9Im1haWx0bzp0cmFt QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0cmFtQGlldGYub3JnPC9hPjsgU2ltb24gUGVy cmVhdWx0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj48YnI+DQo8Yj7DhG1uZTo8L2I+IFJlOiBbdHJhbV0g TWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50 ZXJwcmlzZSBhbmQgSVNQczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPk9uIEZlYiAx MSwgMjAxNCwgYXQgOTowOCBBTSwgTWFyYyBCbGFuY2hldCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1h cmMuYmxhbmNoZXRAdmlhZ2VuaWUuY2EiIHRhcmdldD0iX2JsYW5rIj5tYXJjLmJsYW5jaGV0QHZp YWdlbmllLmNhPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+TGUgMjAx NC0wMi0xMSDDoCAwMDozOSwgRGFuIFdpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpkd2luZ0BjaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj5kd2luZ0BjaXNjby5jb208L2E+Jmd0OyBhIMOpY3JpdCA6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGJyPg0KT24gRmViIDEwLCAyMDE0LCBhdCA1OjMwIFBNLCBKdXN0aW4gVWJlcnRpICZsdDs8YSBo cmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBn b29nbGUuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+R29vZCB0byBzZWUgdGhlcmUgaXMgYSBsb3Qgb2YgaW50ZXJlc3Qg Zm9yIHRoaXMgbWlsZXN0b25lLiBCdXQgYmFzZWQgb24gdGhlIGRlc2NyaXB0aW9uIGhlcmUsIGl0 IHNlZW1zDQogbGlrZSB3ZSB3YW50IHRvIHVzZSBUVVJOIHByaW1hcmlseSB0byBpZGVudGlmeSBX ZWJSVEMgZmxvd3MsIGFzIG9wcG9zZWQgdG8gdXNpbmcgaXQgYXMgYSBOQVQgdHJhdmVyc2FsIHRv b2wuIFRoaXMgbWFrZXMgbWUgY29uY2VybmVkIHRoYXQgd2UgbWF5IGJlIHVzaW5nIHRoZSB3cm9u ZyB0ZWNobm9sb2d5IHRvIHNvbHZlIHRoZSBwcm9ibGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiYjNDM7MS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5JIHdvdWxkIHByZWZlciBhbGxvd2luZyBmbG93cyB0byBlc3RhYmxpc2ggdGhlbXNlbHZl cyB1c2luZyB0aGVpciAnYmVzdCcgcGF0aCwgYW5kIHRoZSBiZXN0IHBhdGggaXMNCiBzZWxkb20g dGhyb3VnaCBhIFRVUk4gc2VydmVyLiAmbmJzcDtXaGVuIHdlIGltYWdpbmUgSVB2NiBpbiBvdXIg ZnV0dXJlLCB3ZSBkb24ndCB3YW50IHRvIGZvcmNlIGFuIGFwcGxpY2F0aW9uLWxldmVsIHByb3h5 IChUVVJOKSBzZXJ2ZXIgb24gdGhlIHBhdGggc29sZWx5IGZvciB0cmF2ZXJzaW5nIGFuIElQdjYg ZmlyZXdhbGwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SXQgc2VlbXMgdGhpcyB0 aHJlYWQgaXMgY29uZmxhdGluZyBhbGwgdGhlIHBvc3NpYmxlIHJlYXNvbnMgLyBqdXN0aWZpY2F0 aW9ucyBmb3IgVFVSTjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDsgKiBtb2JpbGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOyAqIE5BVCB0cmF2ZXJzYWwgKGJvdGggZW5kcG9pbnRzIGFyZSBiZWhpbmQg ZW5kcG9pbnQtZGVwZW5kZW50IG1hcHBpbmcgTkFUcyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgKiZuYnNwO2ZpcmV3YWxsIHRyYXZlcnNhbCAoZmly ZXdhbGwgYmxvY2tzIFVEUCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDsgKiBlbmhhbmNpbmcgcHJpdmFjeTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlVuZm9ydHVuYXRlbHkgdGhlIFRVUk4gc2VydmVyIG5vciB0aGUgZW5kcG9p bnQgcmVhbGx5IGtub3cgd2hpY2ggb2YgdGhvc2UgdXNlLWNhc2VzIGlzIGRlc2lyZWQgKGJ5IHRo ZQ0KIHVzZXIgb3IgYnkgdGhlIElUIG5ldHdvcmsgYWRtaW5pc3RyYXRvcikgb3IgbmVjZXNzYXJ5 IChmb3IgdGhlIGNhbGwgdG8gd29yayBhdCBhbGwpLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5EYW4sIHdoaWxlIEkgYWdyZWUgaW4gcHJp bmNpcGxlLCBJIGRvdWJ0IHRoYXQgYSB1c2VyIGNvdWxkIGV2ZXIgc2F5ICZxdW90O0kgd2FudCBt b2JpbGl0eSBvciBJIHdhbnQgTkFUIHRyYXZlcnNhbCZxdW90Oy4gSSB0aGluayB0aGUgdXNlciBv bmx5IHdhbnQgdGhlIGNhbGwgdG8gc3VjY2VlZCwgd2hhdGV2ZXINCiB0aGUgcHJvcGVydGllcyBv ZiBpdHMgbmV0d29yayBwb2ludCBvZiBhdHRhY2htZW50IGFyZS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+U28gd2hhdCBjYW4g d2UgZG8/ICZuYnNwO1Nob3VsZCB0aGUgVFVSTiBzZXJ2ZXIgcHJvdmlkZSBhbnkgYW5kIGFsbCBz ZXJ2aWNlcyB0aGUgVFVSTiBjbGllbnQgbWlnaHQgcG9zc2libHkgd2FudCwgYXMgdGhhdCBpcyB3 aGF0IGEgcm9idXN0IFRVUk4gc2VydmVyIHdpbGwgZG8sIGFuZCB0aGUNCiBlbmRwb2ludCBzaG91 bGQgcHJlZmVyIFRVUk4gY2FuZGlkYXRlcyBvdmVyIGFsbCBvdGhlcnMgYmVjYXVzZSB0aGVyZSBt aWdodCBiZSBzb21lIGZ1bmN0aW9uYWxpdHkgLyB1c2VmdWxuZXNzIG9mIFRVUk4gdGhhdCB0aGUg dXNlciBtaWdodCBnYWluIHRocm91Z2ggVFVSTiAoZS5nLiwgZW5oYW5jZWQgcHJpdmFjeSk/PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+LWQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwO1RoaXMgc2VlbXMgcHJvYmxlbWF0aWMuICZuYnNwO1BlcmhhcHMgd2UgbmVlZCBh IHdheSB0byBzaWduYWwgdGhlIGRlc2lyZWQgdXNlLWNhc2UgKCZxdW90O3RyYWl0JnF1b3Q7KSwg b3IgYXMgSnVzdGluDQogc3VnZ2VzdHMsIHVzaW5nIGEgZGlmZmVyZW50IHRlY2hub2xvZ3kgZm9y IHNvbWUgb2YgdGhlc2UgdXNlLWNhc2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPi1kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIE1vbiwgRmViIDEwLCAyMDE0IGF0IDM6MTgg UE0sIEthcmwgU3RhaGwmbmJzcDsmbHQ7PGEgaHJlZj0ibWFpbHRvOmthcmwuc3RhaGxAaW50ZXJ0 ZXguc2UiIHRhcmdldD0iX2JsYW5rIj5rYXJsLnN0YWhsQGludGVydGV4LnNlPC9hPiZndDsmbmJz cDt3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TaW1vbiw8YnI+DQo8YnI+DQpH b29kIHF1ZXN0aW9ucyAtIHNlZSBpbmxpbmUgYmVsb3cgLS0mZ3Q7IC48YnI+DQpTb21lIG1vcmUg dGhvdWdodCBpcyByZXF1aXJlZCE8YnI+DQo8YnI+DQovS2FybDxicj4NCjxicj4NCi0tLS0tVXJz cHJ1bmdsaWd0IG1lZGRlbGFuZGUtLS0tLTxicj4NCkZyw6VuOiB0cmFtIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW0tYm91 bmNlc0BpZXRmLm9yZzwvYT5dIEbDtnIgU2ltb24gUGVycmVhdWx0PGJyPg0KU2tpY2thdDogZGVu IDEwIGZlYnJ1YXJpIDIwMTQgMTU6MTY8YnI+DQpUaWxsOiBLYXJsIFN0YWhsOyZuYnNwOzxhIGhy ZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9yZzwv YT47Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnRpcmVkZHlAaWNpc2NvLmNvbTwvYT48YnI+DQrDhG1uZTogUmU6IFt0cmFtXSBNaWxlc3Rv bmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNl IGFuZCBJU1BzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkthcmwsPGJyPg0K PGJyPg0KSXQgaXMgZ3JlYXQgdG8gc2VlIHN1Y2ggZW50aHVzaWFzbSEgVGhhbmtzITxicj4NCjxi cj4NCkkgaGF2ZSBhIGNvdXBsZSB0ZWNobmljYWwgcXVlc3Rpb25zLi4uPGJyPg0KPGJyPg0KTGUg MjAxNC0wMi0wOCAwODoxMSwgS2FybCBTdGFobCBhIMOpY3JpdCA6PGJyPg0KJmd0OyAtIE5vdGUg dGhhdCB0byBhY2hpZXZlIHNvbWUgb2YgdGhlIGFib3ZlIHBvaW50cywgVFVSTiBtdXN0IGJlIGZh dm9yZWQ8YnI+DQomZ3Q7IG92ZXIgU1RVTiB0byBlbmZvcmNlIHRoYXQgdGhlIFRVUk4tcGF0aCBh Y3R1YWxseSBpcyB1c2VkLiAoVGhlIEFueWNhc3Q8YnI+DQomZ3Q7IG1ldGhvZCBzdWdnZXN0ZWQg YmVsb3csIOKAnGF1dG9tYXRpY2FsbHnigJ0gZG9lcyB0aGlzLik8YnI+DQo8YnI+DQpJIHVuZGVy c3RhbmQgdGhlIFNUVU4gdnMgVFVSTiBwcmlvcml0eSBpc3N1ZS4gQnV0IEkgZG9uJ3Qgc2VlIGhv dyBhbnljYXN0IGFmZmVjdHMgaXQgaW4gYW55IHdheS4gQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbj88 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tLSBHb29kIHBvaW50IC0gSSB3 YXMgYSBiaXQgcXVpY2sgaGVyZSAobWF5YmUgdG9vIHF1aWNrKTxicj4NCldlIGhhdmUgZ2l2ZW4g dGhpcyBxdWl0ZSBiaXQgb2YgdGhvdWdodCwgc2luY2UgZXZlbiBpZiBhIFRVUk4gc2VydmVyIGlz IHByb3ZpZGVkIGFuZCBkaXNjb3ZlcmVkLCBDVVJSRU5UIHVzYWdlIG9mIElDRSBtYXkgc3VnZ2Vz dCBhIGNhbmRpZGF0ZSBmcm9tIHRoZSByZW1vdGUgcGFydHkgdGhhdCB3aWxsIG1ha2UgYSBjb25u ZWN0aW9uIHdpdGhvdXQgdGhlIG5lZWQvdXNhZ2Ugb2YgdGhlIFRVUk4gc2VydmVyICh0aGF0IHdl IHdhbnRlZCB0byBiZSB1c2VkDQogZm9yIHRoZSBnb29kIHB1cnBvc2VzIGxpc3RlZCkuPGJyPg0K PGJyPg0KVGhlIG9ubHkgd2F5IHdlIGZvdW5kIGFyb3VuZCB0aGlzLCB3YXMgdG8gc3RvcCBTVFVO IHRocm91Z2ggdGhlIElQIGRlZmF1bHQgZ2F0ZXdheSAobGlrZSBhIHJlc3RyaWN0aXZlIEVudGVy cHJpc2UgZmlyZXdhbGwgZG9lcyBpbmhpYml0aW5nIElDRSBjb25uZWN0aXZpdHksIHdoaWNoIG90 aGVycyBhcmUgY29uY2VybmVkIGFib3V0Li4uKS4gU2luY2UgdGhlIHByb3Zpc2lvbmluZyBvZiBh dXRvLWRpc2NvdmVyeSB1c2luZyB0aGUgYW55Y2FzdCBtZWNoYW5pc20sDQogd291bGQgYmUgYWRk aW5nIGEgcm91dGUgaW4gYSBkZWZhdWx0IGdhdGV3YXksIGFkZGluZyBhIGZpcmV3YWxsIHJ1bGUg dG8gZWF0IFNUVU4gcGFja2V0cyB3b3VsZCBhc3N1cmUgdGhhdCB0aGUgcHJvdmlzaW9uZWQgVFVS TiBzZXJ2ZXIgYWN0dWFsbHkgYmVjb21lcyB1c2VkIChhbmQgbm90IGJ5cGFzc2VkICZxdW90O2J5 IGFjY2lkZW50JnF1b3Q7KS4gKFRoYXQgd2FzIHRoZSB0aG91Z2h0IGJlaGluZCB0aGUg4oCcYXV0 b21hdGljYWxseeKAnSB3aXRoaW4gcXVvdGVzLik8YnI+DQo8YnI+DQpCVVQsIHNpbmNlIHlvdSBi cm91Z2h0IHVwIHRoZSBxdWVzdGlvbiwgYXNzdW1pbmcgdGhhdCB3ZSBoYXZlIHRoZSBwb3dlciB0 byBlbmZvcmNlIFdlYlJUQyB1c2FnZSBvZiBJQ0UsIEkgYmVsaWV2ZSBhIE1VU1QgcmVxdWlyZW1l bnQgdG8gdXNlIGFuIGF1dG8tZGlzY292ZXJlZCBUVVJOIHNlcnZlciBpbnN0ZWFkIG9mIFNUVU4s IHdvdWxkIHNvbHZlIHRoZSBzYW1lIHByb2JsZW0uIEhvd2V2ZXIsIHRoaW5raW5nIGZ1cnRoZXIg KGluIHJlbGF0aW9uDQogdG8geW91ciBuZXh0IHF1ZXN0aW9uIC0gJnF1b3Q7YW55b25lIGNvdWxk IHNldCB1cCBhIGJhZGx5LW1haW50YWluZWQmcXVvdDsgLSBlbmZvcmNpbmcgc3VjaCBJQ0UgdXNh Z2UgbWF5IG5vdCBiZSBnb29kLik8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0K PGJyPg0KJmd0OyAtIDNecmQgVGhlIEFueWNhc3QgbWV0aG9kIGJlbG93IOKAkyBJIHNlZSBubyBw cm9ibGVtPGJyPg0KJmd0Ozxicj4NCiZndDsgSXQgYWxzbyBoYXMgdGhlIGFkdmFudGFnZSBvZiBl bmNvdXJhZ2luZyAoYnV0IG5vdCByZXF1aXJpbmcpIHRoZTxicj4NCiZndDsgU1RVTi9UVVJOIHRv IGJlIGJ1aWx0IGluIHRoZSBkZWZhdWx0IGdhdGV3YXkgb3IgTkFUL2ZpcmV3YWxsL2FjY2Vzczxi cj4NCiZndDsgcm91dGVyIGl0c2VsZiwgd2l0aCBhIHNlY29uZCBpbnRlcmZhY2UgdG8gYSBwdWJs aWMgSVAgYWRkcmVzcyBvbiB0aGU8YnI+DQomZ3Q7IFdBTiBzaWRlLiAoQ3VycmVudCB2b2x1bWUg ZGVwbG95ZWQsIGxvdyBjb3N0IE5TUCB0cmlwbGUgcGxheSBtb2RlbXM8YnI+DQomZ3Q7IHVzdWFs bHkgaGF2ZSBhIHF1YWxpdHkgYXNzdXJlZCBsZXZlbCAyIG9yIGxldmVsIDMgV0FOIHBpcGUgZm9y IGp1c3Q8YnI+DQomZ3Q7IHZvaWNlIChhbmQgYW5vdGhlciBmb3IgSVBUVikg4oCTIFRoZSBhbnlj YXN0IGRpc2NvdmVyZWQgVFVSTi1zZXJ2ZXIgY2FuPGJyPg0KJmd0OyBiZSB0aGUgYWNjZXNzIGdh dGV3YXkgdG8gc3VjaCBxdWFsaXR5IHBpcGUgZm9yIFdlYlJUQyBtZWRpYSwgaW4gYTxicj4NCiZn dDsgc2luZ2xlIE5TUCBwcm92aWRlZCBDUEUsIHNjYWxpbmcgZnJvbSByZXNpZGVudGlhbCBhbmQg dXAuKTxicj4NCjxicj4NClN1cHBvc2Ugd2UgZGVmaW5lIHdlbGwta25vd24gYW55Y2FzdCBUVVJO IHNlcnZlciBhZGRyZXNzZXMuIEhvdyB3b3VsZCB0aGlzIG5vdCBiZSBzdWJqZWN0IHRvIHRoZSBz YW1lIHNlcnZpY2UgcXVhbGl0eSBpc3N1ZXMgdGhhdCBwbGFndWVkIDZ0bzQ/IFRoYXQgaXMsIGFu eW9uZSBjb3VsZCBzZXQgdXAgYSBiYWRseS1tYWludGFpbmVkLCB1bmRlci1wcm92aXNpb25lZCBU VVJOIHNlcnZlciBhbmQgYW5ub3VuY2UgaXQgb3ZlciBCR1AgdG8gdGhlIHdvcmxkLA0KIGFzIGl0 IHdhcyBkb25lIGZvcjxicj4NCjZ0bzQgcmVsYXlzLiBPciBqdXN0IGJhZCBCR1Agb3V0Ym91bmQg ZmlsdGVyIGNvbmZpZ3VyYXRpb24uIEFuZCBob3cgY2FuIHdlIHByZXZlbnQgdHJpYW5nbGUgcm91 dGluZz8gVGhlcmUgaXMgbm90aGluZyBndWFyYW50ZWVpbmcgdGhhdCB0aGUgYW55Y2FzdCBzZXJ2 ZXIgeW91IHNlZSBpcyBiZWluZyBwcm92aWRlZCB0byB5b3UgYnkgeW91ciBJU1AsIHJhdGhlciB0 aGFuIGEgc2VydmVyIHNpdHRpbmcgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIHBsYW5ldC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tLSBHb29kIHBvaW50IC0gbmVlZHMg dG8gYmUgcmVzb2x2ZWQuIEZvciB0aGlzIEkgZG9uJ3QgaGF2ZSBhIHJlYWR5IGFuc3dlci4uLjxi cj4NCkFuIGF1dG8tZGlzY292ZXJlZCBUVVJOIHNlcnZlciBtdXN0IGJlIHRydXN0ZWQgKHdoYXRl dmVyIG1ldGhvZCBpdCBpcyBkaXNjb3ZlcmVkIGJ5KS4gV2UgYXJlIHRydXN0aW5nIHRoZSBvbmUg cHJvdmlkaW5nIHVzIHdpdGggYW4gSVAgYWRkcmVzcyBhbmQgZGVmYXVsdCBnYXRld2F5IGFueXdh eS4gSXQgd291bGQgYmUgZWFzeSBpZiB3ZSBjb3VsZCByZXVzZSB0aGF0IHRydXN0LCBpbnN0ZWFk IG9mIGFub3RoZXIgbWVjaGFuaXNtcy48YnI+DQo8YnI+DQpJcyB0aGVyZSBhIGdvb2Qgd2F5IGZv ciB0aGUgYnJvd3NlciB0byBjaGVjayB0aGF0IHRoZSBhbnljYXN0IGFkZHJlc3MgaXMgbm90IGhh bmRsZWQgYmV5b25kIHRoZSBuZXR3b3JrIHNlcnZpY2UgcHJvdmlkZXIncyBkZWZhdWx0IGdhdGV3 YXk/IElkZWFzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJy Pg0KPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NClNpbW9uPGJyPg0KLS08YnI+DQpEVE4gbWFkZSBl YXN5LCBsZWFuLCBhbmQgc21hcnQgLS0mZ3Q7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Bvc3RlbGxh dGlvbi52aWFnZW5pZS5jYS8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vcG9zdGVsbGF0aW9uLnZp YWdlbmllLmNhPC9hPjxicj4NCk5BVDY0L0ROUzY0IG9wZW4tc291cmNlICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOy0tJmd0OyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9lY2R5c2lzLnZpYWdlbmll LmNhLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhPC9hPjxicj4N ClNUVU4vVFVSTiBzZXJ2ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IC0tJmd0OyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9udW1iLnZpYWdlbmllLmNhLyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9udW1iLnZpYWdlbmllLmNhPC9hPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90cmFtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90cmFtPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IlNW Ij48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxh bmc9IlNWIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ry YW0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L3NwYW4+PC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJT ViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFt PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A242AD1F4xmbrcdx10ciscoc_-- From karl.stahl@intertex.se Thu Feb 13 02:08:05 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE3B1A0155 for ; Thu, 13 Feb 2014 02:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 YM34vCv3Gh3L for ; Thu, 13 Feb 2014 02:08:00 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id A14761A0123 for ; Thu, 13 Feb 2014 02:07:57 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131107523591; Thu, 13 Feb 2014 11:07:52 +0100 From: "Karl Stahl" To: "'Justin Uberti'" References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 13 Feb 2014 11:07:52 +0100 Message-ID: <005d01cf28a3$758bf300$60a3d900$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01CF28AB.D7505B00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8nuZIQThUSmhrYQO63oBjWE0StTAA6UjYA Content-Language: sv Cc: tireddy@icisco.com, 'Marc Blanchet' , tram@ietf.org, 'Dan Wing' , 'Simon Perreault' Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:08:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005E_01CF28AB.D7505B00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 -- I meant the firewall is being =E2=80=9Dfooled=E2=80=9D (within = quotes) by ICE usage =E2=80=93 The firewall is usually stopping incoming = unannounced/not recognized traffic /Karl =20 =20 =20 Fr=C3=A5n: Justin Uberti [mailto:juberti@google.com]=20 Skickat: den 12 februari 2014 07:13 Till: Karl Stahl Kopia: Dan Wing; Marc Blanchet; tireddy@icisco.com; tram@ietf.org; Simon = Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and = necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by = the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle = routing",need a new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D etc! It is not a mistake, but the very need for this = milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like = MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the = wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication = (SIP at that time). However, its largest flaw/problem is that quality = things were not (could not be?) considered. The method=E2=80=99s very = idea (like all similar methods for getting RTC through ordinary = NAT/Firewalls) is to fool the media through a NAT/Firewall that is = unaware of what is happening. Thus, this is root of quality issues (and = bandwidth allocation optimization) that needs to be dealt with: = Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 -- I meant the firewall is being =E2=80=9Dfooled=E2=80=9D (withing = quotes) =E2=80=93 it is usually stopping incoming unannounced/not = recognised traffic /Karl =20 =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get = media through (and of course with as good quality as required and = possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D It is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =E2=80=9Cbecause it is all = about bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with = time=E2=80=9D etc., I strongly object! That is wrong and will be very = detrimental for WebRTC usage. We already see it and I can give numerous = examples of how much less quality demanding VoIP is/is not handled = quality wise and that it matters. And, what would be bad considering = quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. (Maybe the Web browser can = detect and encourage this=E2=80=A6)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the = browser that there are good media paths to be used, and that the web = browser automatically can chose those, then let us all understand those, = so we can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the = Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) = is a much bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of = WebRTC. =20 /Karl =20 =20 Fr=C3=A5n: Dan Wing [mailto:dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; = Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet = wrote: =20 Le 2014-02-11 =C3=A0 00:39, Dan Wing a =C3=A9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' = path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN = server will do, and the endpoint should prefer TURN candidates over all = others because there might be some functionality / usefulness of TURN = that the user might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =E2=80=9Cautomatically=E2=80=9D within quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) > - 3^rd The Anycast method below =E2=80=93 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready = answer... An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca = =20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca = =20 STUN/TURN server --> http://numb.viagenie.ca = =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 ------=_NextPart_000_005E_01CF28AB.D7505B00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I think that "fooling" is an incorrect = description. The NAT is supposed to be transparent to the = client.

 

--= I meant the firewall is being =E2=80=9Dfooled=E2=80=9D (within quotes) = by ICE usage =E2=80=93 The firewall is usually stopping incoming = unannounced/not recognized traffic

/K= arl =C2=A0

 

 

Fr=C3=A5n: Justin = Uberti [mailto:juberti@google.com]
Skickat: den 12 februari = 2014 07:13
Till: Karl Stahl
Kopia: Dan Wing; Marc = Blanchet; tireddy@icisco.com; tram@ietf.org; Simon = Perreault
=C3=84mne: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

Inline.

 

On Tue, = Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped = with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic. =

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the = right technology here, compared to a more transparent flow = identification tool like MALICE. We don't force all HTTP requests to = locate a HTTP proxy via anycast, I don't see why we need to do the same = for WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method=E2=80=99s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion = point.

 

I = think that "fooling" is an incorrect description. The NAT is = supposed to be transparent to the client.

 

--= I meant the firewall is being =E2=80=9Dfooled=E2=80=9D (withing quotes) = =E2=80=93 it is usually stopping incoming unannounced/not recognised = traffic

/K= arl =C2=A0

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot = help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this = milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues =E2=80=9Cbecause it is all about = bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D = etc., I strongly object! That is wrong and will be very detrimental for = WebRTC usage. We already see it and I can give numerous examples of how = much less quality demanding VoIP is/is not handled quality wise and that = it matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with = them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this=E2=80=A6) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this = milestone.

 

Skype, Hangouts, Facetime are doing billions of = minutes per week and the Internet has not melted yet. If we need to do = flow identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to = fade away with the move to IPv6. I don't think we want to make it a = critical element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=C3=A5n: Dan Wing = [mailto:dwing@cisco.com]
Skickat: den 11 = februari 2014 18:25
Till: Marc = Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon = Perreault


=C3=84mne: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 <= /o:p>

 <= /o:p>

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> = wrote:

 <= /p>

Le = 2014-02-11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit = :

 <= /p>


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> = wrote:

 <= /p>

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks = UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all). =

 <= /o:p>

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 <= /o:p>

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced = privacy)?

 <= /o:p>

-d

 <= /o:p>

 <= /o:p>

 <= /p>

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these = use-cases.

 

-d<= o:p>

 

 

 <= /p>

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:<= /o:p>

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon = Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C3=84mne: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =C3=A9crit :
> - Note that to achieve some of the above points, = TURN must be favored
> over STUN to enforce that the TURN-path = actually is used. (The Anycast
> method suggested below, = =E2=80=9Cautomatically=E2=80=9D does this.)

I understand the STUN = vs TURN priority issue. But I don't see how anycast affects it in any = way. Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the =E2=80=9Cautomatically=E2=80=9D within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below =E2=80=93 I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) =E2=80=93 The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://postellation.viagenie.ca
NAT64/DNS64 = open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server =               --> http://numb.viagenie.ca
________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

_= ______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_005E_01CF28AB.D7505B00-- From andrew.hutton@unify.com Thu Feb 13 02:47:59 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0981A01D2 for ; Thu, 13 Feb 2014 02:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 XsW-fjHpXzRT for ; Thu, 13 Feb 2014 02:47:53 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 813461A01CD for ; Thu, 13 Feb 2014 02:47:52 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 25C3C23F05D5; Thu, 13 Feb 2014 11:47:51 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.100]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 11:47:50 +0100 From: "Hutton, Andrew" To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: Ac8obNsCFphKtERXaUGRovqHSSrR3gAPBsvw Date: Thu, 13 Feb 2014 10:47:50 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17CF4032@MCHP04MSX.global-ad.net> References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17CF4032MCHP04MSXglobal_" MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:47:59 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17CF4032MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByaW1lIHVzZSBjYXNlIGZvciB0aGlzIGlzIGRvY3VtZW50ZWQgaW4gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVu dHMtMTIjc2VjdGlvbi0zLjMuNS4xIGFuZCBJIHRoaW5rIHRoYXQgVFJBTSB3aWxsIHByb2JhYmx5 IG1ha2UgZW5oYW5jZW1lbnRzIHRvIFRVUk4gZW5hYmxpbmcgc3VjaCBhbiDigJxlbnRlcnByaXNl IGF1ZGl0aW5nIFRVUk4gc2VydmVy4oCdIHRvIGRvIGFuIGVmZmVjdGl2ZSBqb2Igb2YgbWFuYWdp bmcgV2ViUlRDIHRyYWZmaWMgaW4gYW4gZW50ZXJwcmlzZS4NCg0KVGhlcmUgYXJlIG9mIGNvdXJz ZSBtb3JlIHRoYW4gb25lIHByb2JsZW0gYW5kIG1hbnkgcG9zc2libHkgd2F5cyB0byBzb2x2ZSB0 aGVtIGFuZCBJIHJlY2VudGx5IHVwZGF0ZWQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaHV0dG9uLXJ0Y3dlYi1uYXQtZmlyZXdhbGwtY29uc2lkZXJhdGlvbnMtMDMgdG8gbGlzdCB0 aGVzZSBmb3IgZGlzY3Vzc2lvbiBpbmNsdWRpbmcgUENQLg0KDQpVbmZvcnR1bmF0ZWx5IHNvbHV0 aW9ucyBhcmUgbmVlZGVkIHRvZGF5IHdpdGhpbiBleGlzdGluZyBuZXR3b3JrcyBhbmQgUENQIGRv ZXMgbm90IHNlZW0gc28gdXNlZnVsIGhlcmUgc28gd2UgaGF2ZSB0byBsb29rIGF0IG11bHRpcGxl IHNvbHV0aW9ucyBhbmQgcHJvYmFibHkgV2ViUlRDIGJyb3dzZXJzIGhhdmUgdG8gc3VwcG9ydCBh IG51bWJlciBvZiBtZWNoYW5pc21zLg0KDQpSZWdhcmRzDQpBbmR5DQoNCg0KDQpGcm9tOiBUaXJ1 bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIFttYWlsdG86dGlyZWRkeUBjaXNjby5jb21dDQpTZW50 OiAxMyBGZWJydWFyeSAyMDE0IDAzOjM3DQpUbzogSHV0dG9uLCBBbmRyZXc7IEp1c3RpbiBVYmVy dGk7IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpDQpDYzogdGlyZWRkeUBpY2lz Y28uY29tOyBTaW1vbiBQZXJyZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsgdHJhbUBpZXRmLm9yZzsg TWFyYyBCbGFuY2hldDsgRGFuIFdpbmcgKGR3aW5nKTsgS2FybCBTdGFobA0KU3ViamVjdDogUkU6 IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNt IGZvciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNCkhpIEFuZHksDQoNClRoZXJlIGFyZSBvdGhlciB3 YXlzIHRvIHNvbHZlIHRoZSBwcm9ibGVtIGZvciBleGFtcGxlIHVzaW5nIFBDUC4gQ2FuIHlvdSBj bGFyaWZ5IGhvdyBkZXBsb3lpbmcgYSBUVVJOIHNlcnZlciBpbiB0aGUgRW50ZXJwcmlzZSBwcm90 ZWN0cyB0aGUgdXNlcnMgYW5kIHRoZSBuZXR3b3JrID8NCg0KLVRpcnUuDQpGcm9tOiB0cmFtIFtt YWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSHV0dG9uLCBBbmRyZXcN ClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCAxOjAwIEFNDQpUbzogSnVzdGluIFVi ZXJ0aTsgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkNCkNjOiB0aXJlZGR5QGlj aXNjby5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT47IFNpbW9uIFBlcnJlYXVsdDsgT2xl ZyBNb3NrYWxlbmtvOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPjsgTWFyYyBC bGFuY2hldDsgRGFuIFdpbmcgKGR3aW5nKTsgS2FybCBTdGFobA0KU3ViamVjdDogUmU6IFt0cmFt XSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBl bnRlcnByaXNlIGFuZCBJU1BzDQoNClRoZSBjYXNlIHdoZXJlIHRoZSBUVVJOIHNlcnZlciBpcyB0 aGUgb25seSBvcHRpb24gbWF5IGJlY29tZSBjb21tb24gd2l0aGluIGVudGVycHJpc2UgbmV0d29y a3MgYW5kIHRoYXQgbWlnaHQgYmUgZGVsaWJlcmF0ZSBlbnRlcnByaXNlIHBvbGljeSBiZWNhdXNl IGl0IHByb3ZpZGVzIHRoZSBiZXR0ZXIgcGF0aCAoVURQIHRocm91Z2ggdGhlIEYvVykgYW5kIHBy b3RlY3RzIHRoZSB1c2VycyBhbmQgdGhlIG5ldHdvcmsuDQoNCkFuZHkNCg0KDQpGcm9tOiB0cmFt IFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0 aQ0KU2VudDogMTIgRmVicnVhcnkgMjAxNCAxNzo0Ng0KVG86IE11dGh1IEFydWwgTW96aGkgUGVy dW1hbCAobXBlcnVtYWwpDQpDYzogdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGlj aXNjby5jb20+OyBTaW1vbiBQZXJyZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsgdHJhbUBpZXRmLm9y ZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IE1hcmMgQmxhbmNoZXQ7IERhbiBXaW5nIChkd2luZyk7 IEthcmwgU3RhaGwNClN1YmplY3Q6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVy IGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpBZ3Jl ZS4gSWYgVFVSTiBpcyBpbmRlZWQgYmVpbmcgcHJvdmlkZWQgZm9yIHRoZSB1c2VyJ3MgYmVuZWZp dCwgdGhlIGNsaWVudCdzIElDRSBsb2dpYyAoYmFzZWQgb24gUlRUIG9yIHNpbWlsYXIpIHNob3Vs ZCByZXN1bHQgaW4gaXQgcHJlZmVycmluZyB0aGUgVFVSTiBwYXRoLg0KDQpPbiBXZWQsIEZlYiAx MiwgMjAxNCBhdCAxOjI3IEFNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKSA8 bXBlcnVtYWxAY2lzY28uY29tPG1haWx0bzptcGVydW1hbEBjaXNjby5jb20+PiB3cm90ZToNClll cywgSSBiZWxpZXZlIHRoZSBzZWNvbmQgY2FzZSBpcyByYXJlLCBidXQgd291bGQgYmUgYmV0dGVy IHRoYW4gYSByYXQgcmFjZSBiL3cgYWRtaW5pc3RyYXRvcnMgdHJ5aW5nIHRvIGJsb2NrIHAycCB0 cmFmZmljIGFuZCBmb3JjZSBpdCB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgYW5kIGFwcHMvZW5kcG9p bnRzIGZpbmRpbmcgc21hcnRlciB3YXlzIHRvIGJ5cGFzcyB0aGVtLg0KDQpNdXRodQ0KDQpGcm9t OiBPbGVnIE1vc2thbGVua28gW21haWx0bzptb20wNDAyNjdAZ21haWwuY29tPG1haWx0bzptb20w NDAyNjdAZ21haWwuY29tPl0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQgMTow NyBQTQ0KVG86IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpDQpDYzogSnVzdGlu IFViZXJ0aTsgS2FybCBTdGFobDsgdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGlj aXNjby5jb20+OyBNYXJjIEJsYW5jaGV0OyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYu b3JnPjsgRGFuIFdpbmcgKGR3aW5nKTsgU2ltb24gUGVycmVhdWx0DQoNClN1YmplY3Q6IFJlOiBb dHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBm b3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpUaGUgVFVSTiBzZXJ2ZXIgaGFzIHRvIGJlIHVzZWQg d2hlbiBpdCBpcyBlaXRoZXIgdGhlIG9ubHkgb3B0aW9uLCBvciBpZiBpdCBwcm92aWRlcyBhIGJl dHRlciBwYXRoIChJIGd1ZXNzIHRoZSBzZWNvbmQgY2FzZSBpcyByYXRoZXIgcmFyZSkuDQoNCk9u IFR1ZSwgRmViIDExLCAyMDE0IGF0IDExOjMyIFBNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwg KG1wZXJ1bWFsKSA8bXBlcnVtYWxAY2lzY28uY29tPG1haWx0bzptcGVydW1hbEBjaXNjby5jb20+ PiB3cm90ZToNCisxDQoNCkZvcmNpbmcgYWxsIHRyYWZmaWMgdGhyb3VnaCBhIFRVUk4gc2VydmVy IGFuZCBleHBlY3RpbmcgaXQgd291bGQgcHJvdmlkZSB0aGUgYmVzdCB1c2VyIGV4cGVyaWVuY2Ug ZG9lc24ndCBsb29rIHRoZSByaWdodCBhcHByb2FjaC4gSW5zdGVhZCwgaWYgYSBwYXRoIHRocm91 Z2ggYSBUVVJOIHNlcnZlciBleGlzdHMgYW5kIGRvZXMgcHJvdmlkZSBsb3dlciBSVFQsIGppdHRl ciBldGMsIGJlaW5nIGFibGUgdG8gZGV0ZWN0IGFuZCB1c2UgKG9yIHN3aXRjaCB0bykgdGhhdCBw YXRoIG1pZ2h0IGJlIGRlc2lyYWJsZS4uDQoNCk11dGh1DQoNCkZyb206IHRyYW0gW21haWx0bzp0 cmFtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJl aGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0 IDExOjQzIEFNDQpUbzogS2FybCBTdGFobA0KQ2M6IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWlsdG86 dGlyZWRkeUBpY2lzY28uY29tPjsgTWFyYyBCbGFuY2hldDsgdHJhbUBpZXRmLm9yZzxtYWlsdG86 dHJhbUBpZXRmLm9yZz47IERhbiBXaW5nIChkd2luZyk7IFNpbW9uIFBlcnJlYXVsdA0KU3ViamVj dDogUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVj aGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNCklubGluZS4NCg0KT24gVHVlLCBGZWIg MTEsIDIwMTQgYXQgMjozNyBQTSwgS2FybCBTdGFobCA8a2FybC5zdGFobEBpbnRlcnRleC5zZTxt YWlsdG86a2FybC5zdGFobEBpbnRlcnRleC5zZT4+IHdyb3RlOg0KTGlzdGVuaW5nIHRvIHRoaXMg dGhyZWFkLCBJIGFtIGFmcmFpZCB3ZSBhcmUgbWlzc2luZyB0aGUgdmVyeSBwb2ludCBhbmQgbmVj ZXNzaXR5IGZvciB0aGlzIG1pbGVzdG9uZSENCi0gVGhlcmUgYXJlIHNldmVyZSBOQVQgdHJhdmVy c2FsIGFuZCBxdWFsaXR5IGlzc3VlcyB0aGF0IHNob3VsZCBhbmQgY2FuIGJlIGRlYWx0IHdpdGgg YnkgYSBnb29kIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBhbmQgdGhlIHJpZ2h0IHVzYWdlIGJ5 IHRoZSB0dXJuIGNsaWVudCAodGhlIFdlYlJUQyBicm93c2VyKQ0KDQpUaGVyZSBhcmUgd2F5cywg bm90IG9ubHk6IEVudGVycHJpc2VzIG9yIElTUHMgd2lzaGluZyB0byBwcm92aWRlIHRoZWlyIG93 biBUVVJOIHNlcnZlciwgaW4gYW4gYXR0ZW1wdCB0byByZWR1Y2Ugc28tY2FsbGVkICJ0cmlhbmds ZSByb3V0aW5nIixuZWVkIGEgbmV3IGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbQ0KQnV0IGFsc286 IC0gTlNQcyAoTmV0d29yayBTZXJ2aWNlIFByb3ZpZGVycykgd2FudCB0byBwcm92aWRlIGEgcGF0 aCB3aGVyZSB0aGUgYmFuZHdpZHRoIG9mIFdlYlJUQyBpcyBiZXR0ZXIgY29wZWQgd2l0aC4NCi0g TlNQcyBvciBFbnRlcnByaXNlcyB3YW50IHRvIG9mZmVyIGFuIEludGVybmV0IGFjY2VzcyBxdWFs aXR5IHBpcGUgZm9yIHByaW9yaXRpemVkIFJUQyAoUmVhbCBUaW1lIENvbW11bmljYXRpb24pIHRy YWZmaWMuDQotIEVudGVycHJpc2VzIGhhdmluZyByZXN0cmljdGl2ZSBmaXJld2FsbHMsIHdhbnQg dG8gcHJvdmlkZSBhIFVEUC1wYXRoIGZvciBXZWJSVEMgYW5kIHBvc3NpYmx5IGFsc28gZm9yIGJl dHRlciBxdWFsaXR5IHdoZXJlIFJUQyBkbyBub3QgY29tcGV0ZSB3aXRoIGRhdGEgdHJhZmZpYy4N CkFsc28gY29uc2lkZXJpbmcNCi0gTW9iaWxpdHk7IEl0IGlzIGNvbW1vbiB0byBtb3ZlIGZyb20g YSBMQU4gdG8gYWNjZXNzaW5nIHZpYSBXaUZpIG9yIDNHLzRHIE9UVCBjaGFubmVscywgYWxsIHNo b3VsZCBiZSBhYmxlIHRvIGF1dG9tYXRpY2FsbHkgb2ZmZXIgdGhlaXIgb3duIG9wdGltYWwgVFVS TiBzZXJ2ZXINCg0KVGhpcyBsZWFkcyB1cyBpbnRvICDigJxUVVJO4oCmdG8gaWRlbnRpZnkgV2Vi UlRDIGZsb3dz4oCdIGV0YyEgSXQgaXMgbm90IGEgbWlzdGFrZSwgYnV0IHRoZSB2ZXJ5IG5lZWQg Zm9yIHRoaXMgbWlsZXN0b25lIQ0KDQpBZ2FpbiwgaXQgaGFzIG5vdCBiZWVuIGRlbW9uc3RyYXRl ZCB3aHkgVFVSTiBpcyB0aGUgcmlnaHQgdGVjaG5vbG9neSBoZXJlLCBjb21wYXJlZCB0byBhIG1v cmUgdHJhbnNwYXJlbnQgZmxvdyBpZGVudGlmaWNhdGlvbiB0b29sIGxpa2UgTUFMSUNFLiBXZSBk b24ndCBmb3JjZSBhbGwgSFRUUCByZXF1ZXN0cyB0byBsb2NhdGUgYSBIVFRQIHByb3h5IHZpYSBh bnljYXN0LCBJIGRvbid0IHNlZSB3aHkgd2UgbmVlZCB0byBkbyB0aGUgc2FtZSBmb3IgV2ViUlRD Lg0KDQpXaGF0IGFyZSB0aGUgaGVzaXRhdGlvbnMgcmFpc2VkIGhlcmU/DQo+IFRVUk4gcHJpbWFy aWx5IHRvIGlkZW50aWZ5IFdlYlJUQyBmbG93cywgYXMgb3Bwb3NlZCB0byB1c2luZyBpdCBhcyBh IE5BVCB0cmF2ZXJzYWwgdG9vbC4gVGhpcyBtYWtlcyBtZSBjb25jZXJuZWQgdGhhdCB3ZSBtYXkg YmUgdXNpbmcgdGhlIHdyb25nIHRlY2hub2xvZ3kgdG8gc29sdmUgdGhlIHByb2JsZW0NCkl0IGlz IGNvcnJlY3QgdGhhdCBJQ0UvU1RVTi9UVVJOIHdhcyBkZXNpZ25lZCB0byBhZGRyZXNzIHRoZSBO QVQvRmlyZXdhbGwgdHJhdmVyc2FsIHByb2JsZW0gYXNzb2NpYXRlZCB3aXRoIHJlYWwtdGltZSBj b21tdW5pY2F0aW9uIChTSVAgYXQgdGhhdCB0aW1lKS4gSG93ZXZlciwgaXRzIGxhcmdlc3QgZmxh dy9wcm9ibGVtIGlzIHRoYXQgcXVhbGl0eSB0aGluZ3Mgd2VyZSBub3QgKGNvdWxkIG5vdCBiZT8p IGNvbnNpZGVyZWQuIFRoZSBtZXRob2TigJlzIHZlcnkgaWRlYSAobGlrZSBhbGwgc2ltaWxhciBt ZXRob2RzIGZvciBnZXR0aW5nIFJUQyB0aHJvdWdoIG9yZGluYXJ5IE5BVC9GaXJld2FsbHMpIGlz IHRvIGZvb2wgdGhlIG1lZGlhIHRocm91Z2ggYSBOQVQvRmlyZXdhbGwgdGhhdCBpcyB1bmF3YXJl IG9mIHdoYXQgaXMgaGFwcGVuaW5nLiBUaHVzLCB0aGlzIGlzIHJvb3Qgb2YgcXVhbGl0eSBpc3N1 ZXMgKGFuZCBiYW5kd2lkdGggYWxsb2NhdGlvbiBvcHRpbWl6YXRpb24pIHRoYXQgbmVlZHMgdG8g YmUgZGVhbHQgd2l0aDogUmVhbC10aW1lIHRyYWZmaWMgZmlnaHRpbmcgd2l0aCBhIGRhdGEgdHJh ZmZpYyBjcm93ZGVkIGNvbmdlc3Rpb24gcG9pbnQuDQoNCkkgdGhpbmsgdGhhdCAiZm9vbGluZyIg aXMgYW4gaW5jb3JyZWN0IGRlc2NyaXB0aW9uLiBUaGUgTkFUIGlzIHN1cHBvc2VkIHRvIGJlIHRy YW5zcGFyZW50IHRvIHRoZSBjbGllbnQuDQoNCkJ1dCwgYSBCTEVTU0lORyBvZiBJQ0UvU1RVTi9U VVJOIGlzIHRoYXQgaXQgY2FuIGJlIHNlZW4gYXMgYSBsZWdpdGltYXRlIHJlcXVlc3QgZm9yIGEg c3VpdGFibGUgcGlwZSBmb3IgcXVhbGl0eSBkZW1hbmRpbmcgcmVhbCB0aW1lIHRyYWZmaWMuIOKY ug0KSUNFIGlzIGEgcHJlLXByb3RvY29sIHlvdSB1c2UgYmVjYXVzZSB5b3Ugd2FudCBhIHBhdGgg Zm9yIHJlYWwtdGltZSBtZWRpYSBiZXR3ZWVuIHBhcnRpZXMuIEhlcmU6IFRoZSBicm93c2VyIHNh eXMga25vY2sga25vY2ssIEkgd2FudCB0byBnZXQgbWVkaWEgdGhyb3VnaCAoYW5kIG9mIGNvdXJz ZSB3aXRoIGFzIGdvb2QgcXVhbGl0eSBhcyByZXF1aXJlZCBhbmQgcG9zc2libGUpLg0KDQpJZiB0 aGUgTkFUL0ZpcmV3YWxsIG93bmVyIGFuZCBuZXR3b3JrIG93bmVyIGFyZSBhbGxvd2VkIHRvIHNl ZSB0aGVzZSByZXF1ZXN0cywgdGhleSBjYW4gaGVscC9hc3Npc3QgaW4gYWNoaWV2aW5nIHRoZSBn b29kIG1lZGlhIHBhdGguIElmIHRoZXkgYXJlIG5vdCBhd2FyZSwgdGhleSBjYW5ub3QgaGVscCEN Cg0KSG9wZSB0aGlzIG1hZGUgaXQgdW5kZXJzdGFuZGFibGUgb24gYW4gb3ZlcnZpZXcgbGV2ZWwg aG93IHRoaXMgY2FuIGJlY29tZSDigJxUVVJO4oCmdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dz4oCd DQpJdCBpcyBhbHNvIHRoZSBPTkxZIHdheSBJIGNhbiBzZWUgdG8gYWNoaWV2ZSB3aGF0IHdlIHdh bnQgdG8gYWNoaWV2ZSBhbmQgc2hvdWxkIGJlIHRoZSBhaW0gYW5kIHJlcXVpcmVtZW50IG9mIHRo aXMgbWlsZXN0b25lLg0KDQpJIGFtIHRhbGtpbmcgYWJvdXQgZ2VuZXJhbCB1c2FnZSBvZiBXZWJS VEMgb3ZlciBJbnRlcm5ldC9tb2JpbGUgT1RUIChub3QgZmVlZGluZyBXZWJSVEMgaW50byBhcHBs aWNhdGlvbiBzcGVjaWZpYyBuZXR3b3JrcyBsaWtlIElNUyB3aGVyZSBvdGhlciBtZXRob2RzIG1h eSBleGlzdCkuDQoNClRoaXMgaXMgZ29vZCwgbm90IGV2aWwhDQoNCklmIHRoZSBoZXNpdGF0aW9u cyBhcmUgcmFpc2VkIGJlY2F1c2Ugb2YgYSBiZWxpZWYvaG9wZS93aXNoIHRoYXQgdGhlcmUgYXJl IG5vIG9yIHdpbGwgbm90IGJlIHNldmVyZSBxdWFsaXR5IGlzc3VlcyDigJxiZWNhdXNlIGl0IGlz IGFsbCBhYm91dCBiYW5kd2lkdGjigJ0sIOKAnGl0IHdpbGwgcmVzb2x2ZSBpdHNlbGYgd2l0aCB0 aW1l4oCdIGV0Yy4sIEkgc3Ryb25nbHkgb2JqZWN0ISBUaGF0IGlzIHdyb25nIGFuZCB3aWxsIGJl IHZlcnkgZGV0cmltZW50YWwgZm9yIFdlYlJUQyB1c2FnZS4gV2UgYWxyZWFkeSBzZWUgaXQgYW5k IEkgY2FuIGdpdmUgbnVtZXJvdXMgZXhhbXBsZXMgb2YgaG93IG11Y2ggbGVzcyBxdWFsaXR5IGRl bWFuZGluZyBWb0lQIGlzL2lzIG5vdCBoYW5kbGVkIHF1YWxpdHkgd2lzZSBhbmQgdGhhdCBpdCBt YXR0ZXJzLiBBbmQsIHdoYXQgd291bGQgYmUgYmFkIGNvbnNpZGVyaW5nIHF1YWxpdHkgaXNzdWVz IGFuZCBhbGxvd2luZy9lbmNvdXJhZ2luZyBtZXRob2RzIHRvIGRlYWwgd2l0aCB0aGVtPw0KDQpJ ZiB0aGUgaGVzaXRhdGlvbnMgYXJlIHJhaXNlZCwgYmVjYXVzZSBvZiBzdXNwaWNpb24gdGhhdCB0 aGUgbWV0aG9kcyB3ZSBtYXkgcmVjb21tZW5kIG1heSBiZSBtaXN1c2VkIHRvIHN0b3AvYmxvY2sv ZGVzdHJveSBXZWJSVEMgdXNhZ2UgKGUuZy4gdG8gcHJvdGVjdCBpbmNvbWUgZnJvbSBjYXJyaWVy IHRlbGVwaG9ueSB0cmFmZmljKSwgSSBjb3VsZCB1bmRlcnN0YW5kIGFuZCB3b3VsZCBmaWdodCB0 aGUgc2FtZSBiYXR0bGUuIEJ1dCBob3BlZnVsbHksIHRob3NlIGRheXMgYXJlIChzb29uKSBvdmVy IOKAkyBBdCBsZWFzdCBmb3J3YXJkIHRoaW5raW5nIGNhcnJpZXLigJlzIHJlYWxpemUgdGhhdCBh bHJlYWR5LiBXZWIgUlRDIHdpbGwgaGFwcGVuLiBXaGljaCBjdXN0b21lcnMgd2FudCB0byBwYXkg Zm9yIGFuIGFjY2VzcyB3aXRoIGJsb2NrZWQgV2ViUlRDPyBUaGUgY2FycmllcuKAmXMgb2ZmZXJp bmcvYXNzdXJpbmcgZ29vZCBXZWJSVEMgd2lsbCByYXRoZXIgZ2V0IHRoZSBjdXN0b21lcnMgYW5k IGluY29tZSDimLouIChNYXliZSB0aGUgV2ViIGJyb3dzZXIgY2FuIGRldGVjdCBhbmQgZW5jb3Vy YWdlIHRoaXPigKYpDQoNCklmIHRoZXJlIGFyZSB0ZWNobmljYWwgY29uY2VybnMgb2YgYmFkIHJl c3VsdCwgb3IgYmV0dGVyIG1ldGhvZHMgYWxsb3dpbmcgbmV0d29yayBwcm92aWRlcnMgYW5kIExB TiBtYW5hZ2VycyB0byBvZmZlciBhbmQgaW5mb3JtIHRoZSBicm93c2VyIHRoYXQgdGhlcmUgYXJl IGdvb2QgbWVkaWEgcGF0aHMgdG8gYmUgdXNlZCwgYW5kIHRoYXQgdGhlIHdlYiBicm93c2VyIGF1 dG9tYXRpY2FsbHkgY2FuIGNob3NlIHRob3NlLCB0aGVuIGxldCB1cyBhbGwgdW5kZXJzdGFuZCB0 aG9zZSwgc28gd2UgY2FuIGFjaGlldmUgd2hhdCBzaG91bGQgYmUgYWNoaWV2ZWQgYnkgdGhpcyBt aWxlc3RvbmUuDQoNClNreXBlLCBIYW5nb3V0cywgRmFjZXRpbWUgYXJlIGRvaW5nIGJpbGxpb25z IG9mIG1pbnV0ZXMgcGVyIHdlZWsgYW5kIHRoZSBJbnRlcm5ldCBoYXMgbm90IG1lbHRlZCB5ZXQu IElmIHdlIG5lZWQgdG8gZG8gZmxvdyBpZGVudGlmaWNhdGlvbiB0byBhbGxvdyB0cmFmZmljIHRv IGJlIHByaW9yaXRpemVkLCBmaW5lIChzZWUgYWJvdmUgcmVnYXJkaW5nIG15IHByZWZlcnJlZCBh cHByb2FjaCksIGJ1dCBmb3JjaW5nIGFsbCBXZWJSVEMgdHJhZmZpYyB0aHJvdWdoIGEgTUlUTSAo VFVSTiBzZXJ2ZXIpIGlzIGEgbXVjaCBiaWdnZXIganVtcCB0aGF0IEkgZG9uJ3QgeWV0IHNlZSB0 aGUganVzdGlmaWNhdGlvbiBmb3IuDQoNCkluIHNob3J0OiBUVVJOIGlzIGEgdGVjaG5vbG9neSB0 aGF0IGlzIHN1cHBvc2VkIHRvIGZhZGUgYXdheSB3aXRoIHRoZSBtb3ZlIHRvIElQdjYuIEkgZG9u J3QgdGhpbmsgd2Ugd2FudCB0byBtYWtlIGl0IGEgY3JpdGljYWwgZWxlbWVudCBvZiBXZWJSVEMu DQoNCi9LYXJsDQoNCg0KRnLDpW46IERhbiBXaW5nIFttYWlsdG86ZHdpbmdAY2lzY28uY29tPG1h aWx0bzpkd2luZ0BjaXNjby5jb20+XQ0KU2tpY2thdDogZGVuIDExIGZlYnJ1YXJpIDIwMTQgMTg6 MjUNClRpbGw6IE1hcmMgQmxhbmNoZXQNCktvcGlhOiBKdXN0aW4gVWJlcnRpOyB0aXJlZGR5QGlj aXNjby5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT47IEthcmwgU3RhaGw7IHRyYW1AaWV0 Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+OyBTaW1vbiBQZXJyZWF1bHQNCg0Kw4RtbmU6IFJl OiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlz bSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQoNCk9uIEZlYiAxMSwgMjAxNCwgYXQgOTowOCBB TSwgTWFyYyBCbGFuY2hldCA8bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYTxtYWlsdG86bWFyYy5i bGFuY2hldEB2aWFnZW5pZS5jYT4+IHdyb3RlOg0KDQpMZSAyMDE0LTAyLTExIMOgIDAwOjM5LCBE YW4gV2luZyA8ZHdpbmdAY2lzY28uY29tPG1haWx0bzpkd2luZ0BjaXNjby5jb20+PiBhIMOpY3Jp dCA6DQoNCg0KT24gRmViIDEwLCAyMDE0LCBhdCA1OjMwIFBNLCBKdXN0aW4gVWJlcnRpIDxqdWJl cnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpHb29k IHRvIHNlZSB0aGVyZSBpcyBhIGxvdCBvZiBpbnRlcmVzdCBmb3IgdGhpcyBtaWxlc3RvbmUuIEJ1 dCBiYXNlZCBvbiB0aGUgZGVzY3JpcHRpb24gaGVyZSwgaXQgc2VlbXMgbGlrZSB3ZSB3YW50IHRv IHVzZSBUVVJOIHByaW1hcmlseSB0byBpZGVudGlmeSBXZWJSVEMgZmxvd3MsIGFzIG9wcG9zZWQg dG8gdXNpbmcgaXQgYXMgYSBOQVQgdHJhdmVyc2FsIHRvb2wuIFRoaXMgbWFrZXMgbWUgY29uY2Vy bmVkIHRoYXQgd2UgbWF5IGJlIHVzaW5nIHRoZSB3cm9uZyB0ZWNobm9sb2d5IHRvIHNvbHZlIHRo ZSBwcm9ibGVtLg0KDQorMS4NCg0KSSB3b3VsZCBwcmVmZXIgYWxsb3dpbmcgZmxvd3MgdG8gZXN0 YWJsaXNoIHRoZW1zZWx2ZXMgdXNpbmcgdGhlaXIgJ2Jlc3QnIHBhdGgsIGFuZCB0aGUgYmVzdCBw YXRoIGlzIHNlbGRvbSB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIuICBXaGVuIHdlIGltYWdpbmUgSVB2 NiBpbiBvdXIgZnV0dXJlLCB3ZSBkb24ndCB3YW50IHRvIGZvcmNlIGFuIGFwcGxpY2F0aW9uLWxl dmVsIHByb3h5IChUVVJOKSBzZXJ2ZXIgb24gdGhlIHBhdGggc29sZWx5IGZvciB0cmF2ZXJzaW5n IGFuIElQdjYgZmlyZXdhbGwuDQoNCg0KSXQgc2VlbXMgdGhpcyB0aHJlYWQgaXMgY29uZmxhdGlu ZyBhbGwgdGhlIHBvc3NpYmxlIHJlYXNvbnMgLyBqdXN0aWZpY2F0aW9ucyBmb3IgVFVSTjoNCiAg KiBtb2JpbGl0eQ0KICAqIE5BVCB0cmF2ZXJzYWwgKGJvdGggZW5kcG9pbnRzIGFyZSBiZWhpbmQg ZW5kcG9pbnQtZGVwZW5kZW50IG1hcHBpbmcgTkFUcykNCiAgKiBmaXJld2FsbCB0cmF2ZXJzYWwg KGZpcmV3YWxsIGJsb2NrcyBVRFApDQogICogZW5oYW5jaW5nIHByaXZhY3kNCg0KVW5mb3J0dW5h dGVseSB0aGUgVFVSTiBzZXJ2ZXIgbm9yIHRoZSBlbmRwb2ludCByZWFsbHkga25vdyB3aGljaCBv ZiB0aG9zZSB1c2UtY2FzZXMgaXMgZGVzaXJlZCAoYnkgdGhlIHVzZXIgb3IgYnkgdGhlIElUIG5l dHdvcmsgYWRtaW5pc3RyYXRvcikgb3IgbmVjZXNzYXJ5IChmb3IgdGhlIGNhbGwgdG8gd29yayBh dCBhbGwpLg0KDQpEYW4sIHdoaWxlIEkgYWdyZWUgaW4gcHJpbmNpcGxlLCBJIGRvdWJ0IHRoYXQg YSB1c2VyIGNvdWxkIGV2ZXIgc2F5ICJJIHdhbnQgbW9iaWxpdHkgb3IgSSB3YW50IE5BVCB0cmF2 ZXJzYWwiLiBJIHRoaW5rIHRoZSB1c2VyIG9ubHkgd2FudCB0aGUgY2FsbCB0byBzdWNjZWVkLCB3 aGF0ZXZlciB0aGUgcHJvcGVydGllcyBvZiBpdHMgbmV0d29yayBwb2ludCBvZiBhdHRhY2htZW50 IGFyZS4NCg0KU28gd2hhdCBjYW4gd2UgZG8/ICBTaG91bGQgdGhlIFRVUk4gc2VydmVyIHByb3Zp ZGUgYW55IGFuZCBhbGwgc2VydmljZXMgdGhlIFRVUk4gY2xpZW50IG1pZ2h0IHBvc3NpYmx5IHdh bnQsIGFzIHRoYXQgaXMgd2hhdCBhIHJvYnVzdCBUVVJOIHNlcnZlciB3aWxsIGRvLCBhbmQgdGhl IGVuZHBvaW50IHNob3VsZCBwcmVmZXIgVFVSTiBjYW5kaWRhdGVzIG92ZXIgYWxsIG90aGVycyBi ZWNhdXNlIHRoZXJlIG1pZ2h0IGJlIHNvbWUgZnVuY3Rpb25hbGl0eSAvIHVzZWZ1bG5lc3Mgb2Yg VFVSTiB0aGF0IHRoZSB1c2VyIG1pZ2h0IGdhaW4gdGhyb3VnaCBUVVJOIChlLmcuLCBlbmhhbmNl ZCBwcml2YWN5KT8NCg0KLWQNCg0KDQoNCiBUaGlzIHNlZW1zIHByb2JsZW1hdGljLiAgUGVyaGFw cyB3ZSBuZWVkIGEgd2F5IHRvIHNpZ25hbCB0aGUgZGVzaXJlZCB1c2UtY2FzZSAoInRyYWl0Iiks IG9yIGFzIEp1c3RpbiBzdWdnZXN0cywgdXNpbmcgYSBkaWZmZXJlbnQgdGVjaG5vbG9neSBmb3Ig c29tZSBvZiB0aGVzZSB1c2UtY2FzZXMuDQoNCi1kDQoNCg0KDQoNCk9uIE1vbiwgRmViIDEwLCAy MDE0IGF0IDM6MTggUE0sIEthcmwgU3RhaGwgPGthcmwuc3RhaGxAaW50ZXJ0ZXguc2U8bWFpbHRv Omthcmwuc3RhaGxAaW50ZXJ0ZXguc2U+PiB3cm90ZToNClNpbW9uLA0KDQpHb29kIHF1ZXN0aW9u cyAtIHNlZSBpbmxpbmUgYmVsb3cgLS0+IC4NClNvbWUgbW9yZSB0aG91Z2h0IGlzIHJlcXVpcmVk IQ0KDQovS2FybA0KDQotLS0tLVVyc3BydW5nbGlndCBtZWRkZWxhbmRlLS0tLS0NCkZyw6VuOiB0 cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0cmFtLWJvdW5jZXNAaWV0 Zi5vcmc+XSBGw7ZyIFNpbW9uIFBlcnJlYXVsdA0KU2tpY2thdDogZGVuIDEwIGZlYnJ1YXJpIDIw MTQgMTU6MTYNClRpbGw6IEthcmwgU3RhaGw7IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0 Zi5vcmc+OyB0aXJlZGR5QGljaXNjby5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT4NCsOE bW5lOiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBt ZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KS2FybCwNCg0KSXQgaXMgZ3JlYXQg dG8gc2VlIHN1Y2ggZW50aHVzaWFzbSEgVGhhbmtzIQ0KDQpJIGhhdmUgYSBjb3VwbGUgdGVjaG5p Y2FsIHF1ZXN0aW9ucy4uLg0KDQpMZSAyMDE0LTAyLTA4IDA4OjExLCBLYXJsIFN0YWhsIGEgw6lj cml0IDoNCj4gLSBOb3RlIHRoYXQgdG8gYWNoaWV2ZSBzb21lIG9mIHRoZSBhYm92ZSBwb2ludHMs IFRVUk4gbXVzdCBiZSBmYXZvcmVkDQo+IG92ZXIgU1RVTiB0byBlbmZvcmNlIHRoYXQgdGhlIFRV Uk4tcGF0aCBhY3R1YWxseSBpcyB1c2VkLiAoVGhlIEFueWNhc3QNCj4gbWV0aG9kIHN1Z2dlc3Rl ZCBiZWxvdywg4oCcYXV0b21hdGljYWxseeKAnSBkb2VzIHRoaXMuKQ0KDQpJIHVuZGVyc3RhbmQg dGhlIFNUVU4gdnMgVFVSTiBwcmlvcml0eSBpc3N1ZS4gQnV0IEkgZG9uJ3Qgc2VlIGhvdyBhbnlj YXN0IGFmZmVjdHMgaXQgaW4gYW55IHdheS4gQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbj8NCi0tLSBH b29kIHBvaW50IC0gSSB3YXMgYSBiaXQgcXVpY2sgaGVyZSAobWF5YmUgdG9vIHF1aWNrKQ0KV2Ug aGF2ZSBnaXZlbiB0aGlzIHF1aXRlIGJpdCBvZiB0aG91Z2h0LCBzaW5jZSBldmVuIGlmIGEgVFVS TiBzZXJ2ZXIgaXMgcHJvdmlkZWQgYW5kIGRpc2NvdmVyZWQsIENVUlJFTlQgdXNhZ2Ugb2YgSUNF IG1heSBzdWdnZXN0IGEgY2FuZGlkYXRlIGZyb20gdGhlIHJlbW90ZSBwYXJ0eSB0aGF0IHdpbGwg bWFrZSBhIGNvbm5lY3Rpb24gd2l0aG91dCB0aGUgbmVlZC91c2FnZSBvZiB0aGUgVFVSTiBzZXJ2 ZXIgKHRoYXQgd2Ugd2FudGVkIHRvIGJlIHVzZWQgZm9yIHRoZSBnb29kIHB1cnBvc2VzIGxpc3Rl ZCkuDQoNClRoZSBvbmx5IHdheSB3ZSBmb3VuZCBhcm91bmQgdGhpcywgd2FzIHRvIHN0b3AgU1RV TiB0aHJvdWdoIHRoZSBJUCBkZWZhdWx0IGdhdGV3YXkgKGxpa2UgYSByZXN0cmljdGl2ZSBFbnRl cnByaXNlIGZpcmV3YWxsIGRvZXMgaW5oaWJpdGluZyBJQ0UgY29ubmVjdGl2aXR5LCB3aGljaCBv dGhlcnMgYXJlIGNvbmNlcm5lZCBhYm91dC4uLikuIFNpbmNlIHRoZSBwcm92aXNpb25pbmcgb2Yg YXV0by1kaXNjb3ZlcnkgdXNpbmcgdGhlIGFueWNhc3QgbWVjaGFuaXNtLCB3b3VsZCBiZSBhZGRp bmcgYSByb3V0ZSBpbiBhIGRlZmF1bHQgZ2F0ZXdheSwgYWRkaW5nIGEgZmlyZXdhbGwgcnVsZSB0 byBlYXQgU1RVTiBwYWNrZXRzIHdvdWxkIGFzc3VyZSB0aGF0IHRoZSBwcm92aXNpb25lZCBUVVJO IHNlcnZlciBhY3R1YWxseSBiZWNvbWVzIHVzZWQgKGFuZCBub3QgYnlwYXNzZWQgImJ5IGFjY2lk ZW50IikuIChUaGF0IHdhcyB0aGUgdGhvdWdodCBiZWhpbmQgdGhlIOKAnGF1dG9tYXRpY2FsbHni gJ0gd2l0aGluIHF1b3Rlcy4pDQoNCkJVVCwgc2luY2UgeW91IGJyb3VnaHQgdXAgdGhlIHF1ZXN0 aW9uLCBhc3N1bWluZyB0aGF0IHdlIGhhdmUgdGhlIHBvd2VyIHRvIGVuZm9yY2UgV2ViUlRDIHVz YWdlIG9mIElDRSwgSSBiZWxpZXZlIGEgTVVTVCByZXF1aXJlbWVudCB0byB1c2UgYW4gYXV0by1k aXNjb3ZlcmVkIFRVUk4gc2VydmVyIGluc3RlYWQgb2YgU1RVTiwgd291bGQgc29sdmUgdGhlIHNh bWUgcHJvYmxlbS4gSG93ZXZlciwgdGhpbmtpbmcgZnVydGhlciAoaW4gcmVsYXRpb24gdG8geW91 ciBuZXh0IHF1ZXN0aW9uIC0gImFueW9uZSBjb3VsZCBzZXQgdXAgYSBiYWRseS1tYWludGFpbmVk IiAtIGVuZm9yY2luZyBzdWNoIElDRSB1c2FnZSBtYXkgbm90IGJlIGdvb2QuKQ0KDQoNCj4gLSAz XnJkIFRoZSBBbnljYXN0IG1ldGhvZCBiZWxvdyDigJMgSSBzZWUgbm8gcHJvYmxlbQ0KPg0KPiBJ dCBhbHNvIGhhcyB0aGUgYWR2YW50YWdlIG9mIGVuY291cmFnaW5nIChidXQgbm90IHJlcXVpcmlu ZykgdGhlDQo+IFNUVU4vVFVSTiB0byBiZSBidWlsdCBpbiB0aGUgZGVmYXVsdCBnYXRld2F5IG9y IE5BVC9maXJld2FsbC9hY2Nlc3MNCj4gcm91dGVyIGl0c2VsZiwgd2l0aCBhIHNlY29uZCBpbnRl cmZhY2UgdG8gYSBwdWJsaWMgSVAgYWRkcmVzcyBvbiB0aGUNCj4gV0FOIHNpZGUuIChDdXJyZW50 IHZvbHVtZSBkZXBsb3llZCwgbG93IGNvc3QgTlNQIHRyaXBsZSBwbGF5IG1vZGVtcw0KPiB1c3Vh bGx5IGhhdmUgYSBxdWFsaXR5IGFzc3VyZWQgbGV2ZWwgMiBvciBsZXZlbCAzIFdBTiBwaXBlIGZv ciBqdXN0DQo+IHZvaWNlIChhbmQgYW5vdGhlciBmb3IgSVBUVikg4oCTIFRoZSBhbnljYXN0IGRp c2NvdmVyZWQgVFVSTi1zZXJ2ZXIgY2FuDQo+IGJlIHRoZSBhY2Nlc3MgZ2F0ZXdheSB0byBzdWNo IHF1YWxpdHkgcGlwZSBmb3IgV2ViUlRDIG1lZGlhLCBpbiBhDQo+IHNpbmdsZSBOU1AgcHJvdmlk ZWQgQ1BFLCBzY2FsaW5nIGZyb20gcmVzaWRlbnRpYWwgYW5kIHVwLikNCg0KU3VwcG9zZSB3ZSBk ZWZpbmUgd2VsbC1rbm93biBhbnljYXN0IFRVUk4gc2VydmVyIGFkZHJlc3Nlcy4gSG93IHdvdWxk IHRoaXMgbm90IGJlIHN1YmplY3QgdG8gdGhlIHNhbWUgc2VydmljZSBxdWFsaXR5IGlzc3VlcyB0 aGF0IHBsYWd1ZWQgNnRvND8gVGhhdCBpcywgYW55b25lIGNvdWxkIHNldCB1cCBhIGJhZGx5LW1h aW50YWluZWQsIHVuZGVyLXByb3Zpc2lvbmVkIFRVUk4gc2VydmVyIGFuZCBhbm5vdW5jZSBpdCBv dmVyIEJHUCB0byB0aGUgd29ybGQsIGFzIGl0IHdhcyBkb25lIGZvcg0KNnRvNCByZWxheXMuIE9y IGp1c3QgYmFkIEJHUCBvdXRib3VuZCBmaWx0ZXIgY29uZmlndXJhdGlvbi4gQW5kIGhvdyBjYW4g d2UgcHJldmVudCB0cmlhbmdsZSByb3V0aW5nPyBUaGVyZSBpcyBub3RoaW5nIGd1YXJhbnRlZWlu ZyB0aGF0IHRoZSBhbnljYXN0IHNlcnZlciB5b3Ugc2VlIGlzIGJlaW5nIHByb3ZpZGVkIHRvIHlv dSBieSB5b3VyIElTUCwgcmF0aGVyIHRoYW4gYSBzZXJ2ZXIgc2l0dGluZyBvbiB0aGUgb3RoZXIg c2lkZSBvZiB0aGUgcGxhbmV0Lg0KLS0tIEdvb2QgcG9pbnQgLSBuZWVkcyB0byBiZSByZXNvbHZl ZC4gRm9yIHRoaXMgSSBkb24ndCBoYXZlIGEgcmVhZHkgYW5zd2VyLi4uDQpBbiBhdXRvLWRpc2Nv dmVyZWQgVFVSTiBzZXJ2ZXIgbXVzdCBiZSB0cnVzdGVkICh3aGF0ZXZlciBtZXRob2QgaXQgaXMg ZGlzY292ZXJlZCBieSkuIFdlIGFyZSB0cnVzdGluZyB0aGUgb25lIHByb3ZpZGluZyB1cyB3aXRo IGFuIElQIGFkZHJlc3MgYW5kIGRlZmF1bHQgZ2F0ZXdheSBhbnl3YXkuIEl0IHdvdWxkIGJlIGVh c3kgaWYgd2UgY291bGQgcmV1c2UgdGhhdCB0cnVzdCwgaW5zdGVhZCBvZiBhbm90aGVyIG1lY2hh bmlzbXMuDQoNCklzIHRoZXJlIGEgZ29vZCB3YXkgZm9yIHRoZSBicm93c2VyIHRvIGNoZWNrIHRo YXQgdGhlIGFueWNhc3QgYWRkcmVzcyBpcyBub3QgaGFuZGxlZCBiZXlvbmQgdGhlIG5ldHdvcmsg c2VydmljZSBwcm92aWRlcidzIGRlZmF1bHQgZ2F0ZXdheT8gSWRlYXM/DQoNCg0KDQpUaGFua3Ms DQpTaW1vbg0KLS0NCkRUTiBtYWRlIGVhc3ksIGxlYW4sIGFuZCBzbWFydCAtLT4gaHR0cDovL3Bv c3RlbGxhdGlvbi52aWFnZW5pZS5jYTxodHRwOi8vcG9zdGVsbGF0aW9uLnZpYWdlbmllLmNhLz4N Ck5BVDY0L0ROUzY0IG9wZW4tc291cmNlICAgICAgICAtLT4gaHR0cDovL2VjZHlzaXMudmlhZ2Vu aWUuY2E8aHR0cDovL2VjZHlzaXMudmlhZ2VuaWUuY2EvPg0KU1RVTi9UVVJOIHNlcnZlciAgICAg ICAgICAgICAgIC0tPiBodHRwOi8vbnVtYi52aWFnZW5pZS5jYTxodHRwOi8vbnVtYi52aWFnZW5p ZS5jYS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K dHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0 cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90cmFtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86 dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJh bQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJh bSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KDQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0 DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg0K --_000_9F33F40F6F2CD847824537F3C4E37DDF17CF4032MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHByaW1lIHVzZSBjYXNlIGZv ciB0aGlzIGlzIGRvY3VtZW50ZWQgaW4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTEyI3NlY3Rp b24tMy4zLjUuMSI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dl Yi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xMiNzZWN0aW9uLTMuMy41LjE8L2E+IGFuZCBJ IHRoaW5rIHRoYXQgVFJBTSB3aWxsIHByb2JhYmx5IG1ha2UgZW5oYW5jZW1lbnRzIHRvIFRVUk4g ZW5hYmxpbmcgc3VjaCBhbiDigJxlbnRlcnByaXNlIGF1ZGl0aW5nIFRVUk4gc2VydmVy4oCdIHRv IGRvIGFuIGVmZmVjdGl2ZSBqb2Igb2YgbWFuYWdpbmcgV2ViUlRDIHRyYWZmaWMNCiBpbiBhbiBl bnRlcnByaXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIG9mIGNvdXJzZSBtb3JlIHRoYW4gb25lIHBy b2JsZW0gYW5kIG1hbnkgcG9zc2libHkgd2F5cyB0byBzb2x2ZSB0aGVtIGFuZCBJIHJlY2VudGx5 IHVwZGF0ZWQNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1dHRv bi1ydGN3ZWItbmF0LWZpcmV3YWxsLWNvbnNpZGVyYXRpb25zLTAzIj4NCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWh1dHRvbi1ydGN3ZWItbmF0LWZpcmV3YWxsLWNvbnNpZGVyYXRp b25zLTAzPC9hPiB0byBsaXN0IHRoZXNlIGZvciBkaXNjdXNzaW9uIGluY2x1ZGluZyBQQ1AuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5VbmZvcnR1bmF0ZWx5IHNvbHV0aW9ucyBhcmUgbmVlZGVkIHRvZGF5IHdpdGhpbiBl eGlzdGluZyBuZXR3b3JrcyBhbmQgUENQIGRvZXMgbm90IHNlZW0gc28gdXNlZnVsIGhlcmUgc28g d2UgaGF2ZSB0byBsb29rIGF0IG11bHRpcGxlIHNvbHV0aW9ucyBhbmQgcHJvYmFibHkNCiBXZWJS VEMgYnJvd3NlcnMgaGF2ZSB0byBzdXBwb3J0IGEgbnVtYmVyIG9mIG1lY2hhbmlzbXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUaXJ1 bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIFttYWlsdG86dGlyZWRkeUBjaXNjby5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gMTMgRmVicnVhcnkgMjAxNCAwMzozNzxicj4NCjxiPlRvOjwvYj4gSHV0 dG9uLCBBbmRyZXc7IEp1c3RpbiBVYmVydGk7IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBl cnVtYWwpPGJyPg0KPGI+Q2M6PC9iPiB0aXJlZGR5QGljaXNjby5jb207IFNpbW9uIFBlcnJlYXVs dDsgT2xlZyBNb3NrYWxlbmtvOyB0cmFtQGlldGYub3JnOyBNYXJjIEJsYW5jaGV0OyBEYW4gV2lu ZyAoZHdpbmcpOyBLYXJsIFN0YWhsPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbdHJhbV0gTWls ZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJw cmlzZSBhbmQgSVNQczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBBbmR5LDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhlcmUgYXJlIG90aGVyIHdheXMgdG8gc29sdmUgdGhlIHByb2JsZW0gZm9yIGV4 YW1wbGUgdXNpbmcgUENQLiBDYW4geW91IGNsYXJpZnkgaG93IGRlcGxveWluZyBhIFRVUk4gc2Vy dmVyIGluIHRoZSBFbnRlcnByaXNlIHByb3RlY3RzIHRoZSB1c2VycyBhbmQgdGhlIG5ldHdvcmsN CiA/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+LVRpcnUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBbPGEgaHJlZj0ibWFpbHRvOnRyYW0t Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPkh1dHRvbiwgQW5kcmV3PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBGZWJydWFyeSAxMywgMjAxNCAxOjAwIEFNPGJyPg0KPGI+VG86PC9iPiBKdXN0aW4gVWJlcnRp OyBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKTxicj4NCjxiPkNjOjwvYj4gPGEg aHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbSI+dGlyZWRkeUBpY2lzY28uY29tPC9hPjsg U2ltb24gUGVycmVhdWx0OyBPbGVnIE1vc2thbGVua287DQo8YSBocmVmPSJtYWlsdG86dHJhbUBp ZXRmLm9yZyI+dHJhbUBpZXRmLm9yZzwvYT47IE1hcmMgQmxhbmNoZXQ7IERhbiBXaW5nIChkd2lu Zyk7IEthcmwgU3RhaGw8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBNaWxlc3RvbmUg MzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFu ZCBJU1BzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBjYXNlIHdoZXJlIHRo ZSBUVVJOIHNlcnZlciBpcyB0aGUgb25seSBvcHRpb24gbWF5IGJlY29tZSBjb21tb24gd2l0aGlu IGVudGVycHJpc2UgbmV0d29ya3MgYW5kIHRoYXQgbWlnaHQgYmUgZGVsaWJlcmF0ZSBlbnRlcnBy aXNlIHBvbGljeSBiZWNhdXNlIGl0IHByb3ZpZGVzDQogdGhlIGJldHRlciBwYXRoIChVRFAgdGhy b3VnaCB0aGUgRi9XKSBhbmQgcHJvdGVjdHMgdGhlIHVzZXJzIGFuZCB0aGUgbmV0d29yay48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRyYW0gWzwvc3Bhbj48YSBocmVm PSJtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxi PlNlbnQ6PC9iPiAxMiBGZWJydWFyeSAyMDE0IDE3OjQ2PGJyPg0KPGI+VG86PC9iPiBNdXRodSBB cnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKTxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij50aXJlZGR5QGljaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij47IFNpbW9uIFBlcnJlYXVsdDsgT2xlZyBNb3NrYWxlbmtvOw0KPC9zcGFuPjxhIGhyZWY9Im1h aWx0bzp0cmFtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRm Lm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgTWFyYyBCbGFuY2hl dDsgRGFuIFdpbmcgKGR3aW5nKTsgS2FybCBTdGFobDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20g Zm9yIGVudGVycHJpc2UgYW5kIElTUHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWUuIElmIFRVUk4gaXMgaW5kZWVkIGJlaW5nIHByb3Zp ZGVkIGZvciB0aGUgdXNlcidzIGJlbmVmaXQsIHRoZSBjbGllbnQncyBJQ0UgbG9naWMgKGJhc2Vk IG9uIFJUVCBvciBzaW1pbGFyKSBzaG91bGQgcmVzdWx0IGluIGl0IHByZWZlcnJpbmcgdGhlIFRV Uk4gcGF0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgMTIsIDIwMTQgYXQgMToyNyBB TSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgJmx0OzxhIGhyZWY9Im1haWx0 bzptcGVydW1hbEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tcGVydW1hbEBjaXNjby5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+WWVzLCBJIGJlbGlldmUgdGhlIHNlY29uZCBjYXNlIGlzIHJh cmUsIGJ1dCB3b3VsZCBiZSBiZXR0ZXIgdGhhbiBhIHJhdCByYWNlIGIvdyBhZG1pbmlzdHJhdG9y cyB0cnlpbmcgdG8gYmxvY2sgcDJwIHRyYWZmaWMNCiBhbmQgZm9yY2UgaXQgdGhyb3VnaCBhIFRV Uk4gc2VydmVyIGFuZCBhcHBzL2VuZHBvaW50cyBmaW5kaW5nIHNtYXJ0ZXIgd2F5cyB0byBieXBh c3MgdGhlbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5NdXRodTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT2xlZyBNb3NrYWxlbmtvIFttYWls dG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptb20wNDAyNjdAZ21haWwuY29tIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1vbTA0MDI2N0BnbWFpbC5jb208L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAxNCAxOjA3IFBNPGJyPg0KPGI+VG86PC9iPiBNdXRo dSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKTxicj4NCjxiPkNjOjwvYj4gSnVzdGluIFVi ZXJ0aTsgS2FybCBTdGFobDsgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dGlyZWRkeUBp Y2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ow0KIE1hcmMg QmxhbmNoZXQ7IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBEYW4gV2luZyAoZHdpbmcpOyBTaW1vbiBQ ZXJyZWF1bHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBU VVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElT UHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIFRVUk4gc2VydmVyIGhhcyB0byBiZSB1c2Vk IHdoZW4gaXQgaXMgZWl0aGVyIHRoZSBvbmx5IG9wdGlvbiwgb3IgaWYgaXQgcHJvdmlkZXMgYSBi ZXR0ZXIgcGF0aCAoSSBndWVzcyB0aGUgc2Vjb25kIGNhc2UgaXMgcmF0aGVyIHJhcmUpLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZlYiAxMSwgMjAxNCBhdCAx MTozMiBQTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgJmx0OzxhIGhyZWY9 Im1haWx0bzptcGVydW1hbEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tcGVydW1hbEBjaXNj by5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0MzsxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Rm9yY2luZyBhbGwgdHJhZmZp YyB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgYW5kIGV4cGVjdGluZyBpdCB3b3VsZCBwcm92aWRlIHRo ZSBiZXN0IHVzZXIgZXhwZXJpZW5jZSBkb2Vzbid0IGxvb2sgdGhlIHJpZ2h0DQogYXBwcm9hY2gu IEluc3RlYWQsIGlmIGEgcGF0aCB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgZXhpc3RzIGFuZCBkb2Vz IHByb3ZpZGUgbG93ZXIgUlRULCBqaXR0ZXIgZXRjLCBiZWluZyBhYmxlIHRvIGRldGVjdCBhbmQg dXNlIChvciBzd2l0Y2ggdG8pIHRoYXQgcGF0aCBtaWdodCBiZSBkZXNpcmFibGUuLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk11 dGh1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiB0cmFtIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0 cmFtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+dHJhbS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQgMTE6NDMgQU08YnI+DQo8Yj5U bzo8L2I+IEthcmwgU3RhaGw8YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86 dGlyZWRkeUBpY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPnRpcmVkZHlAaWNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjsgTWFyYyBCbGFuY2hldDsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGll dGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBEYW4gV2luZyAo ZHdpbmcpOyBTaW1vbiBQZXJyZWF1bHQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBN aWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRl cnByaXNlIGFuZCBJU1BzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklubGluZS48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBGZWIgMTEsIDIwMTQgYXQgMjozNyBQTSwg S2FybCBTdGFobCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthcmwuc3RhaGxAaW50ZXJ0ZXguc2UiIHRh cmdldD0iX2JsYW5rIj5rYXJsLnN0YWhsQGludGVydGV4LnNlPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5MaXN0ZW5pbmcgdG8gdGhpcyB0aHJlYWQsIEkg YW0gYWZyYWlkIHdlIGFyZSBtaXNzaW5nIHRoZSB2ZXJ5IHBvaW50IGFuZCBuZWNlc3NpdHkgZm9y IHRoaXMgbWlsZXN0b25lITwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIFRoZXJlIGFyZSBz ZXZlcmUgTkFUIHRyYXZlcnNhbCBhbmQgcXVhbGl0eSBpc3N1ZXMgdGhhdCBzaG91bGQgYW5kIGNh biBiZSBkZWFsdCB3aXRoIGJ5IGEgZ29vZCBhdXRvLWRpc2NvdmVyeQ0KIG1lY2hhbmlzbSBhbmQg dGhlIHJpZ2h0IHVzYWdlIGJ5IHRoZSB0dXJuIGNsaWVudCAodGhlIFdlYlJUQyBicm93c2VyKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1 ZSI+VGhlcmUgYXJlIHdheXMsIG5vdCBvbmx5Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5FbnRlcnByaXNl cyBvciBJU1BzIHdpc2hpbmcgdG8gcHJvdmlkZSB0aGVpciBvd24gVFVSTiBzZXJ2ZXIsIGluIGFu IGF0dGVtcHQgdG8gcmVkdWNlIHNvLWNhbGxlZCAmcXVvdDt0cmlhbmdsZSByb3V0aW5nJnF1b3Q7 LG5lZWQgYSBuZXcgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPkJ1dCBhbHNvOiAtIE5TUHMgKE5ldHdvcmsgU2VydmljZSBQcm92aWRlcnMpIHdhbnQg dG8gcHJvdmlkZSBhIHBhdGggd2hlcmUgdGhlIGJhbmR3aWR0aCBvZiBXZWJSVEMgaXMgYmV0dGVy DQogY29wZWQgd2l0aC48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0gTlNQcyBv ciBFbnRlcnByaXNlcyB3YW50IHRvIG9mZmVyIGFuIEludGVybmV0IGFjY2VzcyBxdWFsaXR5IHBp cGUgZm9yIHByaW9yaXRpemVkIFJUQyAoUmVhbCBUaW1lIENvbW11bmljYXRpb24pDQogdHJhZmZp Yy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0gRW50ZXJwcmlzZXMgaGF2aW5nIHJlc3Ry aWN0aXZlIGZpcmV3YWxscywgd2FudCB0byBwcm92aWRlIGEgVURQLXBhdGggZm9yIFdlYlJUQyBh bmQgcG9zc2libHkgYWxzbyBmb3INCiBiZXR0ZXIgcXVhbGl0eSB3aGVyZSBSVEMgZG8gbm90IGNv bXBldGUgd2l0aCBkYXRhIHRyYWZmaWMuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPkFsc28gY29uc2lkZXJpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0g TW9iaWxpdHk7IEl0IGlzIGNvbW1vbiB0byBtb3ZlIGZyb20gYSBMQU4gdG8gYWNjZXNzaW5nIHZp YSBXaUZpIG9yIDNHLzRHIE9UVCBjaGFubmVscywgYWxsIHNob3VsZCBiZQ0KIGFibGUgdG8gYXV0 b21hdGljYWxseSBvZmZlciB0aGVpciBvd24gb3B0aW1hbCBUVVJOIHNlcnZlcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVl Ij5UaGlzIGxlYWRzIHVzIGludG8NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDvigJxUVVJO4oCmdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dz4oCdDQo8c3BhbiBzdHls ZT0iY29sb3I6Ymx1ZSI+ZXRjISBJdCBpcyBub3QgYSBtaXN0YWtlLCBidXQgdGhlIHZlcnkgbmVl ZCBmb3IgdGhpcyBtaWxlc3RvbmUhPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWdhaW4sIGl0IGhh cyBub3QgYmVlbiBkZW1vbnN0cmF0ZWQgd2h5IFRVUk4gaXMgdGhlIHJpZ2h0IHRlY2hub2xvZ3kg aGVyZSwgY29tcGFyZWQgdG8gYSBtb3JlIHRyYW5zcGFyZW50IGZsb3cgaWRlbnRpZmljYXRpb24g dG9vbCBsaWtlIE1BTElDRS4gV2UgZG9uJ3QgZm9yY2UgYWxsIEhUVFAgcmVxdWVzdHMNCiB0byBs b2NhdGUgYSBIVFRQIHByb3h5IHZpYSBhbnljYXN0LCBJIGRvbid0IHNlZSB3aHkgd2UgbmVlZCB0 byBkbyB0aGUgc2FtZSBmb3IgV2ViUlRDLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5XaGF0IGFyZSB0aGUg aGVzaXRhdGlvbnMgcmFpc2VkIGhlcmU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBU VVJOIHByaW1hcmlseSB0byBpZGVudGlmeSBXZWJSVEMgZmxvd3MsIGFzIG9wcG9zZWQgdG8gdXNp bmcgaXQgYXMgYSBOQVQgdHJhdmVyc2FsIHRvb2wuIFRoaXMgbWFrZXMgbWUgY29uY2VybmVkDQog dGhhdCB3ZSBtYXkgYmUgdXNpbmcgdGhlIHdyb25nIHRlY2hub2xvZ3kgdG8gc29sdmUgdGhlIHBy b2JsZW08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JdCBpcyBjb3JyZWN0IHRo YXQgSUNFL1NUVU4vVFVSTiB3YXMgZGVzaWduZWQgdG8gYWRkcmVzcyB0aGUgTkFUL0ZpcmV3YWxs IHRyYXZlcnNhbCBwcm9ibGVtIGFzc29jaWF0ZWQNCiB3aXRoIHJlYWwtdGltZSBjb21tdW5pY2F0 aW9uIChTSVAgYXQgdGhhdCB0aW1lKS4gSG93ZXZlciwgaXRzIGxhcmdlc3QgZmxhdy9wcm9ibGVt IGlzIHRoYXQgcXVhbGl0eSB0aGluZ3Mgd2VyZSBub3QgKGNvdWxkIG5vdCBiZT8pIGNvbnNpZGVy ZWQuIFRoZSBtZXRob2TigJlzIHZlcnkgaWRlYSAobGlrZSBhbGwgc2ltaWxhciBtZXRob2RzIGZv ciBnZXR0aW5nIFJUQyB0aHJvdWdoIG9yZGluYXJ5IE5BVC9GaXJld2FsbHMpIGlzIHRvIGZvb2wg dGhlIG1lZGlhDQogdGhyb3VnaCBhIE5BVC9GaXJld2FsbCB0aGF0IGlzIHVuYXdhcmUgb2Ygd2hh dCBpcyBoYXBwZW5pbmcuIFRodXMsIHRoaXMgaXMgcm9vdCBvZiBxdWFsaXR5IGlzc3VlcyAoYW5k IGJhbmR3aWR0aCBhbGxvY2F0aW9uIG9wdGltaXphdGlvbikgdGhhdCBuZWVkcyB0byBiZSBkZWFs dCB3aXRoOiBSZWFsLXRpbWUgdHJhZmZpYyBmaWdodGluZyB3aXRoIGEgZGF0YSB0cmFmZmljIGNy b3dkZWQgY29uZ2VzdGlvbiBwb2ludC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkg dGhpbmsgdGhhdCAmcXVvdDtmb29saW5nJnF1b3Q7IGlzIGFuIGluY29ycmVjdCBkZXNjcmlwdGlv bi4gVGhlIE5BVCBpcyBzdXBwb3NlZCB0byBiZSB0cmFuc3BhcmVudCB0byB0aGUgY2xpZW50Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj5CdXQsIGEgQkxFU1NJTkcgb2YgSUNFL1NUVU4vVFVSTiBpcyB0aGF0IGl0IGNh biBiZSBzZWVuIGFzIGEgbGVnaXRpbWF0ZSByZXF1ZXN0IGZvciBhIHN1aXRhYmxlIHBpcGUgZm9y DQogcXVhbGl0eSBkZW1hbmRpbmcgcmVhbCB0aW1lIHRyYWZmaWMuIDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6Ymx1ZSI+Sjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPg0KPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsdWUiPklDRSBpcyBhIHByZS1wcm90b2NvbCB5b3UgdXNlIGJlY2F1c2UgeW91 IHdhbnQgYSBwYXRoIGZvciByZWFsLXRpbWUgbWVkaWEgYmV0d2VlbiBwYXJ0aWVzLiBIZXJlOiBU aGUgYnJvd3Nlcg0KIHNheXMga25vY2sga25vY2ssIEkgd2FudCB0byBnZXQgbWVkaWEgdGhyb3Vn aCAoYW5kIG9mIGNvdXJzZSB3aXRoIGFzIGdvb2QgcXVhbGl0eSBhcyByZXF1aXJlZCBhbmQgcG9z c2libGUpLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj5JZiB0aGUgTkFUL0ZpcmV3YWxsIG93bmVyIGFuZCBuZXR3b3JrIG93bmVy IGFyZSBhbGxvd2VkIHRvIHNlZSB0aGVzZSByZXF1ZXN0cywgdGhleSBjYW4gaGVscC9hc3Npc3Qg aW4NCiBhY2hpZXZpbmcgdGhlIGdvb2QgbWVkaWEgcGF0aC4gSWYgdGhleSBhcmUgbm90IGF3YXJl LCB0aGV5IGNhbm5vdCBoZWxwITwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj5Ib3BlIHRoaXMgbWFkZSBpdCB1bmRlcnN0YW5kYWJsZSBvbiBhbiBvdmVydmlldyBsZXZl bCBob3cgdGhpcyBjYW4gYmVjb21lPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pg0KIOKAnFRVUk7igKZ0byBpZGVudGlmeSBXZWJSVEMgZmxvd3PigJ08L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Ymx1ZSI+SXQgaXMgYWxzbyB0aGUgT05MWSB3YXkgSSBjYW4gc2VlIHRvIGFjaGlldmUg d2hhdCB3ZSB3YW50IHRvIGFjaGlldmUgYW5kIHNob3VsZCBiZSB0aGUgYWltIGFuZCByZXF1aXJl bWVudA0KIG9mIHRoaXMgbWlsZXN0b25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SSBhbSB0YWxraW5nIGFib3V0IGdlbmVyYWwg dXNhZ2Ugb2YgV2ViUlRDIG92ZXIgSW50ZXJuZXQvbW9iaWxlIE9UVCAobm90IGZlZWRpbmcgV2Vi UlRDIGludG8gYXBwbGljYXRpb24NCiBzcGVjaWZpYyBuZXR3b3JrcyBsaWtlIElNUyB3aGVyZSBv dGhlciBtZXRob2RzIG1heSBleGlzdCkuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhpcyBpcyBnb29kLCBub3QgZXZpbCE8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi PklmIHRoZSBoZXNpdGF0aW9ucyBhcmUgcmFpc2VkIGJlY2F1c2Ugb2YgYSBiZWxpZWYvaG9wZS93 aXNoIHRoYXQgdGhlcmUgYXJlIG5vIG9yIHdpbGwgbm90IGJlIHNldmVyZSBxdWFsaXR5DQogaXNz dWVzIOKAnGJlY2F1c2UgaXQgaXMgYWxsIGFib3V0IGJhbmR3aWR0aOKAnSwg4oCcaXQgd2lsbCBy ZXNvbHZlIGl0c2VsZiB3aXRoIHRpbWXigJ0gZXRjLiwgSSBzdHJvbmdseSBvYmplY3QhIFRoYXQg aXMgd3JvbmcgYW5kIHdpbGwgYmUgdmVyeSBkZXRyaW1lbnRhbCBmb3IgV2ViUlRDIHVzYWdlLiBX ZSBhbHJlYWR5IHNlZSBpdCBhbmQgSSBjYW4gZ2l2ZSBudW1lcm91cyBleGFtcGxlcyBvZiBob3cg bXVjaCBsZXNzIHF1YWxpdHkgZGVtYW5kaW5nIFZvSVANCiBpcy9pcyBub3QgaGFuZGxlZCBxdWFs aXR5IHdpc2UgYW5kIHRoYXQgaXQgbWF0dGVycy4gQW5kLCB3aGF0IHdvdWxkIGJlIGJhZCBjb25z aWRlcmluZyBxdWFsaXR5IGlzc3VlcyBhbmQgYWxsb3dpbmcvZW5jb3VyYWdpbmcgbWV0aG9kcyB0 byBkZWFsIHdpdGggdGhlbT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1 ZSI+SWYgdGhlIGhlc2l0YXRpb25zIGFyZSByYWlzZWQsIGJlY2F1c2Ugb2Ygc3VzcGljaW9uIHRo YXQgdGhlIG1ldGhvZHMgd2UgbWF5IHJlY29tbWVuZCBtYXkgYmUgbWlzdXNlZCB0bw0KIHN0b3Av YmxvY2svZGVzdHJveSBXZWJSVEMgdXNhZ2UgKGUuZy4gdG8gcHJvdGVjdCBpbmNvbWUgZnJvbSBj YXJyaWVyIHRlbGVwaG9ueSB0cmFmZmljKSwgSSBjb3VsZCB1bmRlcnN0YW5kIGFuZCB3b3VsZCBm aWdodCB0aGUgc2FtZSBiYXR0bGUuIEJ1dCBob3BlZnVsbHksIHRob3NlIGRheXMgYXJlIChzb29u KSBvdmVyIOKAkyBBdCBsZWFzdCBmb3J3YXJkIHRoaW5raW5nIGNhcnJpZXLigJlzIHJlYWxpemUg dGhhdCBhbHJlYWR5LiBXZWIgUlRDIHdpbGwNCiBoYXBwZW4uIFdoaWNoIGN1c3RvbWVycyB3YW50 IHRvIHBheSBmb3IgYW4gYWNjZXNzIHdpdGggYmxvY2tlZCBXZWJSVEM/IFRoZSBjYXJyaWVy4oCZ cyBvZmZlcmluZy9hc3N1cmluZyBnb29kIFdlYlJUQyB3aWxsIHJhdGhlciBnZXQgdGhlIGN1c3Rv bWVycyBhbmQgaW5jb21lDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOmJsdWUiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibHVlIj4uIChNYXliZSB0aGUgV2ViIGJyb3dzZXIgY2FuIGRldGVjdCBh bmQgZW5jb3VyYWdlIHRoaXPigKYpPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVl Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SWYgdGhlcmUgYXJlIHRlY2huaWNh bCBjb25jZXJucyBvZiBiYWQgcmVzdWx0LCBvciBiZXR0ZXIgbWV0aG9kcyBhbGxvd2luZyBuZXR3 b3JrIHByb3ZpZGVycyBhbmQgTEFOIG1hbmFnZXJzDQogdG8gb2ZmZXIgYW5kIGluZm9ybSB0aGUg YnJvd3NlciB0aGF0IHRoZXJlIGFyZSBnb29kIG1lZGlhIHBhdGhzIHRvIGJlIHVzZWQsIGFuZCB0 aGF0IHRoZSB3ZWIgYnJvd3NlciBhdXRvbWF0aWNhbGx5IGNhbiBjaG9zZSB0aG9zZSwgdGhlbiBs ZXQgdXMgYWxsIHVuZGVyc3RhbmQgdGhvc2UsIHNvIHdlIGNhbiBhY2hpZXZlIHdoYXQgc2hvdWxk IGJlIGFjaGlldmVkIGJ5IHRoaXMgbWlsZXN0b25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+U2t5cGUsIEhhbmdvdXRzLCBGYWNldGltZSBhcmUgZG9pbmcgYmlsbGlvbnMgb2YgbWlu dXRlcyBwZXIgd2VlayBhbmQgdGhlIEludGVybmV0IGhhcyBub3QgbWVsdGVkIHlldC4gSWYgd2Ug bmVlZCB0byBkbyBmbG93IGlkZW50aWZpY2F0aW9uIHRvIGFsbG93IHRyYWZmaWMgdG8gYmUgcHJp b3JpdGl6ZWQsIGZpbmUNCiAoc2VlIGFib3ZlIHJlZ2FyZGluZyBteSBwcmVmZXJyZWQgYXBwcm9h Y2gpLCBidXQgZm9yY2luZyBhbGwgV2ViUlRDIHRyYWZmaWMgdGhyb3VnaCBhIE1JVE0gKFRVUk4g c2VydmVyKSBpcyBhIG11Y2ggYmlnZ2VyIGp1bXAgdGhhdCBJIGRvbid0IHlldCBzZWUgdGhlIGp1 c3RpZmljYXRpb24gZm9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SW4gc2hvcnQ6IFRVUk4gaXMgYSB0ZWNobm9sb2d5IHRoYXQgaXMg c3VwcG9zZWQgdG8gZmFkZSBhd2F5IHdpdGggdGhlIG1vdmUgdG8gSVB2Ni4gSSBkb24ndCB0aGlu ayB3ZSB3YW50IHRvIG1ha2UgaXQgYSBjcml0aWNhbCBlbGVtZW50IG9mIFdlYlJUQy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+L0thcmw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5GcsOlbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gRGFuIFdpbmcgW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmR3aW5nQGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kd2lu Z0BjaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+ DQo8Yj5Ta2lja2F0OjwvYj4gZGVuIDExIGZlYnJ1YXJpIDIwMTQgMTg6MjU8YnI+DQo8Yj5UaWxs OjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TWFyYyBC bGFuY2hldDxicj4NCjxiPktvcGlhOjwvYj4gSnVzdGluIFViZXJ0aTsgPC9zcGFuPjxhIGhyZWY9 Im1haWx0bzp0aXJlZGR5QGljaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRpcmVkZHlAaWNpc2NvLmNvbTwvc3Bhbj48L2E+PHNw YW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47DQogS2FybCBTdGFobDsgPC9zcGFu PjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFu Zz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgU2ltb24gUGVycmVhdWx0PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IlNWIj48YnI+DQo8Yj7DhG1uZTo8L2I+IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6 IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQg SVNQczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPk9uIEZlYiAxMSwgMjAxNCwgYXQg OTowOCBBTSwgTWFyYyBCbGFuY2hldCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYXJjLmJs YW5jaGV0QHZpYWdlbmllLmNhIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiPm1hcmMu YmxhbmNoZXRAdmlhZ2VuaWUuY2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIj4mZ3Q7DQogd3Jv dGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+TGUgMjAxNC0wMi0xMSDDoCAwMDozOSwgRGFu IFdpbmcgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHdpbmdAY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiPmR3aW5nQGNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4g bGFuZz0iU1YiPiZndDsgYSDDqWNyaXQgOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1Yi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCk9uIEZlYiAxMCwgMjAxNCwgYXQgNTozMCBQ TSwgSnVzdGluIFViZXJ0aSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+anViZXJ0aUBnb29nbGUuY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jmd0Ow0KIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1Yi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkdvb2QgdG8gc2VlIHRoZXJlIGlzIGEgbG90IG9mIGlu dGVyZXN0IGZvciB0aGlzIG1pbGVzdG9uZS4gQnV0IGJhc2VkIG9uIHRoZSBkZXNjcmlwdGlvbiBo ZXJlLCBpdCBzZWVtcw0KIGxpa2Ugd2Ugd2FudCB0byB1c2UgVFVSTiBwcmltYXJpbHkgdG8gaWRl bnRpZnkgV2ViUlRDIGZsb3dzLCBhcyBvcHBvc2VkIHRvIHVzaW5nIGl0IGFzIGEgTkFUIHRyYXZl cnNhbCB0b29sLiBUaGlzIG1ha2VzIG1lIGNvbmNlcm5lZCB0aGF0IHdlIG1heSBiZSB1c2luZyB0 aGUgd3JvbmcgdGVjaG5vbG9neSB0byBzb2x2ZSB0aGUgcHJvYmxlbS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mIzQzOzEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SSB3b3VsZCBwcmVmZXIgYWxsb3dpbmcgZmxvd3MgdG8gZXN0YWJsaXNoIHRo ZW1zZWx2ZXMgdXNpbmcgdGhlaXIgJ2Jlc3QnIHBhdGgsIGFuZCB0aGUgYmVzdCBwYXRoIGlzDQog c2VsZG9tIHRocm91Z2ggYSBUVVJOIHNlcnZlci4gJm5ic3A7V2hlbiB3ZSBpbWFnaW5lIElQdjYg aW4gb3VyIGZ1dHVyZSwgd2UgZG9uJ3Qgd2FudCB0byBmb3JjZSBhbiBhcHBsaWNhdGlvbi1sZXZl bCBwcm94eSAoVFVSTikgc2VydmVyIG9uIHRoZSBwYXRoIHNvbGVseSBmb3IgdHJhdmVyc2luZyBh biBJUHY2IGZpcmV3YWxsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkl0IHNlZW1z IHRoaXMgdGhyZWFkIGlzIGNvbmZsYXRpbmcgYWxsIHRoZSBwb3NzaWJsZSByZWFzb25zIC8ganVz dGlmaWNhdGlvbnMgZm9yIFRVUk46PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7ICogbW9iaWxpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDsgKiBOQVQgdHJhdmVyc2FsIChib3RoIGVuZHBvaW50cyBhcmUg YmVoaW5kIGVuZHBvaW50LWRlcGVuZGVudCBtYXBwaW5nIE5BVHMpPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICombmJzcDtmaXJld2FsbCB0cmF2ZXJz YWwgKGZpcmV3YWxsIGJsb2NrcyBVRFApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7ICogZW5oYW5jaW5nIHByaXZhY3k8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5VbmZvcnR1bmF0ZWx5IHRoZSBUVVJOIHNlcnZlciBub3IgdGhl IGVuZHBvaW50IHJlYWxseSBrbm93IHdoaWNoIG9mIHRob3NlIHVzZS1jYXNlcyBpcyBkZXNpcmVk IChieSB0aGUNCiB1c2VyIG9yIGJ5IHRoZSBJVCBuZXR3b3JrIGFkbWluaXN0cmF0b3IpIG9yIG5l Y2Vzc2FyeSAoZm9yIHRoZSBjYWxsIHRvIHdvcmsgYXQgYWxsKS4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+RGFuLCB3aGlsZSBJIGFncmVl IGluIHByaW5jaXBsZSwgSSBkb3VidCB0aGF0IGEgdXNlciBjb3VsZCBldmVyIHNheSAmcXVvdDtJ IHdhbnQgbW9iaWxpdHkgb3IgSSB3YW50IE5BVCB0cmF2ZXJzYWwmcXVvdDsuIEkgdGhpbmsgdGhl IHVzZXIgb25seSB3YW50IHRoZSBjYWxsIHRvIHN1Y2NlZWQsIHdoYXRldmVyDQogdGhlIHByb3Bl cnRpZXMgb2YgaXRzIG5ldHdvcmsgcG9pbnQgb2YgYXR0YWNobWVudCBhcmUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPlNvIHdo YXQgY2FuIHdlIGRvPyAmbmJzcDtTaG91bGQgdGhlIFRVUk4gc2VydmVyIHByb3ZpZGUgYW55IGFu ZCBhbGwgc2VydmljZXMgdGhlIFRVUk4gY2xpZW50IG1pZ2h0IHBvc3NpYmx5IHdhbnQsIGFzIHRo YXQgaXMgd2hhdCBhIHJvYnVzdCBUVVJOIHNlcnZlciB3aWxsIGRvLCBhbmQgdGhlDQogZW5kcG9p bnQgc2hvdWxkIHByZWZlciBUVVJOIGNhbmRpZGF0ZXMgb3ZlciBhbGwgb3RoZXJzIGJlY2F1c2Ug dGhlcmUgbWlnaHQgYmUgc29tZSBmdW5jdGlvbmFsaXR5IC8gdXNlZnVsbmVzcyBvZiBUVVJOIHRo YXQgdGhlIHVzZXIgbWlnaHQgZ2FpbiB0aHJvdWdoIFRVUk4gKGUuZy4sIGVuaGFuY2VkIHByaXZh Y3kpPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPi1kPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDtUaGlzIHNlZW1zIHByb2JsZW1hdGljLiAmbmJzcDtQZXJoYXBzIHdl IG5lZWQgYSB3YXkgdG8gc2lnbmFsIHRoZSBkZXNpcmVkIHVzZS1jYXNlICgmcXVvdDt0cmFpdCZx dW90OyksIG9yIGFzIEp1c3Rpbg0KIHN1Z2dlc3RzLCB1c2luZyBhIGRpZmZlcmVudCB0ZWNobm9s b2d5IGZvciBzb21lIG9mIHRoZXNlIHVzZS1jYXNlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4tZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBNb24sIEZlYiAxMCwgMjAxNCBh dCAzOjE4IFBNLCBLYXJsIFN0YWhsJm5ic3A7Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86a2Fy bC5zdGFobEBpbnRlcnRleC5zZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5rYXJsLnN0YWhsQGludGVydGV4LnNlPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyZuYnNwO3dyb3RlOjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1Yi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNpbW9uLDxicj4NCjxicj4NCkdvb2QgcXVlc3Rpb25z IC0gc2VlIGlubGluZSBiZWxvdyAtLSZndDsgLjxicj4NClNvbWUgbW9yZSB0aG91Z2h0IGlzIHJl cXVpcmVkITxicj4NCjxicj4NCi9LYXJsPGJyPg0KPGJyPg0KLS0tLS1VcnNwcnVuZ2xpZ3QgbWVk ZGVsYW5kZS0tLS0tPGJyPg0KRnLDpW46IHRyYW0gW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQogRsO2ciBTaW1vbiBQ ZXJyZWF1bHQ8YnI+DQpTa2lja2F0OiBkZW4gMTAgZmVicnVhcmkgMjAxNCAxNToxNjxicj4NClRp bGw6IEthcmwgU3RhaGw7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij47Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ dGlyZWRkeUBpY2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PGJyPg0Kw4RtbmU6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2Vy dmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQczwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpLYXJsLDxicj4NCjxicj4NCkl0IGlzIGdy ZWF0IHRvIHNlZSBzdWNoIGVudGh1c2lhc20hIFRoYW5rcyE8YnI+DQo8YnI+DQpJIGhhdmUgYSBj b3VwbGUgdGVjaG5pY2FsIHF1ZXN0aW9ucy4uLjxicj4NCjxicj4NCkxlIDIwMTQtMDItMDggMDg6 MTEsIEthcmwgU3RhaGwgYSDDqWNyaXQgOjxicj4NCiZndDsgLSBOb3RlIHRoYXQgdG8gYWNoaWV2 ZSBzb21lIG9mIHRoZSBhYm92ZSBwb2ludHMsIFRVUk4gbXVzdCBiZSBmYXZvcmVkPGJyPg0KJmd0 OyBvdmVyIFNUVU4gdG8gZW5mb3JjZSB0aGF0IHRoZSBUVVJOLXBhdGggYWN0dWFsbHkgaXMgdXNl ZC4gKFRoZSBBbnljYXN0PGJyPg0KJmd0OyBtZXRob2Qgc3VnZ2VzdGVkIGJlbG93LCDigJxhdXRv bWF0aWNhbGx54oCdIGRvZXMgdGhpcy4pPGJyPg0KPGJyPg0KSSB1bmRlcnN0YW5kIHRoZSBTVFVO IHZzIFRVUk4gcHJpb3JpdHkgaXNzdWUuIEJ1dCBJIGRvbid0IHNlZSBob3cgYW55Y2FzdCBhZmZl Y3RzIGl0IGluIGFueSB3YXkuIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLS0gR29vZCBwb2ludCAtIEkgd2FzIGEgYml0IHF1aWNr IGhlcmUgKG1heWJlIHRvbyBxdWljayk8YnI+DQpXZSBoYXZlIGdpdmVuIHRoaXMgcXVpdGUgYml0 IG9mIHRob3VnaHQsIHNpbmNlIGV2ZW4gaWYgYSBUVVJOIHNlcnZlciBpcyBwcm92aWRlZCBhbmQg ZGlzY292ZXJlZCwgQ1VSUkVOVCB1c2FnZSBvZiBJQ0UgbWF5IHN1Z2dlc3QgYSBjYW5kaWRhdGUg ZnJvbSB0aGUgcmVtb3RlIHBhcnR5IHRoYXQgd2lsbCBtYWtlIGEgY29ubmVjdGlvbiB3aXRob3V0 IHRoZSBuZWVkL3VzYWdlIG9mIHRoZSBUVVJOIHNlcnZlciAodGhhdCB3ZSB3YW50ZWQgdG8gYmUg dXNlZA0KIGZvciB0aGUgZ29vZCBwdXJwb3NlcyBsaXN0ZWQpLjxicj4NCjxicj4NClRoZSBvbmx5 IHdheSB3ZSBmb3VuZCBhcm91bmQgdGhpcywgd2FzIHRvIHN0b3AgU1RVTiB0aHJvdWdoIHRoZSBJ UCBkZWZhdWx0IGdhdGV3YXkgKGxpa2UgYSByZXN0cmljdGl2ZSBFbnRlcnByaXNlIGZpcmV3YWxs IGRvZXMgaW5oaWJpdGluZyBJQ0UgY29ubmVjdGl2aXR5LCB3aGljaCBvdGhlcnMgYXJlIGNvbmNl cm5lZCBhYm91dC4uLikuIFNpbmNlIHRoZSBwcm92aXNpb25pbmcgb2YgYXV0by1kaXNjb3Zlcnkg dXNpbmcgdGhlIGFueWNhc3QgbWVjaGFuaXNtLA0KIHdvdWxkIGJlIGFkZGluZyBhIHJvdXRlIGlu IGEgZGVmYXVsdCBnYXRld2F5LCBhZGRpbmcgYSBmaXJld2FsbCBydWxlIHRvIGVhdCBTVFVOIHBh Y2tldHMgd291bGQgYXNzdXJlIHRoYXQgdGhlIHByb3Zpc2lvbmVkIFRVUk4gc2VydmVyIGFjdHVh bGx5IGJlY29tZXMgdXNlZCAoYW5kIG5vdCBieXBhc3NlZCAmcXVvdDtieSBhY2NpZGVudCZxdW90 OykuIChUaGF0IHdhcyB0aGUgdGhvdWdodCBiZWhpbmQgdGhlIOKAnGF1dG9tYXRpY2FsbHnigJ0g d2l0aGluIHF1b3Rlcy4pPGJyPg0KPGJyPg0KQlVULCBzaW5jZSB5b3UgYnJvdWdodCB1cCB0aGUg cXVlc3Rpb24sIGFzc3VtaW5nIHRoYXQgd2UgaGF2ZSB0aGUgcG93ZXIgdG8gZW5mb3JjZSBXZWJS VEMgdXNhZ2Ugb2YgSUNFLCBJIGJlbGlldmUgYSBNVVNUIHJlcXVpcmVtZW50IHRvIHVzZSBhbiBh dXRvLWRpc2NvdmVyZWQgVFVSTiBzZXJ2ZXIgaW5zdGVhZCBvZiBTVFVOLCB3b3VsZCBzb2x2ZSB0 aGUgc2FtZSBwcm9ibGVtLiBIb3dldmVyLCB0aGlua2luZyBmdXJ0aGVyIChpbiByZWxhdGlvbg0K IHRvIHlvdXIgbmV4dCBxdWVzdGlvbiAtICZxdW90O2FueW9uZSBjb3VsZCBzZXQgdXAgYSBiYWRs eS1tYWludGFpbmVkJnF1b3Q7IC0gZW5mb3JjaW5nIHN1Y2ggSUNFIHVzYWdlIG1heSBub3QgYmUg Z29vZC4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCiZndDsgLSAz XnJkIFRoZSBBbnljYXN0IG1ldGhvZCBiZWxvdyDigJMgSSBzZWUgbm8gcHJvYmxlbTxicj4NCiZn dDs8YnI+DQomZ3Q7IEl0IGFsc28gaGFzIHRoZSBhZHZhbnRhZ2Ugb2YgZW5jb3VyYWdpbmcgKGJ1 dCBub3QgcmVxdWlyaW5nKSB0aGU8YnI+DQomZ3Q7IFNUVU4vVFVSTiB0byBiZSBidWlsdCBpbiB0 aGUgZGVmYXVsdCBnYXRld2F5IG9yIE5BVC9maXJld2FsbC9hY2Nlc3M8YnI+DQomZ3Q7IHJvdXRl ciBpdHNlbGYsIHdpdGggYSBzZWNvbmQgaW50ZXJmYWNlIHRvIGEgcHVibGljIElQIGFkZHJlc3Mg b24gdGhlPGJyPg0KJmd0OyBXQU4gc2lkZS4gKEN1cnJlbnQgdm9sdW1lIGRlcGxveWVkLCBsb3cg Y29zdCBOU1AgdHJpcGxlIHBsYXkgbW9kZW1zPGJyPg0KJmd0OyB1c3VhbGx5IGhhdmUgYSBxdWFs aXR5IGFzc3VyZWQgbGV2ZWwgMiBvciBsZXZlbCAzIFdBTiBwaXBlIGZvciBqdXN0PGJyPg0KJmd0 OyB2b2ljZSAoYW5kIGFub3RoZXIgZm9yIElQVFYpIOKAkyBUaGUgYW55Y2FzdCBkaXNjb3ZlcmVk IFRVUk4tc2VydmVyIGNhbjxicj4NCiZndDsgYmUgdGhlIGFjY2VzcyBnYXRld2F5IHRvIHN1Y2gg cXVhbGl0eSBwaXBlIGZvciBXZWJSVEMgbWVkaWEsIGluIGE8YnI+DQomZ3Q7IHNpbmdsZSBOU1Ag cHJvdmlkZWQgQ1BFLCBzY2FsaW5nIGZyb20gcmVzaWRlbnRpYWwgYW5kIHVwLik8YnI+DQo8YnI+ DQpTdXBwb3NlIHdlIGRlZmluZSB3ZWxsLWtub3duIGFueWNhc3QgVFVSTiBzZXJ2ZXIgYWRkcmVz c2VzLiBIb3cgd291bGQgdGhpcyBub3QgYmUgc3ViamVjdCB0byB0aGUgc2FtZSBzZXJ2aWNlIHF1 YWxpdHkgaXNzdWVzIHRoYXQgcGxhZ3VlZCA2dG80PyBUaGF0IGlzLCBhbnlvbmUgY291bGQgc2V0 IHVwIGEgYmFkbHktbWFpbnRhaW5lZCwgdW5kZXItcHJvdmlzaW9uZWQgVFVSTiBzZXJ2ZXIgYW5k IGFubm91bmNlIGl0IG92ZXIgQkdQIHRvIHRoZSB3b3JsZCwNCiBhcyBpdCB3YXMgZG9uZSBmb3I8 YnI+DQo2dG80IHJlbGF5cy4gT3IganVzdCBiYWQgQkdQIG91dGJvdW5kIGZpbHRlciBjb25maWd1 cmF0aW9uLiBBbmQgaG93IGNhbiB3ZSBwcmV2ZW50IHRyaWFuZ2xlIHJvdXRpbmc/IFRoZXJlIGlz IG5vdGhpbmcgZ3VhcmFudGVlaW5nIHRoYXQgdGhlIGFueWNhc3Qgc2VydmVyIHlvdSBzZWUgaXMg YmVpbmcgcHJvdmlkZWQgdG8geW91IGJ5IHlvdXIgSVNQLCByYXRoZXIgdGhhbiBhIHNlcnZlciBz aXR0aW5nIG9uIHRoZSBvdGhlciBzaWRlIG9mIHRoZSBwbGFuZXQuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLS0gR29vZCBwb2ludCAtIG5lZWRzIHRvIGJlIHJlc29sdmVk LiBGb3IgdGhpcyBJIGRvbid0IGhhdmUgYSByZWFkeSBhbnN3ZXIuLi48YnI+DQpBbiBhdXRvLWRp c2NvdmVyZWQgVFVSTiBzZXJ2ZXIgbXVzdCBiZSB0cnVzdGVkICh3aGF0ZXZlciBtZXRob2QgaXQg aXMgZGlzY292ZXJlZCBieSkuIFdlIGFyZSB0cnVzdGluZyB0aGUgb25lIHByb3ZpZGluZyB1cyB3 aXRoIGFuIElQIGFkZHJlc3MgYW5kIGRlZmF1bHQgZ2F0ZXdheSBhbnl3YXkuIEl0IHdvdWxkIGJl IGVhc3kgaWYgd2UgY291bGQgcmV1c2UgdGhhdCB0cnVzdCwgaW5zdGVhZCBvZiBhbm90aGVyIG1l Y2hhbmlzbXMuPGJyPg0KPGJyPg0KSXMgdGhlcmUgYSBnb29kIHdheSBmb3IgdGhlIGJyb3dzZXIg dG8gY2hlY2sgdGhhdCB0aGUgYW55Y2FzdCBhZGRyZXNzIGlzIG5vdCBoYW5kbGVkIGJleW9uZCB0 aGUgbmV0d29yayBzZXJ2aWNlIHByb3ZpZGVyJ3MgZGVmYXVsdCBnYXRld2F5PyBJZGVhcz88L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCjxicj4N ClRoYW5rcyw8YnI+DQpTaW1vbjxicj4NCi0tPGJyPg0KRFROIG1hZGUgZWFzeSwgbGVhbiwgYW5k IHNtYXJ0IC0tJmd0OyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vcG9zdGVsbGF0aW9uLnZp YWdlbmllLmNhLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5odHRwOi8vcG9zdGVsbGF0aW9uLnZpYWdlbmllLmNhPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KTkFUNjQvRE5TNjQgb3Bl bi1zb3VyY2UgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LS0mZ3Q7Jm5ic3A7PC9zcGFuPjxh IGhyZWY9Imh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwOi8vZWNkeXNpcy52aWFnZW5p ZS5jYTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxi cj4NClNUVU4vVFVSTiBzZXJ2ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IC0tJmd0OyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vbnVtYi52aWFn ZW5pZS5jYS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+aHR0cDovL251bWIudmlhZ2VuaWUuY2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFu PjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFu Zz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1Yi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9zcGFuPjwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVm PSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5n PSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0 cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdHJhbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyYW0g bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF17CF4032MCHP04MSXglobal_-- From karl.stahl@intertex.se Thu Feb 13 02:59:59 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC27A1A01B0 for ; Thu, 13 Feb 2014 02:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 F26uFtYK1UnA for ; Thu, 13 Feb 2014 02:59:54 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 98B571A00D9 for ; Thu, 13 Feb 2014 02:59:53 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131159484804; Thu, 13 Feb 2014 11:59:48 +0100 From: "Karl Stahl" To: "'Justin Uberti'" References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 13 Feb 2014 11:59:48 +0100 Message-ID: <006201cf28aa$b6b23f40$2416bdc0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01CF28B3.1876A740" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8nuZIQThUSmhrYQO63oBjWE0StTAA6rZKQ Content-Language: sv Cc: tireddy@icisco.com, 'Marc Blanchet' , tram@ietf.org, 'Dan Wing' , 'Simon Perreault' Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:00:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0063_01CF28B3.1876A740 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Justin said > Skype, Hangouts, Facetime are doing billions of minutes = per week and the Internet has not melted yet. If we need to do flow = identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of = WebRTC.are doing billions of minutes per week and the Internet has not = melted yet. If we need to do flow identification to allow traffic to be = prioritized, fine (see above regarding my preferred approach), but = forcing all WebRTC traffic through a MITM (TURN server) is a much bigger = jump that I don't yet see the justification for. =20 --- You (and the ones you communicate with) must be blessed with very = good Internet pipes! =20 As an illustration; here is my experience from ITEXPO a few weeks ago = where I/Ingate made several live tests and demos of WebRTC and over the = AT&T and Verizon LTE/4G networks. Walking around the halls, the Verizon = LTE showed 2-3 signal strength bars and the AT&T LTE with a closer cell = tower showed 4-5 bars. The Verizon network was = =E2=80=9Cunusable=E2=80=9D for WebRTC video, while the AT&T long times = showed perfect HD WebRTC video, mixed with severe quality degradation = (incl Chrome=E2=80=99s shrinking VP8 video window size remedy = mechanism), and even total loss media. =20 I have similar experiences with Hangouts, even over fixed pipes.=20 =20 How do think bandwidth reservation type of networks (Cable and Mobile) = will be able to receive and deliver unannounced/unrecognized high = bandwidth traffic in a lossless way to the client if the pipe is data = crowded? (a few more things than discussed now are actually required to = ease that)=20 =20 - We need flow enforcement (not only identification), to cope with the = problems and be able to enjoy all the good benefits and capabilities of = WebRTC! And WebRTC in itself has/allows =E2=80=9CTelepresence = quality/resolution=E2=80=9D =E2=80=93 Let us get that on our desktops = and in our pockets! We must realize that we are talking about 30 times = higher bandwidth needs than for old POTS telephony (that is run over = quality managed networks). Now we are about to do 30 times more = demanding things over best effort Internet, and through severe = NAT/Firewall congestion points=E2=80=A6. =20 - See the standardization of WebRTC (compared to proprietary Skype, = Hangouts, Facetime) as a very good opportunity of finally dealing with = this and getting/enabling quality for RTC over the Internet. This is a = huge opportunity and a necessity!=20 - If we do it right Skype, Hangouts, Facetime Can/Will also benefit from = it by using WebRTC J. I actually think they will do just that in a = future when the standards are settled and WebRTC are in all browsers.=20 =20 Justin said > In short: TURN is a technology that is supposed to fade = away with the move to IPv6. I don't think we want to make it a critical = element of WebRTC. =20 --- ICE and at least STUN will be necessary also in an all IPv6 world. = Firewalls stopping unannounced/not recognized traffic (=3Dmedia) will = still be there hindering media to clients. =20 /Karl =20 Fr=C3=A5n: Justin Uberti [mailto:juberti@google.com]=20 Skickat: den 12 februari 2014 07:13 Till: Karl Stahl Kopia: Dan Wing; Marc Blanchet; tireddy@icisco.com; tram@ietf.org; Simon = Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and = necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by = the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle = routing",need a new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D etc! It is not a mistake, but the very need for this = milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like = MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the = wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication = (SIP at that time). However, its largest flaw/problem is that quality = things were not (could not be?) considered. The method=E2=80=99s very = idea (like all similar methods for getting RTC through ordinary = NAT/Firewalls) is to fool the media through a NAT/Firewall that is = unaware of what is happening. Thus, this is root of quality issues (and = bandwidth allocation optimization) that needs to be dealt with: = Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get = media through (and of course with as good quality as required and = possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D It is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =E2=80=9Cbecause it is all = about bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with = time=E2=80=9D etc., I strongly object! That is wrong and will be very = detrimental for WebRTC usage. We already see it and I can give numerous = examples of how much less quality demanding VoIP is/is not handled = quality wise and that it matters. And, what would be bad considering = quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. (Maybe the Web browser can = detect and encourage this=E2=80=A6)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the = browser that there are good media paths to be used, and that the web = browser automatically can chose those, then let us all understand those, = so we can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the = Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) = is a much bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of = WebRTC. =20 /Karl =20 =20 Fr=C3=A5n: Dan Wing [mailto:dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; = Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet = wrote: =20 Le 2014-02-11 =C3=A0 00:39, Dan Wing a =C3=A9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' = path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN = server will do, and the endpoint should prefer TURN candidates over all = others because there might be some functionality / usefulness of TURN = that the user might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =E2=80=9Cautomatically=E2=80=9D within quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) > - 3^rd The Anycast method below =E2=80=93 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready = answer... An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca = =20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca = =20 STUN/TURN server --> http://numb.viagenie.ca = =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 ------=_NextPart_000_0063_01CF28B3.1876A740 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Justin said > Skype, Hangouts, Facetime are doing = billions of minutes per week and the Internet has not melted yet. If we = need to do flow identification to allow traffic to be prioritized, fine = (see above regarding my preferred approach), but forcing all WebRTC = traffic through a MITM (TURN server) is a much bigger jump that I don't = yet see the justification for.

 

In short: TURN is a technology that = is supposed to fade away with the move to IPv6. I don't think we want to = make it a critical element of WebRTC.are doing billions of minutes per = week and the Internet has not melted yet. If we need to do flow = identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

--= - You (and the ones you communicate with) must be blessed with very good = Internet pipes!

 

As= an illustration; here is my experience from ITEXPO a few weeks ago = wh= ere I/Ingate made several live tests and demos of WebRTC and over the = AT&T and Verizon LTE/4G networks. Walking around the halls, the = Verizon LTE showed 2-3 signal strength bars and the AT&T LTE with a = closer cell tower showed 4-5 bars. The Verizon network was = =E2=80=9Cunusable=E2=80=9D for WebRTC video, while the AT&T long = times showed perfect HD WebRTC video, mixed with severe quality = degradation (incl Chrome=E2=80=99s shrinking VP8 video window size = remedy mechanism), and even total loss media.

 

I have similar experiences with Hangouts, even over = fixed pipes.

 

How do think = bandwidth reservation type of networks (Cable and Mobile) will be able = to receive and deliver unannounced/unrecognized high bandwidth traffic = in a lossless way =C2=A0to the client if the pipe is data crowded? (a = few more things than discussed now are actually required to ease that) =

 

- We need flow = enforcement (not only identification), to cope with the problems and be = able to enjoy all the good benefits and capabilities of WebRTC! And = WebRTC in itself has/allows =E2=80=9CTelepresence = quality/resolution=E2=80=9D =E2=80=93 Let us get that on our desktops = and in our pockets! We must realize that we are talking about 30 times = higher bandwidth needs than for old POTS telephony (that is run over = quality managed networks). Now we are about to do 30 times more = demanding things over best effort Internet, and through severe = NAT/Firewall congestion points=E2=80=A6.

 

- See the = standardization of WebRTC (compared to proprietary Skype, Hangouts, Facetime) as a = very good opportunity of finally dealing with this and getting/enabling = quality for RTC over the Internet. This is a huge opportunity and a = necessity!

- If we do it right Skype, Hangouts, = Facetime Can/Will also benefit from it by using WebRTC J. I actually think they will do just = that in a future when the standards are settled and WebRTC are in all = browsers.

 

Justin said > In short: TURN is a technology that is = supposed to fade away with the move to IPv6. I don't think we want to = make it a critical element of WebRTC.

 

--= - ICE and at least STUN will be necessary also in an all IPv6 world. = Firewalls stopping unannounced/not recognized traffic (=3Dmedia) will = still be there hindering media to clients.

 

/K= arl

 

Fr=C3=A5n: Justin = Uberti [mailto:juberti@google.com]
Skickat: den 12 februari = 2014 07:13
Till: Karl Stahl
Kopia: Dan Wing; Marc = Blanchet; tireddy@icisco.com; tram@ietf.org; Simon = Perreault
=C3=84mne: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

Inline.

 

On Tue, = Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped = with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic. =

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the = right technology here, compared to a more transparent flow = identification tool like MALICE. We don't force all HTTP requests to = locate a HTTP proxy via anycast, I don't see why we need to do the same = for WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method=E2=80=99s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion = point.

 

I = think that "fooling" is an incorrect description. The NAT is = supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot = help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this = milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues =E2=80=9Cbecause it is all about = bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D = etc., I strongly object! That is wrong and will be very detrimental for = WebRTC usage. We already see it and I can give numerous examples of how = much less quality demanding VoIP is/is not handled quality wise and that = it matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with = them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this=E2=80=A6) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this = milestone.

 

Skype, Hangouts, Facetime are doing billions of = minutes per week and the Internet has not melted yet. If we need to do = flow identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to = fade away with the move to IPv6. I don't think we want to make it a = critical element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=C3=A5n: Dan Wing = [mailto:dwing@cisco.com]
Skickat: den 11 = februari 2014 18:25
Till: Marc = Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon = Perreault


=C3=84mne: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 <= /o:p>

 <= /o:p>

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> = wrote:

 <= /p>

Le = 2014-02-11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit = :

 <= /p>


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> = wrote:

 <= /p>

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks = UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all). =

 <= /o:p>

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 <= /o:p>

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced = privacy)?

 <= /o:p>

-d

 <= /o:p>

 <= /o:p>

 <= /p>

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these = use-cases.

 

-d<= o:p>

 

 

 <= /p>

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:<= /o:p>

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon = Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C3=84mne: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =C3=A9crit :
> - Note that to achieve some of the above points, = TURN must be favored
> over STUN to enforce that the TURN-path = actually is used. (The Anycast
> method suggested below, = =E2=80=9Cautomatically=E2=80=9D does this.)

I understand the STUN = vs TURN priority issue. But I don't see how anycast affects it in any = way. Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the =E2=80=9Cautomatically=E2=80=9D within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below =E2=80=93 I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) =E2=80=93 The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://postellation.viagenie.ca
NAT64/DNS64 = open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server =               --> http://numb.viagenie.ca
________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

_= ______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_0063_01CF28B3.1876A740-- From karl.stahl@intertex.se Thu Feb 13 03:36:22 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65901A01F3 for ; Thu, 13 Feb 2014 03:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 cxo2d7RpfEox for ; Thu, 13 Feb 2014 03:36:18 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id D5A2F1A01F0 for ; Thu, 13 Feb 2014 03:36:16 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131236111861; Thu, 13 Feb 2014 12:36:11 +0100 From: "Karl Stahl" To: "'Justin Uberti'" References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 13 Feb 2014 12:36:11 +0100 Message-ID: <006c01cf28af$cbd18ed0$6374ac70$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01CF28B8.2D95F6D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8nuZIQThUSmhrYQO63oBjWE0StTAA5YlIQ Content-Language: sv Cc: tireddy@icisco.com, 'Marc Blanchet' , tram@ietf.org, 'Dan Wing' , 'Simon Perreault' Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:36:23 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006D_01CF28B8.2D95F6D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >> This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D etc! It is not a mistake, but the very need for this = milestone! >Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like = MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for WebRTC =20 ---- You may think what I am about to say sounds even worse, but it is = good! =20 This discussion actually does not (only) lead to = =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D,=20 It leads us to ENFORE media (WebRTC flows) (into paths announced by the = enterprise or NSP/ISP) (my =E2=80=9Cetc=E2=80=9D =E2=80=A6in = flows=E2=80=9D etc!=E2=80=9D was this ) =20 I read up on MALICE or rather DISCUSS as it is now called:=20 - Good ideas and methods, but to have any effect, the media arrive at = the point in the network where such good measures can applied. =20 So we need a way to ENFORCE that the media takes certain paths in the = network. For RTC protocols using ICE (like WebRTC and SIP) we can/must = use TURN for this (the only way I see, and it is a good way). =20 /Karl =20 =20 Fr=C3=A5n: Justin Uberti [mailto:juberti@google.com]=20 Skickat: den 12 februari 2014 07:13 Till: Karl Stahl Kopia: Dan Wing; Marc Blanchet; tireddy@icisco.com; tram@ietf.org; Simon = Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and = necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by = the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle = routing",need a new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D etc! It is not a mistake, but the very need for this = milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like = MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the = wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication = (SIP at that time). However, its largest flaw/problem is that quality = things were not (could not be?) considered. The method=E2=80=99s very = idea (like all similar methods for getting RTC through ordinary = NAT/Firewalls) is to fool the media through a NAT/Firewall that is = unaware of what is happening. Thus, this is root of quality issues (and = bandwidth allocation optimization) that needs to be dealt with: = Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get = media through (and of course with as good quality as required and = possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D It is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =E2=80=9Cbecause it is all = about bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with = time=E2=80=9D etc., I strongly object! That is wrong and will be very = detrimental for WebRTC usage. We already see it and I can give numerous = examples of how much less quality demanding VoIP is/is not handled = quality wise and that it matters. And, what would be bad considering = quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. (Maybe the Web browser can = detect and encourage this=E2=80=A6)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the = browser that there are good media paths to be used, and that the web = browser automatically can chose those, then let us all understand those, = so we can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the = Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) = is a much bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of = WebRTC. =20 /Karl =20 =20 Fr=C3=A5n: Dan Wing [mailto:dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; = Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet = wrote: =20 Le 2014-02-11 =C3=A0 00:39, Dan Wing a =C3=A9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' = path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN = server will do, and the endpoint should prefer TURN candidates over all = others because there might be some functionality / usefulness of TURN = that the user might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =E2=80=9Cautomatically=E2=80=9D within quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) > - 3^rd The Anycast method below =E2=80=93 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready = answer... An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca = =20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca = =20 STUN/TURN server --> http://numb.viagenie.ca = =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 ------=_NextPart_000_006D_01CF28B8.2D95F6D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

&g= t;> This leads us into  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

>Again, it has not been = demonstrated why TURN is the right technology here, compared to a more = transparent flow identification tool like MALICE. We don't force all = HTTP requests to locate a HTTP proxy via anycast, I don't see why we = need to do the same for WebRTC

 

--= -- You may think what I am about to say sounds even worse, but it is = good!

 

Th= is discussion actually does not (only) lead to  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D,

It= leads us to ENFORE media (WebRTC flows) (into paths announced by the = enterprise or NSP/ISP) =C2=A0(my =E2=80=9Cetc=E2=80=9D =E2=80=A6in = flows=E2=80= =9D etc!=E2=80=9D was this = )

 

I = read up on MALICE or rather DISCUSS as it is now called: =

- = Good ideas and methods, but to have any effect, the media arrive at the = point in the network where such good measures can = applied.

 

So= we need a way to ENFORCE that the media takes certain paths in the = network. For RTC protocols using ICE (like WebRTC and SIP) we can/must = use TURN for this (the only way I see, and it is a good = way).

 

/K= arl

 

 

Fr=C3=A5n: Justin = Uberti [mailto:juberti@google.com]
Skickat: den 12 februari = 2014 07:13
Till: Karl Stahl
Kopia: Dan Wing; Marc = Blanchet; tireddy@icisco.com; tram@ietf.org; Simon = Perreault
=C3=84mne: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

Inline.

 

On Tue, = Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped = with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic. =

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the = right technology here, compared to a more transparent flow = identification tool like MALICE. We don't force all HTTP requests to = locate a HTTP proxy via anycast, I don't see why we need to do the same = for WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method=E2=80=99s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion = point.

 

I = think that "fooling" is an incorrect description. The NAT is = supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot = help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this = milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues =E2=80=9Cbecause it is all about = bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D = etc., I strongly object! That is wrong and will be very detrimental for = WebRTC usage. We already see it and I can give numerous examples of how = much less quality demanding VoIP is/is not handled quality wise and that = it matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with = them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this=E2=80=A6) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this = milestone.

 

Skype, Hangouts, Facetime are doing billions of = minutes per week and the Internet has not melted yet. If we need to do = flow identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to = fade away with the move to IPv6. I don't think we want to make it a = critical element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=C3=A5n: Dan Wing = [mailto:dwing@cisco.com]
Skickat: den 11 = februari 2014 18:25
Till: Marc = Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon = Perreault


=C3=84mne: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 <= /o:p>

 <= /o:p>

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> = wrote:

 <= /p>

Le = 2014-02-11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit = :

 <= /p>


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> = wrote:

 <= /p>

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks = UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all). =

 <= /o:p>

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 <= /o:p>

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced = privacy)?

 <= /o:p>

-d

 <= /o:p>

 <= /o:p>

 <= /p>

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these = use-cases.

 

-d<= o:p>

 

 

 <= /p>

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:<= /o:p>

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon = Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C3=84mne: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =C3=A9crit :
> - Note that to achieve some of the above points, = TURN must be favored
> over STUN to enforce that the TURN-path = actually is used. (The Anycast
> method suggested below, = =E2=80=9Cautomatically=E2=80=9D does this.)

I understand the STUN = vs TURN priority issue. But I don't see how anycast affects it in any = way. Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the =E2=80=9Cautomatically=E2=80=9D within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below =E2=80=93 I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) =E2=80=93 The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://postellation.viagenie.ca
NAT64/DNS64 = open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server =               --> http://numb.viagenie.ca
________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

_= ______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_006D_01CF28B8.2D95F6D0-- From karl.stahl@intertex.se Thu Feb 13 03:36:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CDF1A01F3 for ; Thu, 13 Feb 2014 03:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1] autolearn=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 8fKeboE-avRP for ; Thu, 13 Feb 2014 03:36:32 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id D4D0B1A01F0 for ; Thu, 13 Feb 2014 03:36:31 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131236261937; Thu, 13 Feb 2014 12:36:26 +0100 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Simon Perreault'" , , References: <082c01cf17d4$393d7bb0$abb87310$@stahl@intertex.se> <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se> <52F8DF21.2080303@viagenie.ca> <049801cf26b6$5a87db30$0f979190$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A242ABA2D@xmb-rcd-x10.cisco.com> <058f01cf275d$da1dc6a0$8e5953e0$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A242AC8C2@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242AC8C2@xmb-rcd-x10.cisco.com> Date: Thu, 13 Feb 2014 12:36:27 +0100 Message-ID: <007101cf28af$d4e3cb00$7eab6100$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPJrZnSgUY4V56JE+wy6rTjZeHIZqvVbIwgAEJXKCAANCLcIAB2bUQ Content-Language: sv Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:36:35 -0000 I checked Malice=3Ddiscussed and just commented in previous response But we need to ENFORCE paths adviced/offered by the enterprise and/or = NSP/ISP to be used (to cope with the problems). Do you see an alternate way/method of doing that, not using TURN? =20 /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Skickat: den 12 februari 2014 08:01 Till: Karl Stahl; 'Simon Perreault'; tram@ietf.org; tireddy@icisco.com =C3=84mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Hi Karl, Yes, there is a problem but P2P WebRTC streams (both media and data = channels) can be identified and QoS can be provided by the access = network without forcing TURN to be used. You may want to look into PCP = FLOWDATA (http://tools.ietf.org/html/draft-wing-pcp-flowdata-00), MALICE = (http://tools.ietf.org/html/draft-martinsen-mmusic-malice-00).=20 -Tiru. > -----Original Message----- > From: Karl Stahl [mailto:karl.stahl@intertex.se] > Sent: Wednesday, February 12, 2014 12:47 AM > To: Tirumaleswar Reddy (tireddy); 'Simon Perreault'; tram@ietf.org;=20 > tireddy@icisco.com > Subject: SV: [tram] Milestone 3: TURN server auto-discovery mechanism=20 > for enterprise and ISPs >=20 > Tireddy wrote below > There are various ways to prioritize WebRTC=20 > media streams and I don't see a need to block P2P connectivity. >=20 > --- We need not only to think about prioritizing WebRTC, it is about=20 > "traffic shaping also". > - If we consider the case of WebRTC traffic over Internet/mobile OTT=20 > (not talking about feeding WebRTC into some application specific=20 > network like IMS where they may be other quality measures), we get=20 > lost quality wise already when (if) we allow prioritized WebRTC=20 > traffic to go into a congestion point (like a NAT/firewall or default=20 > gateway, where there may be heavy data traffic already filling the = pipe. > - Quality loss here (lost WebRTC media packets) cannot be recovered=20 > later > - That is the "need to block P2P connectivity" (which may sound ugly=20 > but is really about assuring that we CAN get P2P connectivity with=20 > best quality, with help of service providers and LAN administrators=20 > that want WebRTC traffic to be good and accessible...) >=20 > --- Or do see another/better way around this that I cannot see? >=20 > -----Ursprungligt meddelande----- > Fr=C3=A5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Skickat: den 11 februari 2014 03:40 > Till: Karl Stahl; 'Simon Perreault'; tram@ietf.org; tireddy@icisco.com > =C3=84mne: RE: [tram] Milestone 3: TURN server auto-discovery = mechanism for=20 > enterprise and ISPs >=20 > > The only way we found around this, was to stop STUN through the IP=20 > > default gateway (like a restrictive Enterprise firewall does=20 > > inhibiting ICE connectivity, which others are concerned about...). > > Since the provisioning of auto- discovery using the anycast=20 > > mechanism, would be adding a route in a default gateway, adding a=20 > > firewall rule to eat STUN packets would assure that the provisioned=20 > > TURN server actually becomes used (and not bypassed "by accident").=20 > > (That was the thought behind the =E2=80=9Cautomatically=E2=80=9D = within quotes.) >=20 > There are various ways to prioritize WebRTC media streams and I don't=20 > see a need to block P2P connectivity. > --- We need not only to think about prioritizing WebRTC, it is about=20 > "traffic shaping also". > - If we consider the case of WebRTC traffic over Internet/mobile OTT=20 > (not talking about feeding WebRTC into some application specific=20 > network like IMS where they may be other quality measures), we get=20 > lost quality wise already when (if) we allow prioritized WebRTC=20 > traffic to go into a congestion point (like a NAT/firewall or default=20 > gateway, where there may be heavy data traffic already filling the = pipe. > - Quality loss here (lost WebRTC media packets) cannot be recovered=20 > later > - That is the "need to block P2P connectivity" (which may sound ugly=20 > but is really about assuring that we CAN get P2P connectivity with=20 > best quality, with help of service providers and LAN administrators=20 > that want WebRTC traffic to be good and accessible...) >=20 > --- Or do see another/better way around this that I cannot see? >=20 > Using TURN server itself endpoint can learn server-reflexive=20 > candidates. If there is a restrictive firewall that blocks P2P=20 > connectivity then relayed candidate would eventually be nominated=20 > because ICE connectivity check fails with other candidate types. >=20 > I don't see any need to advertise only relayed candidates in the=20 > offer/answer other than for privacy reasons. >=20 > -Tiru. >=20 > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl > > Sent: Tuesday, February 11, 2014 4:48 AM > > To: 'Simon Perreault'; tram@ietf.org; tireddy@icisco.com > > Subject: Re: [tram] Milestone 3: TURN server auto-discovery=20 > > mechanism for enterprise and ISPs > > > > Simon, > > > > Good questions - see inline below --> . > > Some more thought is required! > > > > /Karl > > > > -----Ursprungligt meddelande----- > > Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon = Perreault > > Skickat: den 10 februari 2014 15:16 > > Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com > > =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery = mechanism=20 > > for enterprise and ISPs > > > > Karl, > > > > It is great to see such enthusiasm! Thanks! > > > > I have a couple technical questions... > > > > Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > > > - Note that to achieve some of the above points, TURN must be=20 > > > favored over STUN to enforce that the TURN-path actually is used. > > > (The Anycast method suggested below, = =E2=80=9Cautomatically=E2=80=9D does this.) > > > > I understand the STUN vs TURN priority issue. But I don't see how=20 > > anycast affects it in any way. Can you please explain? > > > > --- Good point - I was a bit quick here (maybe too quick) We have=20 > > given this quite bit of thought, since even if a TURN server is=20 > > provided and discovered, CURRENT usage of ICE may suggest a=20 > > candidate from the remote party that will make a connection without=20 > > the need/usage of the TURN server (that we wanted to be used for the = > > good > purposes listed). > > > > The only way we found around this, was to stop STUN through the IP=20 > > default gateway (like a restrictive Enterprise firewall does=20 > > inhibiting ICE connectivity, which others are concerned about...). > > Since the provisioning of auto- discovery using the anycast=20 > > mechanism, would be adding a route in a default gateway, adding a=20 > > firewall rule to eat STUN packets would assure that the provisioned=20 > > TURN server actually becomes used (and not bypassed "by accident").=20 > > (That was the thought behind the =E2=80=9Cautomatically=E2=80=9D = within quotes.) > > > > BUT, since you brought up the question, assuming that we have the=20 > > power to enforce WebRTC usage of ICE, I believe a MUST requirement=20 > > to use an auto- discovered TURN server instead of STUN, would solve=20 > > the > same problem. > > However, thinking further (in relation to your next question -=20 > > "anyone could set up a badly-maintained" - enforcing such ICE usage=20 > > may not be > > good.) > > > > > > > - 3^rd The Anycast method below =E2=80=93 I see no problem > > > > > > It also has the advantage of encouraging (but not requiring) the=20 > > > STUN/TURN to be built in the default gateway or=20 > > > NAT/firewall/access router itself, with a second interface to a=20 > > > public IP address on the WAN side. (Current volume deployed, low=20 > > > cost NSP triple play modems usually have a quality assured level 2 = > > > or level 3 WAN pipe for just voice (and another for IPTV) = =E2=80=93 The=20 > > > anycast discovered TURN-server can be the access gateway to such=20 > > > quality pipe for WebRTC media, in a single NSP provided CPE,=20 > > > scaling from residential and up.) > > > > Suppose we define well-known anycast TURN server addresses. How=20 > > would this not be subject to the same service quality issues that=20 > > plagued 6to4? That is, anyone could set up a badly-maintained,=20 > > under-provisioned TURN server and announce it over BGP to the world, = > > as it was done for > > 6to4 relays. Or just bad BGP outbound filter configuration. And how=20 > > can we prevent triangle routing? There is nothing guaranteeing that=20 > > the anycast server you see is being provided to you by your ISP,=20 > > rather than a server sitting on the other side of the planet. > > > > --- Good point - needs to be resolved. For this I don't have a ready > answer... > > An auto-discovered TURN server must be trusted (whatever method it=20 > > is discovered by). We are trusting the one providing us with an IP=20 > > address and default gateway anyway. It would be easy if we could=20 > > reuse that trust, instead of another mechanisms. > > > > Is there a good way for the browser to check that the anycast=20 > > address is not handled beyond the network service provider's default = gateway? > Ideas? > > > > > > > > Thanks, > > Simon > > -- > > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram From karl.stahl@intertex.se Thu Feb 13 03:37:30 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF0C1A01F8 for ; Thu, 13 Feb 2014 03:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 kNVJsRxDaFLq for ; Thu, 13 Feb 2014 03:37:27 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id DD7431A01F6 for ; Thu, 13 Feb 2014 03:37:25 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131237222119; Thu, 13 Feb 2014 12:37:22 +0100 From: "Karl Stahl" To: "'Muthu Arul Mozhi Perumal \(mperumal\)'" , "'Justin Uberti'" References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 13 Feb 2014 12:37:23 +0100 Message-ID: <007201cf28af$f66e3800$e34aa800$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01CF28B8.5832A000" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPJ7mlnafoQENNEUmFuRpz1h1atZqxMH2AgAHYmbA= Content-Language: sv Cc: tireddy@icisco.com, 'Marc Blanchet' , tram@ietf.org, "'Dan Wing \(dwing\)'" , 'Simon Perreault' Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:37:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0073_01CF28B8.5832A000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =E2=80=9CForcing all traffic through=E2=80=9D a path announced by the = enterprise and/or NSP/ISP is NECESSARY to copy with the problems to be = able to =E2=80=9Cprovide the best user experience=E2=80=9D /Karl =20 Fr=C3=A5n: Muthu Arul Mozhi Perumal (mperumal) = [mailto:mperumal@cisco.com]=20 Skickat: den 12 februari 2014 08:32 Till: Justin Uberti; Karl Stahl Kopia: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing = (dwing); Simon Perreault =C3=84mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 +1 =20 Forcing all traffic through a TURN server and expecting it would provide = the best user experience doesn't look the right approach. Instead, if a = path through a TURN server exists and does provide lower RTT, jitter = etc, being able to detect and use (or switch to) that path might be = desirable.. =20 Muthu =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); = Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and = necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by = the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle = routing",need a new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D etc! It is not a mistake, but the very need for this = milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like = MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the = wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication = (SIP at that time). However, its largest flaw/problem is that quality = things were not (could not be?) considered. The method=E2=80=99s very = idea (like all similar methods for getting RTC through ordinary = NAT/Firewalls) is to fool the media through a NAT/Firewall that is = unaware of what is happening. Thus, this is root of quality issues (and = bandwidth allocation optimization) that needs to be dealt with: = Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get = media through (and of course with as good quality as required and = possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D It is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =E2=80=9Cbecause it is all = about bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with = time=E2=80=9D etc., I strongly object! That is wrong and will be very = detrimental for WebRTC usage. We already see it and I can give numerous = examples of how much less quality demanding VoIP is/is not handled = quality wise and that it matters. And, what would be bad considering = quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. (Maybe the Web browser can = detect and encourage this=E2=80=A6)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the = browser that there are good media paths to be used, and that the web = browser automatically can chose those, then let us all understand those, = so we can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the = Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) = is a much bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of = WebRTC. =20 /Karl =20 =20 Fr=C3=A5n: Dan Wing [mailto:dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; = Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet = wrote: =20 Le 2014-02-11 =C3=A0 00:39, Dan Wing a =C3=A9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' = path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN = server will do, and the endpoint should prefer TURN candidates over all = others because there might be some functionality / usefulness of TURN = that the user might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =E2=80=9Cautomatically=E2=80=9D within quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) > - 3^rd The Anycast method below =E2=80=93 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready = answer... An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca = =20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca = =20 STUN/TURN server --> http://numb.viagenie.ca = =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 ------=_NextPart_000_0073_01CF28B8.5832A000 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

=E2=80=9CForcing all traffic through=E2=80=9D a path announced by = the enterprise and/or NSP/ISP is NECESSARY to copy with the problems to = be able to =E2=80=9Cprovide the best user = experience=E2=80=9D

/Karl

 

Fr=C3=A5n: Muthu Arul = Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]
Skickat: = den 12 februari 2014 08:32
Till: Justin Uberti; Karl = Stahl
Kopia: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; = Dan Wing (dwing); Simon Perreault
=C3=84mne: RE: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs

 

+1

 

Forcing all traffic through a TURN server and expecting it would = provide the best user experience doesn't look the right approach. = Instead, if a path through a TURN server exists and does provide lower = RTT, jitter etc, being able to detect and use (or switch to) that path = might be desirable..

 

Muthu

 

From:= tram [mailto:tram-bounces@ietf.org] = On Behalf Of Justin Uberti
Sent: Wednesday, February = 12, 2014 11:43 AM
To: Karl Stahl
Cc: tireddy@icisco.com; Marc = Blanchet; tram@ietf.org; Dan Wing = (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, = Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped = with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic. =

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated = why TURN is the right technology here, compared to a more transparent = flow identification tool like MALICE. We don't force all HTTP requests = to locate a HTTP proxy via anycast, I don't see why we need to do the = same for WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method=E2=80=99s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion = point.

 

I think that "fooling" is = an incorrect description. The NAT is supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot = help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this = milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues =E2=80=9Cbecause it is all about = bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D = etc., I strongly object! That is wrong and will be very detrimental for = WebRTC usage. We already see it and I can give numerous examples of how = much less quality demanding VoIP is/is not handled quality wise and that = it matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with = them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this=E2=80=A6) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this = milestone.

 

Skype, Hangouts, Facetime are doing = billions of minutes per week and the Internet has not melted yet. If we = need to do flow identification to allow traffic to be prioritized, fine = (see above regarding my preferred approach), but forcing all WebRTC = traffic through a MITM (TURN server) is a much bigger jump that I don't = yet see the justification for.

 

In short: TURN is a technology that = is supposed to fade away with the move to IPv6. I don't think we want to = make it a critical element of = WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=C3=A5n: Dan Wing = [mailto:dwing@cisco.com]
Skickat: den 11 = februari 2014 18:25
Till: Marc = Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon = Perreault


=C3=84mne: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 <= /o:p>

 <= /o:p>

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> = wrote:

 <= /p>

Le = 2014-02-11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit = :

 <= /p>


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> = wrote:

 <= /p>

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks = UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all). =

 <= /o:p>

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 <= /o:p>

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced = privacy)?

 <= /o:p>

-d

 <= /o:p>

 <= /o:p>

 <= /p>

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these = use-cases.

 

-d<= o:p>

 

 

 <= /p>

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:<= /o:p>

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon = Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C3=84mne: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =C3=A9crit :
> - Note that to achieve some of the above points, = TURN must be favored
> over STUN to enforce that the TURN-path = actually is used. (The Anycast
> method suggested below, = =E2=80=9Cautomatically=E2=80=9D does this.)

I understand the STUN = vs TURN priority issue. But I don't see how anycast affects it in any = way. Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the =E2=80=9Cautomatically=E2=80=9D within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below =E2=80=93 I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) =E2=80=93 The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://postellation.viagenie.ca
NAT64/DNS64 = open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server =               --> http://numb.viagenie.ca
________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

_= ______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 <= /o:p>

 <= /o:p>

 

<= /html> ------=_NextPart_000_0073_01CF28B8.5832A000-- From karl.stahl@intertex.se Thu Feb 13 03:38:04 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0D71A01F2 for ; Thu, 13 Feb 2014 03:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 mk880-b4JdxY for ; Thu, 13 Feb 2014 03:37:56 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id C1D7E1A01EB for ; Thu, 13 Feb 2014 03:37:54 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131237512167; Thu, 13 Feb 2014 12:37:51 +0100 From: "Karl Stahl" To: "'Oleg Moskalenko'" , "'Muthu Arul Mozhi Perumal \(mperumal\)'" References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 13 Feb 2014 12:37:52 +0100 Message-ID: <007701cf28b0$07ceeb30$176cc190$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01CF28B8.69935330" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8nxUBtfwoEzgLzSgmkkUQIBWUhjgA5+W9A Content-Language: sv Cc: tireddy@icisco.com, 'Simon Perreault' , tram@ietf.org, 'Justin Uberti' , 'Marc Blanchet' , "'Dan Wing \(dwing\)'" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:38:04 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0078_01CF28B8.69935330 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable An auto-discovered TURN server should advice the best (and maybe only) = path. The Enterprise and/or NSP/ISP making this announcement/offer of the TURN server are the ones that knows (can know). /Karl =20 Fr=E5n: Oleg Moskalenko [mailto:mom040267@gmail.com]=20 Skickat: den 12 februari 2014 08:37 Till: Muthu Arul Mozhi Perumal (mperumal) Kopia: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 The TURN server has to be used when it is either the only option, or if = it provides a better path (I guess the second case is rather rare). =20 On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: +1 =20 Forcing all traffic through a TURN server and expecting it would provide = the best user experience doesn't look the right approach. Instead, if a path through a TURN server exists and does provide lower RTT, jitter etc, = being able to detect and use (or switch to) that path might be desirable.. =20 Muthu =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle routing",need a = new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =93TURN=85to identify WebRTC flows=94 etc! It is not = a mistake, but the very need for this milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like MALICE. We don't force all HTTP requests to locate a HTTP proxy via anycast, I = don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw/problem is that quality things were not (could not be?) considered. The method=92s very idea (like all similar = methods for getting RTC through ordinary NAT/Firewalls) is to fool the media = through a NAT/Firewall that is unaware of what is happening. Thus, this is root = of quality issues (and bandwidth allocation optimization) that needs to be dealt with: Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get media through (and of course with as good quality as required and possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =93TURN=85to identify WebRTC flows=94 It is also the ONLY way I can see to achieve what we want to achieve and should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not feeding WebRTC into application specific networks like IMS where other methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =93because it is all about = bandwidth=94, =93it will resolve itself with time=94 etc., I strongly object! That is = wrong and will be very detrimental for WebRTC usage. We already see it and I = can give numerous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad = considering quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and would = fight the same battle. But hopefully, those days are (soon) over =96 At least forward thinking carrier=92s realize that already. Web RTC will happen. = Which customers want to pay for an access with blocked WebRTC? The carrier=92s offering/assuring good WebRTC will rather get the customers and income = J. (Maybe the Web browser can detect and encourage this=85)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the browser that there are good media paths to be used, and that the web browser automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) is a much = bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of WebRTC. =20 /Karl =20 =20 Fr=E5n: Dan Wing [mailto:dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; = Simon Perreault =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet wrote: =20 Le 2014-02-11 =E0 00:39, Dan Wing a =E9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. This makes = me concerned that we may be using the wrong technology to solve the = problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the call = to succeed, whatever the properties of its network point of attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the user = might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =E9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =93automatically=94 does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage of = the TURN server (that we wanted to be used for the good purposes listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be adding a route = in a default gateway, adding a firewall rule to eat STUN packets would assure that the provisioned TURN server actually becomes used (and not bypassed = "by accident"). (That was the thought behind the =93automatically=94 within = quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - "anyone = could set up a badly-maintained" - enforcing such ICE usage may not be good.) > - 3^rd The Anycast method below =96 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =96 The anycast discovered TURN-server = can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued 6to4? = That is, anyone could set up a badly-maintained, under-provisioned TURN = server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the anycast server you see is being provided to you by your ISP, rather than a = server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready answer... An auto-discovered TURN server must be trusted (whatever method it is discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca =20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca =20 STUN/TURN server --> http://numb.viagenie.ca =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 ------=_NextPart_000_0078_01CF28B8.69935330 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

An= auto-discovered TURN server should advice the best (and maybe only) = path. The Enterprise and/or NSP/ISP making this announcement/offer of = the TURN server are the ones that knows (can = know).

/K= arl

 

Fr=E5n: Oleg = Moskalenko [mailto:mom040267@gmail.com]
Skickat: den 12 = februari 2014 08:37
Till: Muthu Arul Mozhi Perumal = (mperumal)
Kopia: Justin Uberti; Karl Stahl; = tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); = Simon Perreault
=C4mne: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

The = TURN server has to be used when it is either the only option, or if it = provides a better path (I guess the second case is rather = rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi = Perumal (mperumal) <mperumal@cisco.com> = wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would = provide the best user experience doesn't look the right approach. = Instead, if a path through a TURN server exists and does provide lower = RTT, jitter etc, being able to detect and use (or switch to) that path = might be desirable..

 

Muthu

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Justin = Uberti
Sent: Wednesday, February 12, 2014 11:43 = AM
To: Karl Stahl
Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan = Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: = TURN server auto-discovery mechanism for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  R= 20;TURN…to identify WebRTC flows” etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the right = technology here, compared to a more transparent flow identification tool = like MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for = WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method’s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion point.

 

I think that "fooling" is an incorrect = description. The NAT is supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = “TURN…to identify WebRTC flows”

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues “because it is all about = bandwidth”, “it will resolve itself with time” etc., I = strongly object! That is wrong and will be very detrimental for WebRTC = usage. We already see it and I can give numerous examples of how much = less quality demanding VoIP is/is not handled quality wise and that it = matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = – At least forward thinking carrier’s realize that already. = Web RTC will happen. Which customers want to pay for an access with = blocked WebRTC? The carrier’s offering/assuring good WebRTC will = rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this…) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone.

 

Skype, Hangouts, Facetime are doing billions of minutes per = week and the Internet has not melted yet. If we need to do flow = identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to fade = away with the move to IPv6. I don't think we want to make it a critical = element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=E5n: Dan Wing = [mailto:dwing@cisco.com]
Skickat: den 11 = februari 2014 18:25
Till: Marc = Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon = Perreault


=C4mn= e: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs

 

 

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

 

Le = 2014-02-11 =E0 00:39, Dan Wing <dwing@cisco.com> a =E9crit :

 


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> wrote:

 

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all).

 

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced privacy)?

 

-d

 

 

 

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these use-cases.

 

-d<= span lang=3DEN-US>

 

 

 

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon = Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C4mne: Re: [tram] Milestone = 3: TURN server auto-discovery mechanism for enterprise and = ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =E9crit :
> - Note that to achieve some of the above points, TURN = must be favored
> over STUN to enforce that the TURN-path actually = is used. (The Anycast
> method suggested below, = “automatically” does this.)

I understand the STUN vs = TURN priority issue. But I don't see how anycast affects it in any way. = Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the “automatically” within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below – I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) – The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://postellation.viagenie.ca
NAT64/DNS64 = open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server =               --> http://numb.viagenie.ca
________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

_= ______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

 

<= /div>

 


______________________________________= _________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

------=_NextPart_000_0078_01CF28B8.69935330-- From karl.stahl@intertex.se Thu Feb 13 03:38:57 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3D41A01F2 for ; Thu, 13 Feb 2014 03:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 F4jEOAnvYdcX for ; Thu, 13 Feb 2014 03:38:52 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 956841A01EB for ; Thu, 13 Feb 2014 03:38:51 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131238482330; Thu, 13 Feb 2014 12:38:48 +0100 From: "Karl Stahl" To: "'Justin Uberti'" , "'Muthu Arul Mozhi Perumal \(mperumal\)'" References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 13 Feb 2014 12:38:48 +0100 Message-ID: <007c01cf28b0$29a04c40$7ce0e4c0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007D_01CF28B8.8B64B440" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8oGl9KK4iZfuQtSLyFEkBRbAJCIwAlDgYg Content-Language: sv Cc: tireddy@icisco.com, 'Simon Perreault' , 'Oleg Moskalenko' , tram@ietf.org, 'Marc Blanchet' , "'Dan Wing \(dwing\)'" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:38:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_007D_01CF28B8.8B64B440 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Just ICE may result in that the remote end=E2=80=99s proposal overrides = a path that quality wise is better to use. =20 That is why we (also) must assure that an auto-discovered TURN server = actually is used, (instead of a path suggested by the remote end). =20 =20 /Karl =20 Fr=C3=A5n: Justin Uberti [mailto:juberti@google.com]=20 Skickat: den 12 februari 2014 18:46 Till: Muthu Arul Mozhi Perumal (mperumal) Kopia: Oleg Moskalenko; Karl Stahl; tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Agree. If TURN is indeed being provided for the user's benefit, the = client's ICE logic (based on RTT or similar) should result in it = preferring the TURN path. =20 On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) = wrote: Yes, I believe the second case is rare, but would be better than a rat = race b/w administrators trying to block p2p traffic and force it through = a TURN server and apps/endpoints finding smarter ways to bypass them. =20 Muthu =20 From: Oleg Moskalenko [mailto:mom040267@gmail.com]=20 Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The TURN server has to be used when it is either the only option, or if = it provides a better path (I guess the second case is rather rare). =20 On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) = wrote: +1 =20 Forcing all traffic through a TURN server and expecting it would provide = the best user experience doesn't look the right approach. Instead, if a = path through a TURN server exists and does provide lower RTT, jitter = etc, being able to detect and use (or switch to) that path might be = desirable.. =20 Muthu =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); = Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and = necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by = the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle = routing",need a new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D etc! It is not a mistake, but the very need for this = milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like = MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the = wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication = (SIP at that time). However, its largest flaw/problem is that quality = things were not (could not be?) considered. The method=E2=80=99s very = idea (like all similar methods for getting RTC through ordinary = NAT/Firewalls) is to fool the media through a NAT/Firewall that is = unaware of what is happening. Thus, this is root of quality issues (and = bandwidth allocation optimization) that needs to be dealt with: = Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get = media through (and of course with as good quality as required and = possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D It is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =E2=80=9Cbecause it is all = about bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with = time=E2=80=9D etc., I strongly object! That is wrong and will be very = detrimental for WebRTC usage. We already see it and I can give numerous = examples of how much less quality demanding VoIP is/is not handled = quality wise and that it matters. And, what would be bad considering = quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. (Maybe the Web browser can = detect and encourage this=E2=80=A6)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the = browser that there are good media paths to be used, and that the web = browser automatically can chose those, then let us all understand those, = so we can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the = Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) = is a much bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of = WebRTC. =20 /Karl =20 =20 Fr=C3=A5n: Dan Wing [mailto:dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; = Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet = wrote: =20 Le 2014-02-11 =C3=A0 00:39, Dan Wing a =C3=A9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' = path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN = server will do, and the endpoint should prefer TURN candidates over all = others because there might be some functionality / usefulness of TURN = that the user might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =E2=80=9Cautomatically=E2=80=9D within quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) > - 3^rd The Anycast method below =E2=80=93 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready = answer... An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca = =20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca = =20 STUN/TURN server --> http://numb.viagenie.ca = =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_007D_01CF28B8.8B64B440 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Ju= st ICE may result in that the remote end=E2=80=99s proposal overrides a = path that quality wise is better to use.

 

Th= at is why we (also) must assure that an auto-discovered TURN server = actually is used, (instead of a path suggested by the remote end). = =C2=A0

 

/K= arl

 

Fr=C3=A5n: Justin = Uberti [mailto:juberti@google.com]
Skickat: den 12 februari = 2014 18:46
Till: Muthu Arul Mozhi Perumal = (mperumal)
Kopia: Oleg Moskalenko; Karl Stahl; = tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); = Simon Perreault
=C3=84mne: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

Agree. = If TURN is indeed being provided for the user's benefit, the client's = ICE logic (based on RTT or similar) should result in it preferring the = TURN path.

 

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi = Perumal (mperumal) <mperumal@cisco.com> = wrote:

Yes, I = believe the second case is rare, but would be better than a rat race b/w = administrators trying to block p2p traffic and force it through a TURN = server and apps/endpoints finding smarter ways to bypass = them.

 

Muthu

 

From:= Oleg = Moskalenko [mailto:mom040267@gmail.com]
Sent: Wednesday, = February 12, 2014 1:07 PM
To: Muthu Arul Mozhi Perumal = (mperumal)
Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan = Wing (dwing); Simon Perreault


Subject: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

The TURN server has to be used when it is either the only = option, or if it provides a better path (I guess the second case is = rather rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would = provide the best user experience doesn't look the right approach. = Instead, if a path through a TURN server exists and does provide lower = RTT, jitter etc, being able to detect and use (or switch to) that path = might be desirable..

 

Muthu

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Justin = Uberti
Sent: Wednesday, February 12, 2014 11:43 = AM
To: Karl Stahl
Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan = Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: = TURN server auto-discovery mechanism for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the right = technology here, compared to a more transparent flow identification tool = like MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for = WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method=E2=80=99s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion point.

 

I think that "fooling" is an incorrect = description. The NAT is supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues =E2=80=9Cbecause it is all about = bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D = etc., I strongly object! That is wrong and will be very detrimental for = WebRTC usage. We already see it and I can give numerous examples of how = much less quality demanding VoIP is/is not handled quality wise and that = it matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this=E2=80=A6) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone.

 

Skype, Hangouts, Facetime are doing billions of minutes per = week and the Internet has not melted yet. If we need to do flow = identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to fade = away with the move to IPv6. I don't think we want to make it a critical = element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=C3=A5n: Dan Wing = [mailto:dwing@cisco.com]
Skickat: den 11 = februari 2014 18:25
Till: Marc = Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon = Perreault


=C3=84= mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs

 

 

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

 

Le = 2014-02-11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit :

 


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> wrote:

 

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all).

 

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced privacy)?

 

-d

 

 

 

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these use-cases.

 

-d<= span lang=3DEN-US>

 

 

 

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon = Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C3=84mne: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =C3=A9crit :
> - Note that to achieve some of the above points, = TURN must be favored
> over STUN to enforce that the TURN-path = actually is used. (The Anycast
> method suggested below, = =E2=80=9Cautomatically=E2=80=9D does this.)

I understand the STUN = vs TURN priority issue. But I don't see how anycast affects it in any = way. Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the =E2=80=9Cautomatically=E2=80=9D within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below =E2=80=93 I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) =E2=80=93 The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://postellation.viagenie.ca
NAT64/DNS64 = open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server =               --> http://numb.viagenie.ca
________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

_= ______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

 

<= /div>

 


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

 

 

------=_NextPart_000_007D_01CF28B8.8B64B440-- From karl.stahl@intertex.se Thu Feb 13 03:39:42 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC311A01E8 for ; Thu, 13 Feb 2014 03:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 YstJYS2X79tX for ; Thu, 13 Feb 2014 03:39:35 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBF41A01EB for ; Thu, 13 Feb 2014 03:39:34 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131239312452; Thu, 13 Feb 2014 12:39:31 +0100 From: "Karl Stahl" To: "'Muthu Arul Mozhi Perumal \(mperumal\)'" , "'Oleg Moskalenko'" References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Date: Thu, 13 Feb 2014 12:39:32 +0100 Message-ID: <008101cf28b0$433f97f0$c9bec7d0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01CF28B8.A503FFF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPJ7mlnafoQENNEUmFuRpz1h1atZqxMH2AgABvIQD//7gfIIABtHqg Content-Language: sv Cc: tireddy@icisco.com, 'Simon Perreault' , tram@ietf.org, 'Justin Uberti' , 'Marc Blanchet' , "'Dan Wing \(dwing\)'" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:39:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0082_01CF28B8.A503FFF0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It is the Enterprise and/or NSP/ISP making the announcement/offer of the TURN server (by the auto-discovery discussed here) that are the ones = that knows and controls the path advised! And their intent/purpose should be good=85. /Karl =20 Fr=E5n: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 Skickat: den 12 februari 2014 10:28 Till: Oleg Moskalenko Kopia: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault =C4mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 Yes, I believe the second case is rare, but would be better than a rat = race b/w administrators trying to block p2p traffic and force it through a = TURN server and apps/endpoints finding smarter ways to bypass them. =20 Muthu =20 From: Oleg Moskalenko [mailto:mom040267@gmail.com]=20 Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The TURN server has to be used when it is either the only option, or if = it provides a better path (I guess the second case is rather rare). =20 On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: +1 =20 Forcing all traffic through a TURN server and expecting it would provide = the best user experience doesn't look the right approach. Instead, if a path through a TURN server exists and does provide lower RTT, jitter etc, = being able to detect and use (or switch to) that path might be desirable.. =20 Muthu =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle routing",need a = new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =93TURN=85to identify WebRTC flows=94 etc! It is not = a mistake, but the very need for this milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like MALICE. We don't force all HTTP requests to locate a HTTP proxy via anycast, I = don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw/problem is that quality things were not (could not be?) considered. The method=92s very idea (like all similar = methods for getting RTC through ordinary NAT/Firewalls) is to fool the media = through a NAT/Firewall that is unaware of what is happening. Thus, this is root = of quality issues (and bandwidth allocation optimization) that needs to be dealt with: Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get media through (and of course with as good quality as required and possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =93TURN=85to identify WebRTC flows=94 It is also the ONLY way I can see to achieve what we want to achieve and should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not feeding WebRTC into application specific networks like IMS where other methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =93because it is all about = bandwidth=94, =93it will resolve itself with time=94 etc., I strongly object! That is = wrong and will be very detrimental for WebRTC usage. We already see it and I = can give numerous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad = considering quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and would = fight the same battle. But hopefully, those days are (soon) over =96 At least forward thinking carrier=92s realize that already. Web RTC will happen. = Which customers want to pay for an access with blocked WebRTC? The carrier=92s offering/assuring good WebRTC will rather get the customers and income = J. (Maybe the Web browser can detect and encourage this=85)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the browser that there are good media paths to be used, and that the web browser automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) is a much = bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of WebRTC. =20 /Karl =20 =20 Fr=E5n: Dan Wing [mailto:dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; = Simon Perreault =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet wrote: =20 Le 2014-02-11 =E0 00:39, Dan Wing a =E9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. This makes = me concerned that we may be using the wrong technology to solve the = problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the call = to succeed, whatever the properties of its network point of attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the user = might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =E9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =93automatically=94 does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage of = the TURN server (that we wanted to be used for the good purposes listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be adding a route = in a default gateway, adding a firewall rule to eat STUN packets would assure that the provisioned TURN server actually becomes used (and not bypassed = "by accident"). (That was the thought behind the =93automatically=94 within = quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - "anyone = could set up a badly-maintained" - enforcing such ICE usage may not be good.) > - 3^rd The Anycast method below =96 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =96 The anycast discovered TURN-server = can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued 6to4? = That is, anyone could set up a badly-maintained, under-provisioned TURN = server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the anycast server you see is being provided to you by your ISP, rather than a = server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready answer... An auto-discovered TURN server must be trusted (whatever method it is discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca =20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca =20 STUN/TURN server --> http://numb.viagenie.ca =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 ------=_NextPart_000_0082_01CF28B8.A503FFF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It= is the Enterprise and/or NSP/ISP making the announcement/offer of the = TURN server (by the auto-discovery discussed here) that are the ones = that knows and controls the path advised! And their intent/purpose = should be good….

/K= arl

 

Fr=E5n: Muthu Arul = Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]
Skickat: = den 12 februari 2014 10:28
Till: Oleg = Moskalenko
Kopia: Justin Uberti; Karl Stahl; = tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); = Simon Perreault
=C4mne: RE: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

Yes, I = believe the second case is rare, but would be better than a rat race b/w = administrators trying to block p2p traffic and force it through a TURN = server and apps/endpoints finding smarter ways to bypass = them.

 

Muthu

 

From:= Oleg = Moskalenko [mailto:mom040267@gmail.com] =
Sent: Wednesday, February 12, 2014 1:07 PM
To: = Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl = Stahl; tireddy@icisco.com; = Marc Blanchet; tram@ietf.org; Dan = Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: = TURN server auto-discovery mechanism for enterprise and = ISPs

 

The TURN server has to be used when it is either the only = option, or if it provides a better path (I guess the second case is = rather rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would = provide the best user experience doesn't look the right approach. = Instead, if a path through a TURN server exists and does provide lower = RTT, jitter etc, being able to detect and use (or switch to) that path = might be desirable..

 

Muthu

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Justin = Uberti
Sent: Wednesday, February 12, 2014 11:43 = AM
To: Karl Stahl
Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan = Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: = TURN server auto-discovery mechanism for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  R= 20;TURN…to identify WebRTC flows” etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the right = technology here, compared to a more transparent flow identification tool = like MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for = WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method’s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion point.

 

I think that "fooling" is an incorrect = description. The NAT is supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = “TURN…to identify WebRTC flows”

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues “because it is all about = bandwidth”, “it will resolve itself with time” etc., I = strongly object! That is wrong and will be very detrimental for WebRTC = usage. We already see it and I can give numerous examples of how much = less quality demanding VoIP is/is not handled quality wise and that it = matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = – At least forward thinking carrier’s realize that already. = Web RTC will happen. Which customers want to pay for an access with = blocked WebRTC? The carrier’s offering/assuring good WebRTC will = rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this…) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone.

 

Skype, Hangouts, Facetime are doing billions of minutes per = week and the Internet has not melted yet. If we need to do flow = identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to fade = away with the move to IPv6. I don't think we want to make it a critical = element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=E5n: Dan Wing = [mailto:dwing@cisco.com]
Skickat: den 11 = februari 2014 18:25
Till: Marc = Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon = Perreault


=C4mn= e: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs

 

 

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

 

Le = 2014-02-11 =E0 00:39, Dan Wing <dwing@cisco.com> a =E9crit :

 


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> wrote:

 

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all).

 

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced privacy)?

 

-d

 

 

 

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these use-cases.

 

-d<= span lang=3DEN-US>

 

 

 

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon = Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C4mne: Re: [tram] Milestone = 3: TURN server auto-discovery mechanism for enterprise and = ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =E9crit :
> - Note that to achieve some of the above points, TURN = must be favored
> over STUN to enforce that the TURN-path actually = is used. (The Anycast
> method suggested below, = “automatically” does this.)

I understand the STUN vs = TURN priority issue. But I don't see how anycast affects it in any way. = Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the “automatically” within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below – I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) – The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://postellation.viagenie.ca
NAT64/DNS64 = open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server =               --> http://numb.viagenie.ca
________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

_= ______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

 

<= /div>

 


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

 

<= /html> ------=_NextPart_000_0082_01CF28B8.A503FFF0-- From mperumal@cisco.com Thu Feb 13 04:20:22 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A961A0201 for ; Thu, 13 Feb 2014 04:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 tri1KUZk0YPf for ; Thu, 13 Feb 2014 04:20:15 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id E60961A0212 for ; Thu, 13 Feb 2014 04:20:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=90206; q=dns/txt; s=iport; t=1392294014; x=1393503614; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gBIgcDsCCH1zfTAQwxt42k6QDtaUzo26DMsRnH6W87I=; b=V2XUI+BT4/L9cg4gKzXKNMKjFlxO7V2vA8G2yvp9R8WprvWqeKR+LdwJ b9H9l53ZEOO5gTxzY6VF2hLf797bSW0pnS9fokrPx3alO9GlE3g3RNTOm ra5Z6wIr3qNl8XL6lLe/uWiBC0DVhv/8Jgxlt82Z+gQBVbnQgweSIPDTd o=; X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208,217";a="20142690" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 13 Feb 2014 12:20:13 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1DCKDTQ025535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 12:20:13 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.56]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 06:20:13 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Karl Stahl , "'Justin Uberti'" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPKLXxPYEog8wgaUC6SJgg3H1nnQ== Date: Thu, 13 Feb 2014 12:20:12 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> <007c01cf28b0$29a04c40$7ce0e4c0$@stahl@intertex.se> In-Reply-To: <007c01cf28b0$29a04c40$7ce0e4c0$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.115] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DEB7Cxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "tireddy@icisco.com" , 'Simon Perreault' , 'Oleg Moskalenko' , "tram@ietf.org" , 'Marc Blanchet' , "Dan Wing \(dwing\)" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 12:20:22 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DEB7Cxmbrcdx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 fEp1c3QgSUNFIG1heSByZXN1bHQgaW4gdGhhdCB0aGUgcmVtb3RlIGVuZOKAmXMgcHJvcG9zYWwg b3ZlcnJpZGVzIGEgcGF0aA0KfHRoYXQgcXVhbGl0eSB3aXNlIGlzIGJldHRlciB0byB1c2UuDQoN ClRoZW4sIHRoYXQncyBhbiBJQ0UgaW1wbGVtZW50YXRpb24gYW5kIHNob3VsZCBiZSBmaXhlZC4N Cg0KfFRoYXQgaXMgd2h5IHdlIChhbHNvKSBtdXN0IGFzc3VyZSB0aGF0IGFuIGF1dG8tZGlzY292 ZXJlZCBUVVJOIHNlcnZlcg0KfGFjdHVhbGx5IGlzIHVzZWQsIChpbnN0ZWFkIG9mIGEgcGF0aCBz dWdnZXN0ZWQgYnkgdGhlIHJlbW90ZSBlbmQpLg0KDQpBZ2FpbiwgaWYgdGhlIGF1dG8tZGlzY292 ZXJlZCBUVVJOIHNlcnZlciBwcm92aWRlcyBhIGJldHRlciBxdWFsaXR5IHBhdGgsIElDRSBzaG91 bGQgYmUgYWJsZSB0byBkaXNjb3ZlciB0aGF0IHBhdGggYW5kIHVzZSBpdCAtLSB0aGF0J3MgdGhl IGJlc3QgbG9uZyB0ZXJtIHNvbHV0aW9uLCBJTU8uDQoNCk11dGh1DQoNCkZyb206IHRyYW0gW21h aWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLYXJsIFN0YWhsDQpTZW50 OiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgNTowOSBQTQ0KVG86ICdKdXN0aW4gVWJlcnRp JzsgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkNCkNjOiB0aXJlZGR5QGljaXNj by5jb207ICdTaW1vbiBQZXJyZWF1bHQnOyAnT2xlZyBNb3NrYWxlbmtvJzsgdHJhbUBpZXRmLm9y ZzsgJ01hcmMgQmxhbmNoZXQnOyBEYW4gV2luZyAoZHdpbmcpDQpTdWJqZWN0OiBSZTogW3RyYW1d IE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVu dGVycHJpc2UgYW5kIElTUHMNCg0KSnVzdCBJQ0UgbWF5IHJlc3VsdCBpbiB0aGF0IHRoZSByZW1v dGUgZW5k4oCZcyBwcm9wb3NhbCBvdmVycmlkZXMgYSBwYXRoIHRoYXQgcXVhbGl0eSB3aXNlIGlz IGJldHRlciB0byB1c2UuDQoNClRoYXQgaXMgd2h5IHdlIChhbHNvKSBtdXN0IGFzc3VyZSB0aGF0 IGFuIGF1dG8tZGlzY292ZXJlZCBUVVJOIHNlcnZlciBhY3R1YWxseSBpcyB1c2VkLCAoaW5zdGVh ZCBvZiBhIHBhdGggc3VnZ2VzdGVkIGJ5IHRoZSByZW1vdGUgZW5kKS4NCg0KL0thcmwNCg0KRnLD pW46IEp1c3RpbiBVYmVydGkgW21haWx0bzpqdWJlcnRpQGdvb2dsZS5jb21dDQpTa2lja2F0OiBk ZW4gMTIgZmVicnVhcmkgMjAxNCAxODo0Ng0KVGlsbDogTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFs IChtcGVydW1hbCkNCktvcGlhOiBPbGVnIE1vc2thbGVua287IEthcmwgU3RhaGw7IHRpcmVkZHlA aWNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tPjsgTWFyYyBCbGFuY2hldDsgdHJh bUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IERhbiBXaW5nIChkd2luZyk7IFNpbW9u IFBlcnJlYXVsdA0Kw4RtbmU6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1 dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpBZ3JlZS4g SWYgVFVSTiBpcyBpbmRlZWQgYmVpbmcgcHJvdmlkZWQgZm9yIHRoZSB1c2VyJ3MgYmVuZWZpdCwg dGhlIGNsaWVudCdzIElDRSBsb2dpYyAoYmFzZWQgb24gUlRUIG9yIHNpbWlsYXIpIHNob3VsZCBy ZXN1bHQgaW4gaXQgcHJlZmVycmluZyB0aGUgVFVSTiBwYXRoLg0KDQpPbiBXZWQsIEZlYiAxMiwg MjAxNCBhdCAxOjI3IEFNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKSA8bXBl cnVtYWxAY2lzY28uY29tPG1haWx0bzptcGVydW1hbEBjaXNjby5jb20+PiB3cm90ZToNClllcywg SSBiZWxpZXZlIHRoZSBzZWNvbmQgY2FzZSBpcyByYXJlLCBidXQgd291bGQgYmUgYmV0dGVyIHRo YW4gYSByYXQgcmFjZSBiL3cgYWRtaW5pc3RyYXRvcnMgdHJ5aW5nIHRvIGJsb2NrIHAycCB0cmFm ZmljIGFuZCBmb3JjZSBpdCB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgYW5kIGFwcHMvZW5kcG9pbnRz IGZpbmRpbmcgc21hcnRlciB3YXlzIHRvIGJ5cGFzcyB0aGVtLg0KDQpNdXRodQ0KDQpGcm9tOiBP bGVnIE1vc2thbGVua28gW21haWx0bzptb20wNDAyNjdAZ21haWwuY29tPG1haWx0bzptb20wNDAy NjdAZ21haWwuY29tPl0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQgMTowNyBQ TQ0KVG86IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpDQpDYzogSnVzdGluIFVi ZXJ0aTsgS2FybCBTdGFobDsgdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGljaXNj by5jb20+OyBNYXJjIEJsYW5jaGV0OyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3Jn PjsgRGFuIFdpbmcgKGR3aW5nKTsgU2ltb24gUGVycmVhdWx0DQoNClN1YmplY3Q6IFJlOiBbdHJh bV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3Ig ZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpUaGUgVFVSTiBzZXJ2ZXIgaGFzIHRvIGJlIHVzZWQgd2hl biBpdCBpcyBlaXRoZXIgdGhlIG9ubHkgb3B0aW9uLCBvciBpZiBpdCBwcm92aWRlcyBhIGJldHRl ciBwYXRoIChJIGd1ZXNzIHRoZSBzZWNvbmQgY2FzZSBpcyByYXRoZXIgcmFyZSkuDQoNCk9uIFR1 ZSwgRmViIDExLCAyMDE0IGF0IDExOjMyIFBNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1w ZXJ1bWFsKSA8bXBlcnVtYWxAY2lzY28uY29tPG1haWx0bzptcGVydW1hbEBjaXNjby5jb20+PiB3 cm90ZToNCisxDQoNCkZvcmNpbmcgYWxsIHRyYWZmaWMgdGhyb3VnaCBhIFRVUk4gc2VydmVyIGFu ZCBleHBlY3RpbmcgaXQgd291bGQgcHJvdmlkZSB0aGUgYmVzdCB1c2VyIGV4cGVyaWVuY2UgZG9l c24ndCBsb29rIHRoZSByaWdodCBhcHByb2FjaC4gSW5zdGVhZCwgaWYgYSBwYXRoIHRocm91Z2gg YSBUVVJOIHNlcnZlciBleGlzdHMgYW5kIGRvZXMgcHJvdmlkZSBsb3dlciBSVFQsIGppdHRlciBl dGMsIGJlaW5nIGFibGUgdG8gZGV0ZWN0IGFuZCB1c2UgKG9yIHN3aXRjaCB0bykgdGhhdCBwYXRo IG1pZ2h0IGJlIGRlc2lyYWJsZS4uDQoNCk11dGh1DQoNCkZyb206IHRyYW0gW21haWx0bzp0cmFt LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs ZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0IDEx OjQzIEFNDQpUbzogS2FybCBTdGFobA0KQ2M6IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWlsdG86dGly ZWRkeUBpY2lzY28uY29tPjsgTWFyYyBCbGFuY2hldDsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJh bUBpZXRmLm9yZz47IERhbiBXaW5nIChkd2luZyk7IFNpbW9uIFBlcnJlYXVsdA0KU3ViamVjdDog UmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFu aXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNCklubGluZS4NCg0KT24gVHVlLCBGZWIgMTEs IDIwMTQgYXQgMjozNyBQTSwgS2FybCBTdGFobCA8a2FybC5zdGFobEBpbnRlcnRleC5zZTxtYWls dG86a2FybC5zdGFobEBpbnRlcnRleC5zZT4+IHdyb3RlOg0KTGlzdGVuaW5nIHRvIHRoaXMgdGhy ZWFkLCBJIGFtIGFmcmFpZCB3ZSBhcmUgbWlzc2luZyB0aGUgdmVyeSBwb2ludCBhbmQgbmVjZXNz aXR5IGZvciB0aGlzIG1pbGVzdG9uZSENCi0gVGhlcmUgYXJlIHNldmVyZSBOQVQgdHJhdmVyc2Fs IGFuZCBxdWFsaXR5IGlzc3VlcyB0aGF0IHNob3VsZCBhbmQgY2FuIGJlIGRlYWx0IHdpdGggYnkg YSBnb29kIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBhbmQgdGhlIHJpZ2h0IHVzYWdlIGJ5IHRo ZSB0dXJuIGNsaWVudCAodGhlIFdlYlJUQyBicm93c2VyKQ0KDQpUaGVyZSBhcmUgd2F5cywgbm90 IG9ubHk6IEVudGVycHJpc2VzIG9yIElTUHMgd2lzaGluZyB0byBwcm92aWRlIHRoZWlyIG93biBU VVJOIHNlcnZlciwgaW4gYW4gYXR0ZW1wdCB0byByZWR1Y2Ugc28tY2FsbGVkICJ0cmlhbmdsZSBy b3V0aW5nIixuZWVkIGEgbmV3IGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbQ0KQnV0IGFsc286IC0g TlNQcyAoTmV0d29yayBTZXJ2aWNlIFByb3ZpZGVycykgd2FudCB0byBwcm92aWRlIGEgcGF0aCB3 aGVyZSB0aGUgYmFuZHdpZHRoIG9mIFdlYlJUQyBpcyBiZXR0ZXIgY29wZWQgd2l0aC4NCi0gTlNQ cyBvciBFbnRlcnByaXNlcyB3YW50IHRvIG9mZmVyIGFuIEludGVybmV0IGFjY2VzcyBxdWFsaXR5 IHBpcGUgZm9yIHByaW9yaXRpemVkIFJUQyAoUmVhbCBUaW1lIENvbW11bmljYXRpb24pIHRyYWZm aWMuDQotIEVudGVycHJpc2VzIGhhdmluZyByZXN0cmljdGl2ZSBmaXJld2FsbHMsIHdhbnQgdG8g cHJvdmlkZSBhIFVEUC1wYXRoIGZvciBXZWJSVEMgYW5kIHBvc3NpYmx5IGFsc28gZm9yIGJldHRl ciBxdWFsaXR5IHdoZXJlIFJUQyBkbyBub3QgY29tcGV0ZSB3aXRoIGRhdGEgdHJhZmZpYy4NCkFs c28gY29uc2lkZXJpbmcNCi0gTW9iaWxpdHk7IEl0IGlzIGNvbW1vbiB0byBtb3ZlIGZyb20gYSBM QU4gdG8gYWNjZXNzaW5nIHZpYSBXaUZpIG9yIDNHLzRHIE9UVCBjaGFubmVscywgYWxsIHNob3Vs ZCBiZSBhYmxlIHRvIGF1dG9tYXRpY2FsbHkgb2ZmZXIgdGhlaXIgb3duIG9wdGltYWwgVFVSTiBz ZXJ2ZXINCg0KVGhpcyBsZWFkcyB1cyBpbnRvICDigJxUVVJO4oCmdG8gaWRlbnRpZnkgV2ViUlRD IGZsb3dz4oCdIGV0YyEgSXQgaXMgbm90IGEgbWlzdGFrZSwgYnV0IHRoZSB2ZXJ5IG5lZWQgZm9y IHRoaXMgbWlsZXN0b25lIQ0KDQpBZ2FpbiwgaXQgaGFzIG5vdCBiZWVuIGRlbW9uc3RyYXRlZCB3 aHkgVFVSTiBpcyB0aGUgcmlnaHQgdGVjaG5vbG9neSBoZXJlLCBjb21wYXJlZCB0byBhIG1vcmUg dHJhbnNwYXJlbnQgZmxvdyBpZGVudGlmaWNhdGlvbiB0b29sIGxpa2UgTUFMSUNFLiBXZSBkb24n dCBmb3JjZSBhbGwgSFRUUCByZXF1ZXN0cyB0byBsb2NhdGUgYSBIVFRQIHByb3h5IHZpYSBhbnlj YXN0LCBJIGRvbid0IHNlZSB3aHkgd2UgbmVlZCB0byBkbyB0aGUgc2FtZSBmb3IgV2ViUlRDLg0K DQpXaGF0IGFyZSB0aGUgaGVzaXRhdGlvbnMgcmFpc2VkIGhlcmU/DQo+IFRVUk4gcHJpbWFyaWx5 IHRvIGlkZW50aWZ5IFdlYlJUQyBmbG93cywgYXMgb3Bwb3NlZCB0byB1c2luZyBpdCBhcyBhIE5B VCB0cmF2ZXJzYWwgdG9vbC4gVGhpcyBtYWtlcyBtZSBjb25jZXJuZWQgdGhhdCB3ZSBtYXkgYmUg dXNpbmcgdGhlIHdyb25nIHRlY2hub2xvZ3kgdG8gc29sdmUgdGhlIHByb2JsZW0NCkl0IGlzIGNv cnJlY3QgdGhhdCBJQ0UvU1RVTi9UVVJOIHdhcyBkZXNpZ25lZCB0byBhZGRyZXNzIHRoZSBOQVQv RmlyZXdhbGwgdHJhdmVyc2FsIHByb2JsZW0gYXNzb2NpYXRlZCB3aXRoIHJlYWwtdGltZSBjb21t dW5pY2F0aW9uIChTSVAgYXQgdGhhdCB0aW1lKS4gSG93ZXZlciwgaXRzIGxhcmdlc3QgZmxhdy9w cm9ibGVtIGlzIHRoYXQgcXVhbGl0eSB0aGluZ3Mgd2VyZSBub3QgKGNvdWxkIG5vdCBiZT8pIGNv bnNpZGVyZWQuIFRoZSBtZXRob2TigJlzIHZlcnkgaWRlYSAobGlrZSBhbGwgc2ltaWxhciBtZXRo b2RzIGZvciBnZXR0aW5nIFJUQyB0aHJvdWdoIG9yZGluYXJ5IE5BVC9GaXJld2FsbHMpIGlzIHRv IGZvb2wgdGhlIG1lZGlhIHRocm91Z2ggYSBOQVQvRmlyZXdhbGwgdGhhdCBpcyB1bmF3YXJlIG9m IHdoYXQgaXMgaGFwcGVuaW5nLiBUaHVzLCB0aGlzIGlzIHJvb3Qgb2YgcXVhbGl0eSBpc3N1ZXMg KGFuZCBiYW5kd2lkdGggYWxsb2NhdGlvbiBvcHRpbWl6YXRpb24pIHRoYXQgbmVlZHMgdG8gYmUg ZGVhbHQgd2l0aDogUmVhbC10aW1lIHRyYWZmaWMgZmlnaHRpbmcgd2l0aCBhIGRhdGEgdHJhZmZp YyBjcm93ZGVkIGNvbmdlc3Rpb24gcG9pbnQuDQoNCkkgdGhpbmsgdGhhdCAiZm9vbGluZyIgaXMg YW4gaW5jb3JyZWN0IGRlc2NyaXB0aW9uLiBUaGUgTkFUIGlzIHN1cHBvc2VkIHRvIGJlIHRyYW5z cGFyZW50IHRvIHRoZSBjbGllbnQuDQoNCkJ1dCwgYSBCTEVTU0lORyBvZiBJQ0UvU1RVTi9UVVJO IGlzIHRoYXQgaXQgY2FuIGJlIHNlZW4gYXMgYSBsZWdpdGltYXRlIHJlcXVlc3QgZm9yIGEgc3Vp dGFibGUgcGlwZSBmb3IgcXVhbGl0eSBkZW1hbmRpbmcgcmVhbCB0aW1lIHRyYWZmaWMuIOKYug0K SUNFIGlzIGEgcHJlLXByb3RvY29sIHlvdSB1c2UgYmVjYXVzZSB5b3Ugd2FudCBhIHBhdGggZm9y IHJlYWwtdGltZSBtZWRpYSBiZXR3ZWVuIHBhcnRpZXMuIEhlcmU6IFRoZSBicm93c2VyIHNheXMg a25vY2sga25vY2ssIEkgd2FudCB0byBnZXQgbWVkaWEgdGhyb3VnaCAoYW5kIG9mIGNvdXJzZSB3 aXRoIGFzIGdvb2QgcXVhbGl0eSBhcyByZXF1aXJlZCBhbmQgcG9zc2libGUpLg0KDQpJZiB0aGUg TkFUL0ZpcmV3YWxsIG93bmVyIGFuZCBuZXR3b3JrIG93bmVyIGFyZSBhbGxvd2VkIHRvIHNlZSB0 aGVzZSByZXF1ZXN0cywgdGhleSBjYW4gaGVscC9hc3Npc3QgaW4gYWNoaWV2aW5nIHRoZSBnb29k IG1lZGlhIHBhdGguIElmIHRoZXkgYXJlIG5vdCBhd2FyZSwgdGhleSBjYW5ub3QgaGVscCENCg0K SG9wZSB0aGlzIG1hZGUgaXQgdW5kZXJzdGFuZGFibGUgb24gYW4gb3ZlcnZpZXcgbGV2ZWwgaG93 IHRoaXMgY2FuIGJlY29tZSDigJxUVVJO4oCmdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dz4oCdDQpJ dCBpcyBhbHNvIHRoZSBPTkxZIHdheSBJIGNhbiBzZWUgdG8gYWNoaWV2ZSB3aGF0IHdlIHdhbnQg dG8gYWNoaWV2ZSBhbmQgc2hvdWxkIGJlIHRoZSBhaW0gYW5kIHJlcXVpcmVtZW50IG9mIHRoaXMg bWlsZXN0b25lLg0KDQpJIGFtIHRhbGtpbmcgYWJvdXQgZ2VuZXJhbCB1c2FnZSBvZiBXZWJSVEMg b3ZlciBJbnRlcm5ldC9tb2JpbGUgT1RUIChub3QgZmVlZGluZyBXZWJSVEMgaW50byBhcHBsaWNh dGlvbiBzcGVjaWZpYyBuZXR3b3JrcyBsaWtlIElNUyB3aGVyZSBvdGhlciBtZXRob2RzIG1heSBl eGlzdCkuDQoNClRoaXMgaXMgZ29vZCwgbm90IGV2aWwhDQoNCklmIHRoZSBoZXNpdGF0aW9ucyBh cmUgcmFpc2VkIGJlY2F1c2Ugb2YgYSBiZWxpZWYvaG9wZS93aXNoIHRoYXQgdGhlcmUgYXJlIG5v IG9yIHdpbGwgbm90IGJlIHNldmVyZSBxdWFsaXR5IGlzc3VlcyDigJxiZWNhdXNlIGl0IGlzIGFs bCBhYm91dCBiYW5kd2lkdGjigJ0sIOKAnGl0IHdpbGwgcmVzb2x2ZSBpdHNlbGYgd2l0aCB0aW1l 4oCdIGV0Yy4sIEkgc3Ryb25nbHkgb2JqZWN0ISBUaGF0IGlzIHdyb25nIGFuZCB3aWxsIGJlIHZl cnkgZGV0cmltZW50YWwgZm9yIFdlYlJUQyB1c2FnZS4gV2UgYWxyZWFkeSBzZWUgaXQgYW5kIEkg Y2FuIGdpdmUgbnVtZXJvdXMgZXhhbXBsZXMgb2YgaG93IG11Y2ggbGVzcyBxdWFsaXR5IGRlbWFu ZGluZyBWb0lQIGlzL2lzIG5vdCBoYW5kbGVkIHF1YWxpdHkgd2lzZSBhbmQgdGhhdCBpdCBtYXR0 ZXJzLiBBbmQsIHdoYXQgd291bGQgYmUgYmFkIGNvbnNpZGVyaW5nIHF1YWxpdHkgaXNzdWVzIGFu ZCBhbGxvd2luZy9lbmNvdXJhZ2luZyBtZXRob2RzIHRvIGRlYWwgd2l0aCB0aGVtPw0KDQpJZiB0 aGUgaGVzaXRhdGlvbnMgYXJlIHJhaXNlZCwgYmVjYXVzZSBvZiBzdXNwaWNpb24gdGhhdCB0aGUg bWV0aG9kcyB3ZSBtYXkgcmVjb21tZW5kIG1heSBiZSBtaXN1c2VkIHRvIHN0b3AvYmxvY2svZGVz dHJveSBXZWJSVEMgdXNhZ2UgKGUuZy4gdG8gcHJvdGVjdCBpbmNvbWUgZnJvbSBjYXJyaWVyIHRl bGVwaG9ueSB0cmFmZmljKSwgSSBjb3VsZCB1bmRlcnN0YW5kIGFuZCB3b3VsZCBmaWdodCB0aGUg c2FtZSBiYXR0bGUuIEJ1dCBob3BlZnVsbHksIHRob3NlIGRheXMgYXJlIChzb29uKSBvdmVyIOKA kyBBdCBsZWFzdCBmb3J3YXJkIHRoaW5raW5nIGNhcnJpZXLigJlzIHJlYWxpemUgdGhhdCBhbHJl YWR5LiBXZWIgUlRDIHdpbGwgaGFwcGVuLiBXaGljaCBjdXN0b21lcnMgd2FudCB0byBwYXkgZm9y IGFuIGFjY2VzcyB3aXRoIGJsb2NrZWQgV2ViUlRDPyBUaGUgY2FycmllcuKAmXMgb2ZmZXJpbmcv YXNzdXJpbmcgZ29vZCBXZWJSVEMgd2lsbCByYXRoZXIgZ2V0IHRoZSBjdXN0b21lcnMgYW5kIGlu Y29tZSDimLouIChNYXliZSB0aGUgV2ViIGJyb3dzZXIgY2FuIGRldGVjdCBhbmQgZW5jb3VyYWdl IHRoaXPigKYpDQoNCklmIHRoZXJlIGFyZSB0ZWNobmljYWwgY29uY2VybnMgb2YgYmFkIHJlc3Vs dCwgb3IgYmV0dGVyIG1ldGhvZHMgYWxsb3dpbmcgbmV0d29yayBwcm92aWRlcnMgYW5kIExBTiBt YW5hZ2VycyB0byBvZmZlciBhbmQgaW5mb3JtIHRoZSBicm93c2VyIHRoYXQgdGhlcmUgYXJlIGdv b2QgbWVkaWEgcGF0aHMgdG8gYmUgdXNlZCwgYW5kIHRoYXQgdGhlIHdlYiBicm93c2VyIGF1dG9t YXRpY2FsbHkgY2FuIGNob3NlIHRob3NlLCB0aGVuIGxldCB1cyBhbGwgdW5kZXJzdGFuZCB0aG9z ZSwgc28gd2UgY2FuIGFjaGlldmUgd2hhdCBzaG91bGQgYmUgYWNoaWV2ZWQgYnkgdGhpcyBtaWxl c3RvbmUuDQoNClNreXBlLCBIYW5nb3V0cywgRmFjZXRpbWUgYXJlIGRvaW5nIGJpbGxpb25zIG9m IG1pbnV0ZXMgcGVyIHdlZWsgYW5kIHRoZSBJbnRlcm5ldCBoYXMgbm90IG1lbHRlZCB5ZXQuIElm IHdlIG5lZWQgdG8gZG8gZmxvdyBpZGVudGlmaWNhdGlvbiB0byBhbGxvdyB0cmFmZmljIHRvIGJl IHByaW9yaXRpemVkLCBmaW5lIChzZWUgYWJvdmUgcmVnYXJkaW5nIG15IHByZWZlcnJlZCBhcHBy b2FjaCksIGJ1dCBmb3JjaW5nIGFsbCBXZWJSVEMgdHJhZmZpYyB0aHJvdWdoIGEgTUlUTSAoVFVS TiBzZXJ2ZXIpIGlzIGEgbXVjaCBiaWdnZXIganVtcCB0aGF0IEkgZG9uJ3QgeWV0IHNlZSB0aGUg anVzdGlmaWNhdGlvbiBmb3IuDQoNCkluIHNob3J0OiBUVVJOIGlzIGEgdGVjaG5vbG9neSB0aGF0 IGlzIHN1cHBvc2VkIHRvIGZhZGUgYXdheSB3aXRoIHRoZSBtb3ZlIHRvIElQdjYuIEkgZG9uJ3Qg dGhpbmsgd2Ugd2FudCB0byBtYWtlIGl0IGEgY3JpdGljYWwgZWxlbWVudCBvZiBXZWJSVEMuDQoN Ci9LYXJsDQoNCg0KRnLDpW46IERhbiBXaW5nIFttYWlsdG86ZHdpbmdAY2lzY28uY29tPG1haWx0 bzpkd2luZ0BjaXNjby5jb20+XQ0KU2tpY2thdDogZGVuIDExIGZlYnJ1YXJpIDIwMTQgMTg6MjUN ClRpbGw6IE1hcmMgQmxhbmNoZXQNCktvcGlhOiBKdXN0aW4gVWJlcnRpOyB0aXJlZGR5QGljaXNj by5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT47IEthcmwgU3RhaGw7IHRyYW1AaWV0Zi5v cmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+OyBTaW1vbiBQZXJyZWF1bHQNCg0Kw4RtbmU6IFJlOiBb dHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBm b3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQoNCk9uIEZlYiAxMSwgMjAxNCwgYXQgOTowOCBBTSwg TWFyYyBCbGFuY2hldCA8bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYTxtYWlsdG86bWFyYy5ibGFu Y2hldEB2aWFnZW5pZS5jYT4+IHdyb3RlOg0KDQpMZSAyMDE0LTAyLTExIMOgIDAwOjM5LCBEYW4g V2luZyA8ZHdpbmdAY2lzY28uY29tPG1haWx0bzpkd2luZ0BjaXNjby5jb20+PiBhIMOpY3JpdCA6 DQoNCg0KT24gRmViIDEwLCAyMDE0LCBhdCA1OjMwIFBNLCBKdXN0aW4gVWJlcnRpIDxqdWJlcnRp QGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpHb29kIHRv IHNlZSB0aGVyZSBpcyBhIGxvdCBvZiBpbnRlcmVzdCBmb3IgdGhpcyBtaWxlc3RvbmUuIEJ1dCBi YXNlZCBvbiB0aGUgZGVzY3JpcHRpb24gaGVyZSwgaXQgc2VlbXMgbGlrZSB3ZSB3YW50IHRvIHVz ZSBUVVJOIHByaW1hcmlseSB0byBpZGVudGlmeSBXZWJSVEMgZmxvd3MsIGFzIG9wcG9zZWQgdG8g dXNpbmcgaXQgYXMgYSBOQVQgdHJhdmVyc2FsIHRvb2wuIFRoaXMgbWFrZXMgbWUgY29uY2VybmVk IHRoYXQgd2UgbWF5IGJlIHVzaW5nIHRoZSB3cm9uZyB0ZWNobm9sb2d5IHRvIHNvbHZlIHRoZSBw cm9ibGVtLg0KDQorMS4NCg0KSSB3b3VsZCBwcmVmZXIgYWxsb3dpbmcgZmxvd3MgdG8gZXN0YWJs aXNoIHRoZW1zZWx2ZXMgdXNpbmcgdGhlaXIgJ2Jlc3QnIHBhdGgsIGFuZCB0aGUgYmVzdCBwYXRo IGlzIHNlbGRvbSB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIuICBXaGVuIHdlIGltYWdpbmUgSVB2NiBp biBvdXIgZnV0dXJlLCB3ZSBkb24ndCB3YW50IHRvIGZvcmNlIGFuIGFwcGxpY2F0aW9uLWxldmVs IHByb3h5IChUVVJOKSBzZXJ2ZXIgb24gdGhlIHBhdGggc29sZWx5IGZvciB0cmF2ZXJzaW5nIGFu IElQdjYgZmlyZXdhbGwuDQoNCg0KSXQgc2VlbXMgdGhpcyB0aHJlYWQgaXMgY29uZmxhdGluZyBh bGwgdGhlIHBvc3NpYmxlIHJlYXNvbnMgLyBqdXN0aWZpY2F0aW9ucyBmb3IgVFVSTjoNCiAgKiBt b2JpbGl0eQ0KICAqIE5BVCB0cmF2ZXJzYWwgKGJvdGggZW5kcG9pbnRzIGFyZSBiZWhpbmQgZW5k cG9pbnQtZGVwZW5kZW50IG1hcHBpbmcgTkFUcykNCiAgKiBmaXJld2FsbCB0cmF2ZXJzYWwgKGZp cmV3YWxsIGJsb2NrcyBVRFApDQogICogZW5oYW5jaW5nIHByaXZhY3kNCg0KVW5mb3J0dW5hdGVs eSB0aGUgVFVSTiBzZXJ2ZXIgbm9yIHRoZSBlbmRwb2ludCByZWFsbHkga25vdyB3aGljaCBvZiB0 aG9zZSB1c2UtY2FzZXMgaXMgZGVzaXJlZCAoYnkgdGhlIHVzZXIgb3IgYnkgdGhlIElUIG5ldHdv cmsgYWRtaW5pc3RyYXRvcikgb3IgbmVjZXNzYXJ5IChmb3IgdGhlIGNhbGwgdG8gd29yayBhdCBh bGwpLg0KDQpEYW4sIHdoaWxlIEkgYWdyZWUgaW4gcHJpbmNpcGxlLCBJIGRvdWJ0IHRoYXQgYSB1 c2VyIGNvdWxkIGV2ZXIgc2F5ICJJIHdhbnQgbW9iaWxpdHkgb3IgSSB3YW50IE5BVCB0cmF2ZXJz YWwiLiBJIHRoaW5rIHRoZSB1c2VyIG9ubHkgd2FudCB0aGUgY2FsbCB0byBzdWNjZWVkLCB3aGF0 ZXZlciB0aGUgcHJvcGVydGllcyBvZiBpdHMgbmV0d29yayBwb2ludCBvZiBhdHRhY2htZW50IGFy ZS4NCg0KU28gd2hhdCBjYW4gd2UgZG8/ICBTaG91bGQgdGhlIFRVUk4gc2VydmVyIHByb3ZpZGUg YW55IGFuZCBhbGwgc2VydmljZXMgdGhlIFRVUk4gY2xpZW50IG1pZ2h0IHBvc3NpYmx5IHdhbnQs IGFzIHRoYXQgaXMgd2hhdCBhIHJvYnVzdCBUVVJOIHNlcnZlciB3aWxsIGRvLCBhbmQgdGhlIGVu ZHBvaW50IHNob3VsZCBwcmVmZXIgVFVSTiBjYW5kaWRhdGVzIG92ZXIgYWxsIG90aGVycyBiZWNh dXNlIHRoZXJlIG1pZ2h0IGJlIHNvbWUgZnVuY3Rpb25hbGl0eSAvIHVzZWZ1bG5lc3Mgb2YgVFVS TiB0aGF0IHRoZSB1c2VyIG1pZ2h0IGdhaW4gdGhyb3VnaCBUVVJOIChlLmcuLCBlbmhhbmNlZCBw cml2YWN5KT8NCg0KLWQNCg0KDQoNCiBUaGlzIHNlZW1zIHByb2JsZW1hdGljLiAgUGVyaGFwcyB3 ZSBuZWVkIGEgd2F5IHRvIHNpZ25hbCB0aGUgZGVzaXJlZCB1c2UtY2FzZSAoInRyYWl0IiksIG9y IGFzIEp1c3RpbiBzdWdnZXN0cywgdXNpbmcgYSBkaWZmZXJlbnQgdGVjaG5vbG9neSBmb3Igc29t ZSBvZiB0aGVzZSB1c2UtY2FzZXMuDQoNCi1kDQoNCg0KDQoNCk9uIE1vbiwgRmViIDEwLCAyMDE0 IGF0IDM6MTggUE0sIEthcmwgU3RhaGwgPGthcmwuc3RhaGxAaW50ZXJ0ZXguc2U8bWFpbHRvOmth cmwuc3RhaGxAaW50ZXJ0ZXguc2U+PiB3cm90ZToNClNpbW9uLA0KDQpHb29kIHF1ZXN0aW9ucyAt IHNlZSBpbmxpbmUgYmVsb3cgLS0+IC4NClNvbWUgbW9yZSB0aG91Z2h0IGlzIHJlcXVpcmVkIQ0K DQovS2FybA0KDQotLS0tLVVyc3BydW5nbGlndCBtZWRkZWxhbmRlLS0tLS0NCkZyw6VuOiB0cmFt IFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5v cmc+XSBGw7ZyIFNpbW9uIFBlcnJlYXVsdA0KU2tpY2thdDogZGVuIDEwIGZlYnJ1YXJpIDIwMTQg MTU6MTYNClRpbGw6IEthcmwgU3RhaGw7IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5v cmc+OyB0aXJlZGR5QGljaXNjby5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT4NCsOEbW5l OiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNo YW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KS2FybCwNCg0KSXQgaXMgZ3JlYXQgdG8g c2VlIHN1Y2ggZW50aHVzaWFzbSEgVGhhbmtzIQ0KDQpJIGhhdmUgYSBjb3VwbGUgdGVjaG5pY2Fs IHF1ZXN0aW9ucy4uLg0KDQpMZSAyMDE0LTAyLTA4IDA4OjExLCBLYXJsIFN0YWhsIGEgw6ljcml0 IDoNCj4gLSBOb3RlIHRoYXQgdG8gYWNoaWV2ZSBzb21lIG9mIHRoZSBhYm92ZSBwb2ludHMsIFRV Uk4gbXVzdCBiZSBmYXZvcmVkDQo+IG92ZXIgU1RVTiB0byBlbmZvcmNlIHRoYXQgdGhlIFRVUk4t cGF0aCBhY3R1YWxseSBpcyB1c2VkLiAoVGhlIEFueWNhc3QNCj4gbWV0aG9kIHN1Z2dlc3RlZCBi ZWxvdywg4oCcYXV0b21hdGljYWxseeKAnSBkb2VzIHRoaXMuKQ0KDQpJIHVuZGVyc3RhbmQgdGhl IFNUVU4gdnMgVFVSTiBwcmlvcml0eSBpc3N1ZS4gQnV0IEkgZG9uJ3Qgc2VlIGhvdyBhbnljYXN0 IGFmZmVjdHMgaXQgaW4gYW55IHdheS4gQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbj8NCi0tLSBHb29k IHBvaW50IC0gSSB3YXMgYSBiaXQgcXVpY2sgaGVyZSAobWF5YmUgdG9vIHF1aWNrKQ0KV2UgaGF2 ZSBnaXZlbiB0aGlzIHF1aXRlIGJpdCBvZiB0aG91Z2h0LCBzaW5jZSBldmVuIGlmIGEgVFVSTiBz ZXJ2ZXIgaXMgcHJvdmlkZWQgYW5kIGRpc2NvdmVyZWQsIENVUlJFTlQgdXNhZ2Ugb2YgSUNFIG1h eSBzdWdnZXN0IGEgY2FuZGlkYXRlIGZyb20gdGhlIHJlbW90ZSBwYXJ0eSB0aGF0IHdpbGwgbWFr ZSBhIGNvbm5lY3Rpb24gd2l0aG91dCB0aGUgbmVlZC91c2FnZSBvZiB0aGUgVFVSTiBzZXJ2ZXIg KHRoYXQgd2Ugd2FudGVkIHRvIGJlIHVzZWQgZm9yIHRoZSBnb29kIHB1cnBvc2VzIGxpc3RlZCku DQoNClRoZSBvbmx5IHdheSB3ZSBmb3VuZCBhcm91bmQgdGhpcywgd2FzIHRvIHN0b3AgU1RVTiB0 aHJvdWdoIHRoZSBJUCBkZWZhdWx0IGdhdGV3YXkgKGxpa2UgYSByZXN0cmljdGl2ZSBFbnRlcnBy aXNlIGZpcmV3YWxsIGRvZXMgaW5oaWJpdGluZyBJQ0UgY29ubmVjdGl2aXR5LCB3aGljaCBvdGhl cnMgYXJlIGNvbmNlcm5lZCBhYm91dC4uLikuIFNpbmNlIHRoZSBwcm92aXNpb25pbmcgb2YgYXV0 by1kaXNjb3ZlcnkgdXNpbmcgdGhlIGFueWNhc3QgbWVjaGFuaXNtLCB3b3VsZCBiZSBhZGRpbmcg YSByb3V0ZSBpbiBhIGRlZmF1bHQgZ2F0ZXdheSwgYWRkaW5nIGEgZmlyZXdhbGwgcnVsZSB0byBl YXQgU1RVTiBwYWNrZXRzIHdvdWxkIGFzc3VyZSB0aGF0IHRoZSBwcm92aXNpb25lZCBUVVJOIHNl cnZlciBhY3R1YWxseSBiZWNvbWVzIHVzZWQgKGFuZCBub3QgYnlwYXNzZWQgImJ5IGFjY2lkZW50 IikuIChUaGF0IHdhcyB0aGUgdGhvdWdodCBiZWhpbmQgdGhlIOKAnGF1dG9tYXRpY2FsbHnigJ0g d2l0aGluIHF1b3Rlcy4pDQoNCkJVVCwgc2luY2UgeW91IGJyb3VnaHQgdXAgdGhlIHF1ZXN0aW9u LCBhc3N1bWluZyB0aGF0IHdlIGhhdmUgdGhlIHBvd2VyIHRvIGVuZm9yY2UgV2ViUlRDIHVzYWdl IG9mIElDRSwgSSBiZWxpZXZlIGEgTVVTVCByZXF1aXJlbWVudCB0byB1c2UgYW4gYXV0by1kaXNj b3ZlcmVkIFRVUk4gc2VydmVyIGluc3RlYWQgb2YgU1RVTiwgd291bGQgc29sdmUgdGhlIHNhbWUg cHJvYmxlbS4gSG93ZXZlciwgdGhpbmtpbmcgZnVydGhlciAoaW4gcmVsYXRpb24gdG8geW91ciBu ZXh0IHF1ZXN0aW9uIC0gImFueW9uZSBjb3VsZCBzZXQgdXAgYSBiYWRseS1tYWludGFpbmVkIiAt IGVuZm9yY2luZyBzdWNoIElDRSB1c2FnZSBtYXkgbm90IGJlIGdvb2QuKQ0KDQoNCj4gLSAzXnJk IFRoZSBBbnljYXN0IG1ldGhvZCBiZWxvdyDigJMgSSBzZWUgbm8gcHJvYmxlbQ0KPg0KPiBJdCBh bHNvIGhhcyB0aGUgYWR2YW50YWdlIG9mIGVuY291cmFnaW5nIChidXQgbm90IHJlcXVpcmluZykg dGhlDQo+IFNUVU4vVFVSTiB0byBiZSBidWlsdCBpbiB0aGUgZGVmYXVsdCBnYXRld2F5IG9yIE5B VC9maXJld2FsbC9hY2Nlc3MNCj4gcm91dGVyIGl0c2VsZiwgd2l0aCBhIHNlY29uZCBpbnRlcmZh Y2UgdG8gYSBwdWJsaWMgSVAgYWRkcmVzcyBvbiB0aGUNCj4gV0FOIHNpZGUuIChDdXJyZW50IHZv bHVtZSBkZXBsb3llZCwgbG93IGNvc3QgTlNQIHRyaXBsZSBwbGF5IG1vZGVtcw0KPiB1c3VhbGx5 IGhhdmUgYSBxdWFsaXR5IGFzc3VyZWQgbGV2ZWwgMiBvciBsZXZlbCAzIFdBTiBwaXBlIGZvciBq dXN0DQo+IHZvaWNlIChhbmQgYW5vdGhlciBmb3IgSVBUVikg4oCTIFRoZSBhbnljYXN0IGRpc2Nv dmVyZWQgVFVSTi1zZXJ2ZXIgY2FuDQo+IGJlIHRoZSBhY2Nlc3MgZ2F0ZXdheSB0byBzdWNoIHF1 YWxpdHkgcGlwZSBmb3IgV2ViUlRDIG1lZGlhLCBpbiBhDQo+IHNpbmdsZSBOU1AgcHJvdmlkZWQg Q1BFLCBzY2FsaW5nIGZyb20gcmVzaWRlbnRpYWwgYW5kIHVwLikNCg0KU3VwcG9zZSB3ZSBkZWZp bmUgd2VsbC1rbm93biBhbnljYXN0IFRVUk4gc2VydmVyIGFkZHJlc3Nlcy4gSG93IHdvdWxkIHRo aXMgbm90IGJlIHN1YmplY3QgdG8gdGhlIHNhbWUgc2VydmljZSBxdWFsaXR5IGlzc3VlcyB0aGF0 IHBsYWd1ZWQgNnRvND8gVGhhdCBpcywgYW55b25lIGNvdWxkIHNldCB1cCBhIGJhZGx5LW1haW50 YWluZWQsIHVuZGVyLXByb3Zpc2lvbmVkIFRVUk4gc2VydmVyIGFuZCBhbm5vdW5jZSBpdCBvdmVy IEJHUCB0byB0aGUgd29ybGQsIGFzIGl0IHdhcyBkb25lIGZvcg0KNnRvNCByZWxheXMuIE9yIGp1 c3QgYmFkIEJHUCBvdXRib3VuZCBmaWx0ZXIgY29uZmlndXJhdGlvbi4gQW5kIGhvdyBjYW4gd2Ug cHJldmVudCB0cmlhbmdsZSByb3V0aW5nPyBUaGVyZSBpcyBub3RoaW5nIGd1YXJhbnRlZWluZyB0 aGF0IHRoZSBhbnljYXN0IHNlcnZlciB5b3Ugc2VlIGlzIGJlaW5nIHByb3ZpZGVkIHRvIHlvdSBi eSB5b3VyIElTUCwgcmF0aGVyIHRoYW4gYSBzZXJ2ZXIgc2l0dGluZyBvbiB0aGUgb3RoZXIgc2lk ZSBvZiB0aGUgcGxhbmV0Lg0KLS0tIEdvb2QgcG9pbnQgLSBuZWVkcyB0byBiZSByZXNvbHZlZC4g Rm9yIHRoaXMgSSBkb24ndCBoYXZlIGEgcmVhZHkgYW5zd2VyLi4uDQpBbiBhdXRvLWRpc2NvdmVy ZWQgVFVSTiBzZXJ2ZXIgbXVzdCBiZSB0cnVzdGVkICh3aGF0ZXZlciBtZXRob2QgaXQgaXMgZGlz Y292ZXJlZCBieSkuIFdlIGFyZSB0cnVzdGluZyB0aGUgb25lIHByb3ZpZGluZyB1cyB3aXRoIGFu IElQIGFkZHJlc3MgYW5kIGRlZmF1bHQgZ2F0ZXdheSBhbnl3YXkuIEl0IHdvdWxkIGJlIGVhc3kg aWYgd2UgY291bGQgcmV1c2UgdGhhdCB0cnVzdCwgaW5zdGVhZCBvZiBhbm90aGVyIG1lY2hhbmlz bXMuDQoNCklzIHRoZXJlIGEgZ29vZCB3YXkgZm9yIHRoZSBicm93c2VyIHRvIGNoZWNrIHRoYXQg dGhlIGFueWNhc3QgYWRkcmVzcyBpcyBub3QgaGFuZGxlZCBiZXlvbmQgdGhlIG5ldHdvcmsgc2Vy dmljZSBwcm92aWRlcidzIGRlZmF1bHQgZ2F0ZXdheT8gSWRlYXM/DQoNCg0KDQpUaGFua3MsDQpT aW1vbg0KLS0NCkRUTiBtYWRlIGVhc3ksIGxlYW4sIGFuZCBzbWFydCAtLT4gaHR0cDovL3Bvc3Rl bGxhdGlvbi52aWFnZW5pZS5jYTxodHRwOi8vcG9zdGVsbGF0aW9uLnZpYWdlbmllLmNhLz4NCk5B VDY0L0ROUzY0IG9wZW4tc291cmNlICAgICAgICAtLT4gaHR0cDovL2VjZHlzaXMudmlhZ2VuaWUu Y2E8aHR0cDovL2VjZHlzaXMudmlhZ2VuaWUuY2EvPg0KU1RVTi9UVVJOIHNlcnZlciAgICAgICAg ICAgICAgIC0tPiBodHRwOi8vbnVtYi52aWFnZW5pZS5jYTxodHRwOi8vbnVtYi52aWFnZW5pZS5j YS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJh bSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFt QGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90cmFtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJh bUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBt YWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0 cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg0K --_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DEB7Cxmbrcdx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsdWU7fQ0KcC5CYWxsb25ndGV4dCwgbGku QmFsbG9uZ3RleHQsIGRpdi5CYWxsb25ndGV4dA0KCXttc28tc3R5bGUtbmFtZTpCYWxsb25ndGV4 dDsNCgltc28tc3R5bGUtbGluazoiQmFsbG9uZ3RleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQmFsbG9uZ3RleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb25ndGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6QmFsbG9uZ3RleHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fEp1c3QgSUNFIG1heSByZXN1bHQgaW4gdGhhdCB0 aGUgcmVtb3RlIGVuZOKAmXMgcHJvcG9zYWwgb3ZlcnJpZGVzIGEgcGF0aA0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnx0aGF0IHF1YWxpdHkg d2lzZSBpcyBiZXR0ZXIgdG8gdXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VGhlbiwgdGhhdCdzIGFuIElDRSBpbXBsZW1lbnRhdGlv biBhbmQgc2hvdWxkIGJlIGZpeGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+fFRoYXQgaXMgd2h5IHdlIChhbHNvKSBtdXN0IGFzc3Vy ZSB0aGF0IGFuIGF1dG8tZGlzY292ZXJlZCBUVVJOIHNlcnZlcg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPnxhY3R1YWxseSBpcyB1c2VkLCAo aW5zdGVhZCBvZiBhIHBhdGggc3VnZ2VzdGVkIGJ5IHRoZSByZW1vdGUgZW5kKS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkFnYWluLCBp ZiB0aGUgYXV0by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVyIHByb3ZpZGVzIGEgYmV0dGVyIHF1YWxp dHkgcGF0aCwgSUNFIHNob3VsZCBiZSBhYmxlIHRvIGRpc2NvdmVyIHRoYXQgcGF0aCBhbmQgdXNl IGl0IC0tIHRoYXQncyB0aGUgYmVzdCBsb25nIHRlcm0gc29sdXRpb24sIElNTy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPk11dGh1PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkthcmwgU3RhaGw8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5 IDEzLCAyMDE0IDU6MDkgUE08YnI+DQo8Yj5Ubzo8L2I+ICdKdXN0aW4gVWJlcnRpJzsgTXV0aHUg QXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk8YnI+DQo8Yj5DYzo8L2I+IHRpcmVkZHlAaWNp c2NvLmNvbTsgJ1NpbW9uIFBlcnJlYXVsdCc7ICdPbGVnIE1vc2thbGVua28nOyB0cmFtQGlldGYu b3JnOyAnTWFyYyBCbGFuY2hldCc7IERhbiBXaW5nIChkd2luZyk8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVj aGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVl Ij5KdXN0IElDRSBtYXkgcmVzdWx0IGluIHRoYXQgdGhlIHJlbW90ZSBlbmTigJlzIHByb3Bvc2Fs IG92ZXJyaWRlcyBhIHBhdGggdGhhdCBxdWFsaXR5IHdpc2UgaXMgYmV0dGVyIHRvIHVzZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhh dCBpcyB3aHkgd2UgKGFsc28pIG11c3QgYXNzdXJlIHRoYXQgYW4gYXV0by1kaXNjb3ZlcmVkIFRV Uk4gc2VydmVyIGFjdHVhbGx5IGlzIHVzZWQsIChpbnN0ZWFkIG9mIGEgcGF0aCBzdWdnZXN0ZWQg YnkgdGhlIHJlbW90ZSBlbmQpLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+L0thcmw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnLDpW46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBKdXN0aW4gVWJlcnRpIFs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29tIj5t YWlsdG86anViZXJ0aUBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNraWNrYXQ6PC9iPiBkZW4g MTIgZmVicnVhcmkgMjAxNCAxODo0Njxicj4NCjxiPlRpbGw6PC9iPiBNdXRodSBBcnVsIE1vemhp IFBlcnVtYWwgKG1wZXJ1bWFsKTxicj4NCjxiPktvcGlhOjwvYj4gT2xlZyBNb3NrYWxlbmtvOyBL YXJsIFN0YWhsOyA8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tIj50aXJlZGR5QGlj aXNjby5jb208L2E+OyBNYXJjIEJsYW5jaGV0Ow0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5v cmciPnRyYW1AaWV0Zi5vcmc8L2E+OyBEYW4gV2luZyAoZHdpbmcpOyBTaW1vbiBQZXJyZWF1bHQ8 YnI+DQo8Yj7DhG1uZTo8L2I+IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1 dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iU1Yi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJTViI+QWdyZWUuIElmIFRVUk4gaXMgaW5kZWVkIGJlaW5nIHByb3ZpZGVk IGZvciB0aGUgdXNlcidzIGJlbmVmaXQsIHRoZSBjbGllbnQncyBJQ0UgbG9naWMgKGJhc2VkIG9u IFJUVCBvciBzaW1pbGFyKSBzaG91bGQgcmVzdWx0IGluIGl0IHByZWZlcnJpbmcgdGhlIFRVUk4g cGF0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IlNWIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iU1YiPk9uIFdlZCwgRmViIDEyLCAyMDE0IGF0IDE6MjcgQU0sIE11dGh1IEFydWwg TW96aGkgUGVydW1hbCAobXBlcnVtYWwpICZsdDs8YSBocmVmPSJtYWlsdG86bXBlcnVtYWxAY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bXBlcnVtYWxAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij5ZZXMsIEkgYmVsaWV2ZSB0aGUgc2Vjb25kIGNhc2UgaXMgcmFyZSwgYnV0 IHdvdWxkIGJlIGJldHRlciB0aGFuIGEgcmF0IHJhY2UgYi93IGFkbWluaXN0cmF0b3JzIHRyeWlu ZyB0byBibG9jayBwMnAgdHJhZmZpYw0KIGFuZCBmb3JjZSBpdCB0aHJvdWdoIGEgVFVSTiBzZXJ2 ZXIgYW5kIGFwcHMvZW5kcG9pbnRzIGZpbmRpbmcgc21hcnRlciB3YXlzIHRvIGJ5cGFzcyB0aGVt Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPk11dGh1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPbGVnIE1vc2thbGVua28gW21haWx0bzo8YSBo cmVmPSJtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1vbTA0MDI2 N0BnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkg MTIsIDIwMTQgMTowNyBQTTxicj4NCjxiPlRvOjwvYj4gTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFs IChtcGVydW1hbCk8YnI+DQo8Yj5DYzo8L2I+IEp1c3RpbiBVYmVydGk7IEthcmwgU3RhaGw7IDxh IGhyZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj4NCnRpcmVk ZHlAaWNpc2NvLmNvbTwvYT47IE1hcmMgQmxhbmNoZXQ7IDxhIGhyZWY9Im1haWx0bzp0cmFtQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQp0cmFtQGlldGYub3JnPC9hPjsgRGFuIFdpbmcgKGR3 aW5nKTsgU2ltb24gUGVycmVhdWx0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBN aWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRl cnByaXNlIGFuZCBJU1BzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBUVVJOIHNlcnZlciBo YXMgdG8gYmUgdXNlZCB3aGVuIGl0IGlzIGVpdGhlciB0aGUgb25seSBvcHRpb24sIG9yIGlmIGl0 IHByb3ZpZGVzIGEgYmV0dGVyIHBhdGggKEkgZ3Vlc3MgdGhlIHNlY29uZCBjYXNlIGlzIHJhdGhl ciByYXJlKS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBGZWIg MTEsIDIwMTQgYXQgMTE6MzIgUE0sIE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwp ICZsdDs8YSBocmVmPSJtYWlsdG86bXBlcnVtYWxAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ bXBlcnVtYWxAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiYjNDM7MTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZvcmNp bmcgYWxsIHRyYWZmaWMgdGhyb3VnaCBhIFRVUk4gc2VydmVyIGFuZCBleHBlY3RpbmcgaXQgd291 bGQgcHJvdmlkZSB0aGUgYmVzdCB1c2VyIGV4cGVyaWVuY2UgZG9lc24ndCBsb29rIHRoZSByaWdo dA0KIGFwcHJvYWNoLiBJbnN0ZWFkLCBpZiBhIHBhdGggdGhyb3VnaCBhIFRVUk4gc2VydmVyIGV4 aXN0cyBhbmQgZG9lcyBwcm92aWRlIGxvd2VyIFJUVCwgaml0dGVyIGV0YywgYmVpbmcgYWJsZSB0 byBkZXRlY3QgYW5kIHVzZSAob3Igc3dpdGNoIHRvKSB0aGF0IHBhdGggbWlnaHQgYmUgZGVzaXJh YmxlLi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5NdXRodTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0KPGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQgMTE6NDMgQU08YnI+DQo8Yj5U bzo8L2I+IEthcmwgU3RhaGw8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzp0aXJlZGR5 QGljaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj50aXJlZGR5QGljaXNjby5jb208L2E+OyBNYXJj IEJsYW5jaGV0Ow0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij50cmFtQGlldGYub3JnPC9hPjsgRGFuIFdpbmcgKGR3aW5nKTsgU2ltb24gUGVycmVhdWx0PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1 dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5JbmxpbmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u IFR1ZSwgRmViIDExLCAyMDE0IGF0IDI6MzcgUE0sIEthcmwgU3RhaGwgJmx0OzxhIGhyZWY9Im1h aWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlIiB0YXJnZXQ9Il9ibGFuayI+a2FybC5zdGFobEBp bnRlcnRleC5zZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1 ZSI+TGlzdGVuaW5nIHRvIHRoaXMgdGhyZWFkLCBJIGFtIGFmcmFpZCB3ZSBhcmUgbWlzc2luZyB0 aGUgdmVyeSBwb2ludCBhbmQgbmVjZXNzaXR5IGZvciB0aGlzIG1pbGVzdG9uZSE8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+LSBUaGVyZSBhcmUgc2V2ZXJlIE5BVCB0cmF2ZXJzYWwgYW5kIHF1 YWxpdHkgaXNzdWVzIHRoYXQgc2hvdWxkIGFuZCBjYW4gYmUgZGVhbHQgd2l0aCBieSBhIGdvb2Qg YXV0by1kaXNjb3ZlcnkNCiBtZWNoYW5pc20gYW5kIHRoZSByaWdodCB1c2FnZSBieSB0aGUgdHVy biBjbGllbnQgKHRoZSBXZWJSVEMgYnJvd3Nlcik8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlRoZXJlIGFyZSB3YXlzLCBub3Qgb25s eToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+RW50ZXJwcmlzZXMgb3IgSVNQcyB3aXNoaW5nIHRvIHByb3Zp ZGUgdGhlaXIgb3duIFRVUk4gc2VydmVyLCBpbiBhbiBhdHRlbXB0IHRvIHJlZHVjZSBzby1jYWxs ZWQgJnF1b3Q7dHJpYW5nbGUgcm91dGluZyZxdW90OyxuZWVkIGEgbmV3IGF1dG8tZGlzY292ZXJ5 IG1lY2hhbmlzbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5CdXQgYWxzbzogLSBOU1BzIChO ZXR3b3JrIFNlcnZpY2UgUHJvdmlkZXJzKSB3YW50IHRvIHByb3ZpZGUgYSBwYXRoIHdoZXJlIHRo ZSBiYW5kd2lkdGggb2YgV2ViUlRDIGlzIGJldHRlcg0KIGNvcGVkIHdpdGguPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIE5TUHMgb3IgRW50ZXJwcmlzZXMgd2FudCB0byBvZmZl ciBhbiBJbnRlcm5ldCBhY2Nlc3MgcXVhbGl0eSBwaXBlIGZvciBwcmlvcml0aXplZCBSVEMgKFJl YWwgVGltZSBDb21tdW5pY2F0aW9uKQ0KIHRyYWZmaWMuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj4tIEVudGVycHJpc2VzIGhhdmluZyByZXN0cmljdGl2ZSBmaXJld2FsbHMsIHdhbnQgdG8g cHJvdmlkZSBhIFVEUC1wYXRoIGZvciBXZWJSVEMgYW5kIHBvc3NpYmx5IGFsc28gZm9yDQogYmV0 dGVyIHF1YWxpdHkgd2hlcmUgUlRDIGRvIG5vdCBjb21wZXRlIHdpdGggZGF0YSB0cmFmZmljLiA8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5BbHNvIGNvbnNpZGVyaW5nPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIE1vYmlsaXR5OyBJdCBpcyBjb21tb24gdG8g bW92ZSBmcm9tIGEgTEFOIHRvIGFjY2Vzc2luZyB2aWEgV2lGaSBvciAzRy80RyBPVFQgY2hhbm5l bHMsIGFsbCBzaG91bGQgYmUNCiBhYmxlIHRvIGF1dG9tYXRpY2FsbHkgb2ZmZXIgdGhlaXIgb3du IG9wdGltYWwgVFVSTiBzZXJ2ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhpcyBsZWFkcyB1cyBpbnRvDQo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A74oCcVFVSTuKApnRvIGlkZW50 aWZ5IFdlYlJUQyBmbG93c+KAnQ0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPmV0YyEgSXQgaXMg bm90IGEgbWlzdGFrZSwgYnV0IHRoZSB2ZXJ5IG5lZWQgZm9yIHRoaXMgbWlsZXN0b25lITwvc3Bh bj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkFnYWluLCBpdCBoYXMgbm90IGJlZW4gZGVtb25zdHJhdGVkIHdo eSBUVVJOIGlzIHRoZSByaWdodCB0ZWNobm9sb2d5IGhlcmUsIGNvbXBhcmVkIHRvIGEgbW9yZSB0 cmFuc3BhcmVudCBmbG93IGlkZW50aWZpY2F0aW9uIHRvb2wgbGlrZSBNQUxJQ0UuIFdlIGRvbid0 IGZvcmNlIGFsbCBIVFRQIHJlcXVlc3RzDQogdG8gbG9jYXRlIGEgSFRUUCBwcm94eSB2aWEgYW55 Y2FzdCwgSSBkb24ndCBzZWUgd2h5IHdlIG5lZWQgdG8gZG8gdGhlIHNhbWUgZm9yIFdlYlJUQy4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+V2hhdCBhcmUgdGhlIGhlc2l0YXRpb25zIHJhaXNlZCBoZXJlPzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgVFVSTiBwcmltYXJpbHkgdG8gaWRlbnRpZnkg V2ViUlRDIGZsb3dzLCBhcyBvcHBvc2VkIHRvIHVzaW5nIGl0IGFzIGEgTkFUIHRyYXZlcnNhbCB0 b29sLiBUaGlzIG1ha2VzIG1lIGNvbmNlcm5lZA0KIHRoYXQgd2UgbWF5IGJlIHVzaW5nIHRoZSB3 cm9uZyB0ZWNobm9sb2d5IHRvIHNvbHZlIHRoZSBwcm9ibGVtPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6Ymx1ZSI+SXQgaXMgY29ycmVjdCB0aGF0IElDRS9TVFVOL1RVUk4gd2FzIGRlc2ln bmVkIHRvIGFkZHJlc3MgdGhlIE5BVC9GaXJld2FsbCB0cmF2ZXJzYWwgcHJvYmxlbSBhc3NvY2lh dGVkDQogd2l0aCByZWFsLXRpbWUgY29tbXVuaWNhdGlvbiAoU0lQIGF0IHRoYXQgdGltZSkuIEhv d2V2ZXIsIGl0cyBsYXJnZXN0IGZsYXcvcHJvYmxlbSBpcyB0aGF0IHF1YWxpdHkgdGhpbmdzIHdl cmUgbm90IChjb3VsZCBub3QgYmU/KSBjb25zaWRlcmVkLiBUaGUgbWV0aG9k4oCZcyB2ZXJ5IGlk ZWEgKGxpa2UgYWxsIHNpbWlsYXIgbWV0aG9kcyBmb3IgZ2V0dGluZyBSVEMgdGhyb3VnaCBvcmRp bmFyeSBOQVQvRmlyZXdhbGxzKSBpcyB0byBmb29sIHRoZSBtZWRpYQ0KIHRocm91Z2ggYSBOQVQv RmlyZXdhbGwgdGhhdCBpcyB1bmF3YXJlIG9mIHdoYXQgaXMgaGFwcGVuaW5nLiBUaHVzLCB0aGlz IGlzIHJvb3Qgb2YgcXVhbGl0eSBpc3N1ZXMgKGFuZCBiYW5kd2lkdGggYWxsb2NhdGlvbiBvcHRp bWl6YXRpb24pIHRoYXQgbmVlZHMgdG8gYmUgZGVhbHQgd2l0aDogUmVhbC10aW1lIHRyYWZmaWMg ZmlnaHRpbmcgd2l0aCBhIGRhdGEgdHJhZmZpYyBjcm93ZGVkIGNvbmdlc3Rpb24gcG9pbnQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRoaW5rIHRoYXQgJnF1b3Q7Zm9vbGluZyZx dW90OyBpcyBhbiBpbmNvcnJlY3QgZGVzY3JpcHRpb24uIFRoZSBOQVQgaXMgc3VwcG9zZWQgdG8g YmUgdHJhbnNwYXJlbnQgdG8gdGhlIGNsaWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+QnV0LCBhIEJMRVNTSU5H IG9mIElDRS9TVFVOL1RVUk4gaXMgdGhhdCBpdCBjYW4gYmUgc2VlbiBhcyBhIGxlZ2l0aW1hdGUg cmVxdWVzdCBmb3IgYSBzdWl0YWJsZSBwaXBlIGZvcg0KIHF1YWxpdHkgZGVtYW5kaW5nIHJlYWwg dGltZSB0cmFmZmljLiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6V2luZ2RpbmdzO2NvbG9yOmJsdWUiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibHVlIj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JQ0UgaXMgYSBw cmUtcHJvdG9jb2wgeW91IHVzZSBiZWNhdXNlIHlvdSB3YW50IGEgcGF0aCBmb3IgcmVhbC10aW1l IG1lZGlhIGJldHdlZW4gcGFydGllcy4gSGVyZTogVGhlIGJyb3dzZXINCiBzYXlzIGtub2NrIGtu b2NrLCBJIHdhbnQgdG8gZ2V0IG1lZGlhIHRocm91Z2ggKGFuZCBvZiBjb3Vyc2Ugd2l0aCBhcyBn b29kIHF1YWxpdHkgYXMgcmVxdWlyZWQgYW5kIHBvc3NpYmxlKS4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SWYgdGhlIE5BVC9G aXJld2FsbCBvd25lciBhbmQgbmV0d29yayBvd25lciBhcmUgYWxsb3dlZCB0byBzZWUgdGhlc2Ug cmVxdWVzdHMsIHRoZXkgY2FuIGhlbHAvYXNzaXN0IGluDQogYWNoaWV2aW5nIHRoZSBnb29kIG1l ZGlhIHBhdGguIElmIHRoZXkgYXJlIG5vdCBhd2FyZSwgdGhleSBjYW5ub3QgaGVscCE8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVl Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SG9wZSB0aGlzIG1hZGUgaXQgdW5k ZXJzdGFuZGFibGUgb24gYW4gb3ZlcnZpZXcgbGV2ZWwgaG93IHRoaXMgY2FuIGJlY29tZTwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiDigJxUVVJO4oCmdG8gaWRlbnRpZnkg V2ViUlRDIGZsb3dz4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkl0IGlzIGFsc28gdGhl IE9OTFkgd2F5IEkgY2FuIHNlZSB0byBhY2hpZXZlIHdoYXQgd2Ugd2FudCB0byBhY2hpZXZlIGFu ZCBzaG91bGQgYmUgdGhlIGFpbSBhbmQgcmVxdWlyZW1lbnQNCiBvZiB0aGlzIG1pbGVzdG9uZS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPkkgYW0gdGFsa2luZyBhYm91dCBnZW5lcmFsIHVzYWdlIG9mIFdlYlJUQyBvdmVyIEludGVy bmV0L21vYmlsZSBPVFQgKG5vdCBmZWVkaW5nIFdlYlJUQyBpbnRvIGFwcGxpY2F0aW9uDQogc3Bl Y2lmaWMgbmV0d29ya3MgbGlrZSBJTVMgd2hlcmUgb3RoZXIgbWV0aG9kcyBtYXkgZXhpc3QpLiA8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPlRoaXMgaXMgZ29vZCwgbm90IGV2aWwhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JZiB0aGUgaGVzaXRhdGlvbnMgYXJlIHJh aXNlZCBiZWNhdXNlIG9mIGEgYmVsaWVmL2hvcGUvd2lzaCB0aGF0IHRoZXJlIGFyZSBubyBvciB3 aWxsIG5vdCBiZSBzZXZlcmUgcXVhbGl0eQ0KIGlzc3VlcyDigJxiZWNhdXNlIGl0IGlzIGFsbCBh Ym91dCBiYW5kd2lkdGjigJ0sIOKAnGl0IHdpbGwgcmVzb2x2ZSBpdHNlbGYgd2l0aCB0aW1l4oCd IGV0Yy4sIEkgc3Ryb25nbHkgb2JqZWN0ISBUaGF0IGlzIHdyb25nIGFuZCB3aWxsIGJlIHZlcnkg ZGV0cmltZW50YWwgZm9yIFdlYlJUQyB1c2FnZS4gV2UgYWxyZWFkeSBzZWUgaXQgYW5kIEkgY2Fu IGdpdmUgbnVtZXJvdXMgZXhhbXBsZXMgb2YgaG93IG11Y2ggbGVzcyBxdWFsaXR5IGRlbWFuZGlu ZyBWb0lQDQogaXMvaXMgbm90IGhhbmRsZWQgcXVhbGl0eSB3aXNlIGFuZCB0aGF0IGl0IG1hdHRl cnMuIEFuZCwgd2hhdCB3b3VsZCBiZSBiYWQgY29uc2lkZXJpbmcgcXVhbGl0eSBpc3N1ZXMgYW5k IGFsbG93aW5nL2VuY291cmFnaW5nIG1ldGhvZHMgdG8gZGVhbCB3aXRoIHRoZW0/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPklmIHRoZSBoZXNpdGF0aW9ucyBhcmUg cmFpc2VkLCBiZWNhdXNlIG9mIHN1c3BpY2lvbiB0aGF0IHRoZSBtZXRob2RzIHdlIG1heSByZWNv bW1lbmQgbWF5IGJlIG1pc3VzZWQgdG8NCiBzdG9wL2Jsb2NrL2Rlc3Ryb3kgV2ViUlRDIHVzYWdl IChlLmcuIHRvIHByb3RlY3QgaW5jb21lIGZyb20gY2FycmllciB0ZWxlcGhvbnkgdHJhZmZpYyks IEkgY291bGQgdW5kZXJzdGFuZCBhbmQgd291bGQgZmlnaHQgdGhlIHNhbWUgYmF0dGxlLiBCdXQg aG9wZWZ1bGx5LCB0aG9zZSBkYXlzIGFyZSAoc29vbikgb3ZlciDigJMgQXQgbGVhc3QgZm9yd2Fy ZCB0aGlua2luZyBjYXJyaWVy4oCZcyByZWFsaXplIHRoYXQgYWxyZWFkeS4gV2ViIFJUQyB3aWxs DQogaGFwcGVuLiBXaGljaCBjdXN0b21lcnMgd2FudCB0byBwYXkgZm9yIGFuIGFjY2VzcyB3aXRo IGJsb2NrZWQgV2ViUlRDPyBUaGUgY2FycmllcuKAmXMgb2ZmZXJpbmcvYXNzdXJpbmcgZ29vZCBX ZWJSVEMgd2lsbCByYXRoZXIgZ2V0IHRoZSBjdXN0b21lcnMgYW5kIGluY29tZQ0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjpi bHVlIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LiAoTWF5 YmUgdGhlIFdlYiBicm93c2VyIGNhbiBkZXRlY3QgYW5kIGVuY291cmFnZSB0aGlz4oCmKTwvc3Bh bj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPklmIHRoZXJlIGFyZSB0ZWNobmljYWwgY29uY2VybnMgb2YgYmFkIHJlc3VsdCwg b3IgYmV0dGVyIG1ldGhvZHMgYWxsb3dpbmcgbmV0d29yayBwcm92aWRlcnMgYW5kIExBTiBtYW5h Z2Vycw0KIHRvIG9mZmVyIGFuZCBpbmZvcm0gdGhlIGJyb3dzZXIgdGhhdCB0aGVyZSBhcmUgZ29v ZCBtZWRpYSBwYXRocyB0byBiZSB1c2VkLCBhbmQgdGhhdCB0aGUgd2ViIGJyb3dzZXIgYXV0b21h dGljYWxseSBjYW4gY2hvc2UgdGhvc2UsIHRoZW4gbGV0IHVzIGFsbCB1bmRlcnN0YW5kIHRob3Nl LCBzbyB3ZSBjYW4gYWNoaWV2ZSB3aGF0IHNob3VsZCBiZSBhY2hpZXZlZCBieSB0aGlzIG1pbGVz dG9uZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNreXBlLCBIYW5nb3V0cywgRmFj ZXRpbWUgYXJlIGRvaW5nIGJpbGxpb25zIG9mIG1pbnV0ZXMgcGVyIHdlZWsgYW5kIHRoZSBJbnRl cm5ldCBoYXMgbm90IG1lbHRlZCB5ZXQuIElmIHdlIG5lZWQgdG8gZG8gZmxvdyBpZGVudGlmaWNh dGlvbiB0byBhbGxvdyB0cmFmZmljIHRvIGJlIHByaW9yaXRpemVkLCBmaW5lDQogKHNlZSBhYm92 ZSByZWdhcmRpbmcgbXkgcHJlZmVycmVkIGFwcHJvYWNoKSwgYnV0IGZvcmNpbmcgYWxsIFdlYlJU QyB0cmFmZmljIHRocm91Z2ggYSBNSVRNIChUVVJOIHNlcnZlcikgaXMgYSBtdWNoIGJpZ2dlciBq dW1wIHRoYXQgSSBkb24ndCB5ZXQgc2VlIHRoZSBqdXN0aWZpY2F0aW9uIGZvci48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIHNob3J0 OiBUVVJOIGlzIGEgdGVjaG5vbG9neSB0aGF0IGlzIHN1cHBvc2VkIHRvIGZhZGUgYXdheSB3aXRo IHRoZSBtb3ZlIHRvIElQdjYuIEkgZG9uJ3QgdGhpbmsgd2Ugd2FudCB0byBtYWtlIGl0IGEgY3Jp dGljYWwgZWxlbWVudCBvZiBXZWJSVEMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1 ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi9LYXJsPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnLDpW46 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERhbiBXaW5nIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOmR3aW5nQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR3aW5nQGNp c2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5Ta2lja2F0OjwvYj4gZGVuIDExIGZlYnJ1YXJpIDIwMTQg MTg6MjU8YnI+DQo8Yj5UaWxsOjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+TWFyYyBCbGFuY2hldDxicj4NCjxiPktvcGlhOjwvYj4gSnVzdGluIFViZXJ0 aTsgPGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0K dGlyZWRkeUBpY2lzY28uY29tPC9hPjsgS2FybCBTdGFobDsgPGEgaHJlZj0ibWFpbHRvOnRyYW1A aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnRyYW1AaWV0Zi5vcmc8L2E+OyBTaW1vbiBQZXJy ZWF1bHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPjxicj4NCjxiPsOEbW5lOjwvYj4gUmU6IFt0cmFtXSBN aWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRl cnByaXNlIGFuZCBJU1BzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+T24gRmViIDEx LCAyMDE0LCBhdCA5OjA4IEFNLCBNYXJjIEJsYW5jaGV0ICZsdDs8YSBocmVmPSJtYWlsdG86bWFy Yy5ibGFuY2hldEB2aWFnZW5pZS5jYSIgdGFyZ2V0PSJfYmxhbmsiPm1hcmMuYmxhbmNoZXRAdmlh Z2VuaWUuY2E8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5MZSAyMDE0 LTAyLTExIMOgIDAwOjM5LCBEYW4gV2luZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmR3aW5nQGNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmR3aW5nQGNpc2NvLmNvbTwvYT4mZ3Q7IGEgw6ljcml0IDo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n PSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 YnI+DQpPbiBGZWIgMTAsIDIwMTQsIGF0IDU6MzAgUE0sIEp1c3RpbiBVYmVydGkgJmx0OzxhIGhy ZWY9Im1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWJlcnRpQGdv b2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Hb29kIHRvIHNlZSB0aGVyZSBpcyBhIGxvdCBvZiBpbnRlcmVzdCBm b3IgdGhpcyBtaWxlc3RvbmUuIEJ1dCBiYXNlZCBvbiB0aGUgZGVzY3JpcHRpb24gaGVyZSwgaXQg c2VlbXMNCiBsaWtlIHdlIHdhbnQgdG8gdXNlIFRVUk4gcHJpbWFyaWx5IHRvIGlkZW50aWZ5IFdl YlJUQyBmbG93cywgYXMgb3Bwb3NlZCB0byB1c2luZyBpdCBhcyBhIE5BVCB0cmF2ZXJzYWwgdG9v bC4gVGhpcyBtYWtlcyBtZSBjb25jZXJuZWQgdGhhdCB3ZSBtYXkgYmUgdXNpbmcgdGhlIHdyb25n IHRlY2hub2xvZ3kgdG8gc29sdmUgdGhlIHByb2JsZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+JiM0MzsxLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkkgd291bGQgcHJlZmVyIGFsbG93aW5nIGZsb3dzIHRvIGVzdGFibGlzaCB0aGVtc2VsdmVz IHVzaW5nIHRoZWlyICdiZXN0JyBwYXRoLCBhbmQgdGhlIGJlc3QgcGF0aCBpcw0KIHNlbGRvbSB0 aHJvdWdoIGEgVFVSTiBzZXJ2ZXIuICZuYnNwO1doZW4gd2UgaW1hZ2luZSBJUHY2IGluIG91ciBm dXR1cmUsIHdlIGRvbid0IHdhbnQgdG8gZm9yY2UgYW4gYXBwbGljYXRpb24tbGV2ZWwgcHJveHkg KFRVUk4pIHNlcnZlciBvbiB0aGUgcGF0aCBzb2xlbHkgZm9yIHRyYXZlcnNpbmcgYW4gSVB2NiBm aXJld2FsbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JdCBzZWVtcyB0aGlzIHRo cmVhZCBpcyBjb25mbGF0aW5nIGFsbCB0aGUgcG9zc2libGUgcmVhc29ucyAvIGp1c3RpZmljYXRp b25zIGZvciBUVVJOOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOyAqIG1vYmlsaXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7ICogTkFUIHRyYXZlcnNhbCAoYm90aCBlbmRwb2ludHMgYXJlIGJlaGluZCBl bmRwb2ludC1kZXBlbmRlbnQgbWFwcGluZyBOQVRzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAqJm5ic3A7ZmlyZXdhbGwgdHJhdmVyc2FsIChmaXJl d2FsbCBibG9ja3MgVURQKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOyAqIGVuaGFuY2luZyBwcml2YWN5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+VW5mb3J0dW5hdGVseSB0aGUgVFVSTiBzZXJ2ZXIgbm9yIHRoZSBlbmRwb2lu dCByZWFsbHkga25vdyB3aGljaCBvZiB0aG9zZSB1c2UtY2FzZXMgaXMgZGVzaXJlZCAoYnkgdGhl DQogdXNlciBvciBieSB0aGUgSVQgbmV0d29yayBhZG1pbmlzdHJhdG9yKSBvciBuZWNlc3Nhcnkg KGZvciB0aGUgY2FsbCB0byB3b3JrIGF0IGFsbCkuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i U1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPkRhbiwgd2hpbGUgSSBhZ3JlZSBpbiBwcmlu Y2lwbGUsIEkgZG91YnQgdGhhdCBhIHVzZXIgY291bGQgZXZlciBzYXkgJnF1b3Q7SSB3YW50IG1v YmlsaXR5IG9yIEkgd2FudCBOQVQgdHJhdmVyc2FsJnF1b3Q7LiBJIHRoaW5rIHRoZSB1c2VyIG9u bHkgd2FudCB0aGUgY2FsbCB0byBzdWNjZWVkLCB3aGF0ZXZlcg0KIHRoZSBwcm9wZXJ0aWVzIG9m IGl0cyBuZXR3b3JrIHBvaW50IG9mIGF0dGFjaG1lbnQgYXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5TbyB3aGF0IGNhbiB3 ZSBkbz8gJm5ic3A7U2hvdWxkIHRoZSBUVVJOIHNlcnZlciBwcm92aWRlIGFueSBhbmQgYWxsIHNl cnZpY2VzIHRoZSBUVVJOIGNsaWVudCBtaWdodCBwb3NzaWJseSB3YW50LCBhcyB0aGF0IGlzIHdo YXQgYSByb2J1c3QgVFVSTiBzZXJ2ZXIgd2lsbCBkbywgYW5kIHRoZQ0KIGVuZHBvaW50IHNob3Vs ZCBwcmVmZXIgVFVSTiBjYW5kaWRhdGVzIG92ZXIgYWxsIG90aGVycyBiZWNhdXNlIHRoZXJlIG1p Z2h0IGJlIHNvbWUgZnVuY3Rpb25hbGl0eSAvIHVzZWZ1bG5lc3Mgb2YgVFVSTiB0aGF0IHRoZSB1 c2VyIG1pZ2h0IGdhaW4gdGhyb3VnaCBUVVJOIChlLmcuLCBlbmhhbmNlZCBwcml2YWN5KT88L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4tZDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7VGhpcyBzZWVtcyBwcm9ibGVtYXRpYy4gJm5ic3A7UGVyaGFwcyB3ZSBuZWVkIGEg d2F5IHRvIHNpZ25hbCB0aGUgZGVzaXJlZCB1c2UtY2FzZSAoJnF1b3Q7dHJhaXQmcXVvdDspLCBv ciBhcyBKdXN0aW4NCiBzdWdnZXN0cywgdXNpbmcgYSBkaWZmZXJlbnQgdGVjaG5vbG9neSBmb3Ig c29tZSBvZiB0aGVzZSB1c2UtY2FzZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+LWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i U1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gTW9uLCBGZWIgMTAsIDIwMTQgYXQgMzoxOCBQ TSwgS2FybCBTdGFobCZuYnNwOyZsdDs8YSBocmVmPSJtYWlsdG86a2FybC5zdGFobEBpbnRlcnRl eC5zZSIgdGFyZ2V0PSJfYmxhbmsiPmthcmwuc3RhaGxAaW50ZXJ0ZXguc2U8L2E+Jmd0OyZuYnNw O3dyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNpbW9uLDxicj4NCjxicj4NCkdv b2QgcXVlc3Rpb25zIC0gc2VlIGlubGluZSBiZWxvdyAtLSZndDsgLjxicj4NClNvbWUgbW9yZSB0 aG91Z2h0IGlzIHJlcXVpcmVkITxicj4NCjxicj4NCi9LYXJsPGJyPg0KPGJyPg0KLS0tLS1VcnNw cnVuZ2xpZ3QgbWVkZGVsYW5kZS0tLS0tPGJyPg0KRnLDpW46IHRyYW0gW21haWx0bzo8YSBocmVm PSJtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbS1ib3Vu Y2VzQGlldGYub3JnPC9hPl0gRsO2ciBTaW1vbiBQZXJyZWF1bHQ8YnI+DQpTa2lja2F0OiBkZW4g MTAgZmVicnVhcmkgMjAxNCAxNToxNjxicj4NClRpbGw6IEthcmwgU3RhaGw7Jm5ic3A7PGEgaHJl Zj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFtQGlldGYub3JnPC9h PjsmbmJzcDs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFu ayI+dGlyZWRkeUBpY2lzY28uY29tPC9hPjxicj4NCsOEbW5lOiBSZTogW3RyYW1dIE1pbGVzdG9u ZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2Ug YW5kIElTUHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KS2FybCw8YnI+DQo8 YnI+DQpJdCBpcyBncmVhdCB0byBzZWUgc3VjaCBlbnRodXNpYXNtISBUaGFua3MhPGJyPg0KPGJy Pg0KSSBoYXZlIGEgY291cGxlIHRlY2huaWNhbCBxdWVzdGlvbnMuLi48YnI+DQo8YnI+DQpMZSAy MDE0LTAyLTA4IDA4OjExLCBLYXJsIFN0YWhsIGEgw6ljcml0IDo8YnI+DQomZ3Q7IC0gTm90ZSB0 aGF0IHRvIGFjaGlldmUgc29tZSBvZiB0aGUgYWJvdmUgcG9pbnRzLCBUVVJOIG11c3QgYmUgZmF2 b3JlZDxicj4NCiZndDsgb3ZlciBTVFVOIHRvIGVuZm9yY2UgdGhhdCB0aGUgVFVSTi1wYXRoIGFj dHVhbGx5IGlzIHVzZWQuIChUaGUgQW55Y2FzdDxicj4NCiZndDsgbWV0aG9kIHN1Z2dlc3RlZCBi ZWxvdywg4oCcYXV0b21hdGljYWxseeKAnSBkb2VzIHRoaXMuKTxicj4NCjxicj4NCkkgdW5kZXJz dGFuZCB0aGUgU1RVTiB2cyBUVVJOIHByaW9yaXR5IGlzc3VlLiBCdXQgSSBkb24ndCBzZWUgaG93 IGFueWNhc3QgYWZmZWN0cyBpdCBpbiBhbnkgd2F5LiBDYW4geW91IHBsZWFzZSBleHBsYWluPzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS0tIEdvb2QgcG9pbnQgLSBJIHdh cyBhIGJpdCBxdWljayBoZXJlIChtYXliZSB0b28gcXVpY2spPGJyPg0KV2UgaGF2ZSBnaXZlbiB0 aGlzIHF1aXRlIGJpdCBvZiB0aG91Z2h0LCBzaW5jZSBldmVuIGlmIGEgVFVSTiBzZXJ2ZXIgaXMg cHJvdmlkZWQgYW5kIGRpc2NvdmVyZWQsIENVUlJFTlQgdXNhZ2Ugb2YgSUNFIG1heSBzdWdnZXN0 IGEgY2FuZGlkYXRlIGZyb20gdGhlIHJlbW90ZSBwYXJ0eSB0aGF0IHdpbGwgbWFrZSBhIGNvbm5l Y3Rpb24gd2l0aG91dCB0aGUgbmVlZC91c2FnZSBvZiB0aGUgVFVSTiBzZXJ2ZXIgKHRoYXQgd2Ug d2FudGVkIHRvIGJlIHVzZWQNCiBmb3IgdGhlIGdvb2QgcHVycG9zZXMgbGlzdGVkKS48YnI+DQo8 YnI+DQpUaGUgb25seSB3YXkgd2UgZm91bmQgYXJvdW5kIHRoaXMsIHdhcyB0byBzdG9wIFNUVU4g dGhyb3VnaCB0aGUgSVAgZGVmYXVsdCBnYXRld2F5IChsaWtlIGEgcmVzdHJpY3RpdmUgRW50ZXJw cmlzZSBmaXJld2FsbCBkb2VzIGluaGliaXRpbmcgSUNFIGNvbm5lY3Rpdml0eSwgd2hpY2ggb3Ro ZXJzIGFyZSBjb25jZXJuZWQgYWJvdXQuLi4pLiBTaW5jZSB0aGUgcHJvdmlzaW9uaW5nIG9mIGF1 dG8tZGlzY292ZXJ5IHVzaW5nIHRoZSBhbnljYXN0IG1lY2hhbmlzbSwNCiB3b3VsZCBiZSBhZGRp bmcgYSByb3V0ZSBpbiBhIGRlZmF1bHQgZ2F0ZXdheSwgYWRkaW5nIGEgZmlyZXdhbGwgcnVsZSB0 byBlYXQgU1RVTiBwYWNrZXRzIHdvdWxkIGFzc3VyZSB0aGF0IHRoZSBwcm92aXNpb25lZCBUVVJO IHNlcnZlciBhY3R1YWxseSBiZWNvbWVzIHVzZWQgKGFuZCBub3QgYnlwYXNzZWQgJnF1b3Q7Ynkg YWNjaWRlbnQmcXVvdDspLiAoVGhhdCB3YXMgdGhlIHRob3VnaHQgYmVoaW5kIHRoZSDigJxhdXRv bWF0aWNhbGx54oCdIHdpdGhpbiBxdW90ZXMuKTxicj4NCjxicj4NCkJVVCwgc2luY2UgeW91IGJy b3VnaHQgdXAgdGhlIHF1ZXN0aW9uLCBhc3N1bWluZyB0aGF0IHdlIGhhdmUgdGhlIHBvd2VyIHRv IGVuZm9yY2UgV2ViUlRDIHVzYWdlIG9mIElDRSwgSSBiZWxpZXZlIGEgTVVTVCByZXF1aXJlbWVu dCB0byB1c2UgYW4gYXV0by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVyIGluc3RlYWQgb2YgU1RVTiwg d291bGQgc29sdmUgdGhlIHNhbWUgcHJvYmxlbS4gSG93ZXZlciwgdGhpbmtpbmcgZnVydGhlciAo aW4gcmVsYXRpb24NCiB0byB5b3VyIG5leHQgcXVlc3Rpb24gLSAmcXVvdDthbnlvbmUgY291bGQg c2V0IHVwIGEgYmFkbHktbWFpbnRhaW5lZCZxdW90OyAtIGVuZm9yY2luZyBzdWNoIElDRSB1c2Fn ZSBtYXkgbm90IGJlIGdvb2QuKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8 YnI+DQomZ3Q7IC0gM15yZCBUaGUgQW55Y2FzdCBtZXRob2QgYmVsb3cg4oCTIEkgc2VlIG5vIHBy b2JsZW08YnI+DQomZ3Q7PGJyPg0KJmd0OyBJdCBhbHNvIGhhcyB0aGUgYWR2YW50YWdlIG9mIGVu Y291cmFnaW5nIChidXQgbm90IHJlcXVpcmluZykgdGhlPGJyPg0KJmd0OyBTVFVOL1RVUk4gdG8g YmUgYnVpbHQgaW4gdGhlIGRlZmF1bHQgZ2F0ZXdheSBvciBOQVQvZmlyZXdhbGwvYWNjZXNzPGJy Pg0KJmd0OyByb3V0ZXIgaXRzZWxmLCB3aXRoIGEgc2Vjb25kIGludGVyZmFjZSB0byBhIHB1Ymxp YyBJUCBhZGRyZXNzIG9uIHRoZTxicj4NCiZndDsgV0FOIHNpZGUuIChDdXJyZW50IHZvbHVtZSBk ZXBsb3llZCwgbG93IGNvc3QgTlNQIHRyaXBsZSBwbGF5IG1vZGVtczxicj4NCiZndDsgdXN1YWxs eSBoYXZlIGEgcXVhbGl0eSBhc3N1cmVkIGxldmVsIDIgb3IgbGV2ZWwgMyBXQU4gcGlwZSBmb3Ig anVzdDxicj4NCiZndDsgdm9pY2UgKGFuZCBhbm90aGVyIGZvciBJUFRWKSDigJMgVGhlIGFueWNh c3QgZGlzY292ZXJlZCBUVVJOLXNlcnZlciBjYW48YnI+DQomZ3Q7IGJlIHRoZSBhY2Nlc3MgZ2F0 ZXdheSB0byBzdWNoIHF1YWxpdHkgcGlwZSBmb3IgV2ViUlRDIG1lZGlhLCBpbiBhPGJyPg0KJmd0 OyBzaW5nbGUgTlNQIHByb3ZpZGVkIENQRSwgc2NhbGluZyBmcm9tIHJlc2lkZW50aWFsIGFuZCB1 cC4pPGJyPg0KPGJyPg0KU3VwcG9zZSB3ZSBkZWZpbmUgd2VsbC1rbm93biBhbnljYXN0IFRVUk4g c2VydmVyIGFkZHJlc3Nlcy4gSG93IHdvdWxkIHRoaXMgbm90IGJlIHN1YmplY3QgdG8gdGhlIHNh bWUgc2VydmljZSBxdWFsaXR5IGlzc3VlcyB0aGF0IHBsYWd1ZWQgNnRvND8gVGhhdCBpcywgYW55 b25lIGNvdWxkIHNldCB1cCBhIGJhZGx5LW1haW50YWluZWQsIHVuZGVyLXByb3Zpc2lvbmVkIFRV Uk4gc2VydmVyIGFuZCBhbm5vdW5jZSBpdCBvdmVyIEJHUCB0byB0aGUgd29ybGQsDQogYXMgaXQg d2FzIGRvbmUgZm9yPGJyPg0KNnRvNCByZWxheXMuIE9yIGp1c3QgYmFkIEJHUCBvdXRib3VuZCBm aWx0ZXIgY29uZmlndXJhdGlvbi4gQW5kIGhvdyBjYW4gd2UgcHJldmVudCB0cmlhbmdsZSByb3V0 aW5nPyBUaGVyZSBpcyBub3RoaW5nIGd1YXJhbnRlZWluZyB0aGF0IHRoZSBhbnljYXN0IHNlcnZl ciB5b3Ugc2VlIGlzIGJlaW5nIHByb3ZpZGVkIHRvIHlvdSBieSB5b3VyIElTUCwgcmF0aGVyIHRo YW4gYSBzZXJ2ZXIgc2l0dGluZyBvbiB0aGUgb3RoZXIgc2lkZSBvZiB0aGUgcGxhbmV0Ljwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS0tIEdvb2QgcG9pbnQgLSBuZWVkcyB0 byBiZSByZXNvbHZlZC4gRm9yIHRoaXMgSSBkb24ndCBoYXZlIGEgcmVhZHkgYW5zd2VyLi4uPGJy Pg0KQW4gYXV0by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVyIG11c3QgYmUgdHJ1c3RlZCAod2hhdGV2 ZXIgbWV0aG9kIGl0IGlzIGRpc2NvdmVyZWQgYnkpLiBXZSBhcmUgdHJ1c3RpbmcgdGhlIG9uZSBw cm92aWRpbmcgdXMgd2l0aCBhbiBJUCBhZGRyZXNzIGFuZCBkZWZhdWx0IGdhdGV3YXkgYW55d2F5 LiBJdCB3b3VsZCBiZSBlYXN5IGlmIHdlIGNvdWxkIHJldXNlIHRoYXQgdHJ1c3QsIGluc3RlYWQg b2YgYW5vdGhlciBtZWNoYW5pc21zLjxicj4NCjxicj4NCklzIHRoZXJlIGEgZ29vZCB3YXkgZm9y IHRoZSBicm93c2VyIHRvIGNoZWNrIHRoYXQgdGhlIGFueWNhc3QgYWRkcmVzcyBpcyBub3QgaGFu ZGxlZCBiZXlvbmQgdGhlIG5ldHdvcmsgc2VydmljZSBwcm92aWRlcidzIGRlZmF1bHQgZ2F0ZXdh eT8gSWRlYXM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+ DQo8YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KU2ltb248YnI+DQotLTxicj4NCkRUTiBtYWRlIGVh c3ksIGxlYW4sIGFuZCBzbWFydCAtLSZndDsmbmJzcDs8YSBocmVmPSJodHRwOi8vcG9zdGVsbGF0 aW9uLnZpYWdlbmllLmNhLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9wb3N0ZWxsYXRpb24udmlh Z2VuaWUuY2E8L2E+PGJyPg0KTkFUNjQvRE5TNjQgb3Blbi1zb3VyY2UgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7LS0mZ3Q7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL2VjZHlzaXMudmlhZ2VuaWUu Y2EvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2VjZHlzaXMudmlhZ2VuaWUuY2E8L2E+PGJyPg0K U1RVTi9UVVJOIHNlcnZlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgLS0mZ3Q7Jm5ic3A7PGEgaHJlZj0iaHR0cDovL251bWIudmlhZ2VuaWUuY2EvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL251bWIudmlhZ2VuaWUuY2E8L2E+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjxh IGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RyYW08L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyYW0gbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iU1Yi PjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PHNwYW4gbGFu Zz0iU1YiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJh bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNW Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dHJhbUBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i U1YiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DEB7Cxmbrcdx02ciscoc_-- From mperumal@cisco.com Thu Feb 13 04:23:28 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EF71A020D for ; Thu, 13 Feb 2014 04:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 fxlgTuaYzvrp for ; Thu, 13 Feb 2014 04:23:21 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 67CB21A0211 for ; Thu, 13 Feb 2014 04:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64428; q=dns/txt; s=iport; t=1392294199; x=1393503799; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0S3KoM8O3+4fneI2ylmvIo671oaPXt/pzcoPJ5ETjNU=; b=YcItpGX/QmtrZ1ivtN4bd8rjq6yDamBRWFuRe3ftSBHGb+/MwSgOJS57 Yx5XyMtDS8dQMKC1zE4o23fb9X26kGBn8QwBpnojiVRvJmza+SSDPCNHb FrhDyHon8MVv1tDIa3Qt3jtr06fHBV7djDWKfjtnpEDacDJpEtMF/WAI6 U=; X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208,217";a="20149609" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 13 Feb 2014 12:23:19 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1DCNJMg024359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 12:23:19 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.56]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 06:23:18 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Karl Stahl , "'Oleg Moskalenko'" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPKLZgRJjRuxRc20ObzyBWsfPM1g== Date: Thu, 13 Feb 2014 12:23:18 +0000 Message-ID: References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> <008101cf28b0$433f97f0$c9bec7d0$@stahl@intertex.se> In-Reply-To: <008101cf28b0$433f97f0$c9bec7d0$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.115] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DEB97xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "tireddy@icisco.com" , 'Simon Perreault' , "tram@ietf.org" , 'Justin Uberti' , 'Marc Blanchet' , "Dan Wing \(dwing\)" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 12:23:28 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DEB97xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What if the user is multihomed, connected to 2 ISPs, and both advertise a T= URN server? How would you rank their intents? Muthu From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl Sent: Thursday, February 13, 2014 5:10 PM To: Muthu Arul Mozhi Perumal (mperumal); 'Oleg Moskalenko' Cc: tireddy@icisco.com; 'Simon Perreault'; tram@ietf.org; 'Justin Uberti'; = 'Marc Blanchet'; Dan Wing (dwing) Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for e= nterprise and ISPs It is the Enterprise and/or NSP/ISP making the announcement/offer of the TU= RN server (by the auto-discovery discussed here) that are the ones that kno= ws and controls the path advised! And their intent/purpose should be good..= .. /Karl Fr=E5n: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] Skickat: den 12 februari 2014 10:28 Till: Oleg Moskalenko Kopia: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@i= etf.org; Dan Wing (dwing); Simon Perreault =C4mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for en= terprise and ISPs Yes, I believe the second case is rare, but would be better than a rat race= b/w administrators trying to block p2p traffic and force it through a TURN= server and apps/endpoints finding smarter ways to bypass them. Muthu From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Si= mon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for e= nterprise and ISPs The TURN server has to be used when it is either the only option, or if it = provides a better path (I guess the second case is rather rare). On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) > wrote: +1 Forcing all traffic through a TURN server and expecting it would provide th= e best user experience doesn't look the right approach. Instead, if a path = through a TURN server exists and does provide lower RTT, jitter etc, being = able to detect and use (or switch to) that path might be desirable.. Muthu From: tram [mailto:tram-bounces@ietf.org] On = Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf= .org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for e= nterprise and ISPs Inline. On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl > wrote: Listening to this thread, I am afraid we are missing the very point and nec= essity for this milestone! - There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the tu= rn client (the WebRTC browser) There are ways, not only: Enterprises or ISPs wishing to provide their own = TURN server, in an attempt to reduce so-called "triangle routing",need a ne= w auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path where t= he bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for pri= oritized RTC (Real Time Communication) traffic. - Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete with d= ata traffic. Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own optimal T= URN server This leads us into "TURN...to identify WebRTC flows" etc! It is not a mist= ake, but the very need for this milestone! Again, it has not been demonstrated why TURN is the right technology here, = compared to a more transparent flow identification tool like MALICE. We don= 't force all HTTP requests to locate a HTTP proxy via anycast, I don't see = why we need to do the same for WebRTC. What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong tech= nology to solve the problem It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall t= raversal problem associated with real-time communication (SIP at that time)= . However, its largest flaw/problem is that quality things were not (could = not be?) considered. The method's very idea (like all similar methods for g= etting RTC through ordinary NAT/Firewalls) is to fool the media through a N= AT/Firewall that is unaware of what is happening. Thus, this is root of qua= lity issues (and bandwidth allocation optimization) that needs to be dealt = with: Real-time traffic fighting with a data traffic crowded congestion poi= nt. I think that "fooling" is an incorrect description. The NAT is supposed to = be transparent to the client. But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate req= uest for a suitable pipe for quality demanding real time traffic. :) ICE is a pre-protocol you use because you want a path for real-time media b= etween parties. Here: The browser says knock knock, I want to get media thr= ough (and of course with as good quality as required and possible). If the NAT/Firewall owner and network owner are allowed to see these reques= ts, they can help/assist in achieving the good media path. If they are not = aware, they cannot help! Hope this made it understandable on an overview level how this can become "= TURN...to identify WebRTC flows" It is also the ONLY way I can see to achieve what we want to achieve and sh= ould be the aim and requirement of this milestone. I am talking about general usage of WebRTC over Internet/mobile OTT (not fe= eding WebRTC into application specific networks like IMS where other method= s may exist). This is good, not evil! If the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues "because it is all about bandwidth"= , "it will resolve itself with time" etc., I strongly object! That is wrong= and will be very detrimental for WebRTC usage. We already see it and I can= give numerous examples of how much less quality demanding VoIP is/is not h= andled quality wise and that it matters. And, what would be bad considering= quality issues and allowing/encouraging methods to deal with them? If the hesitations are raised, because of suspicion that the methods we may= recommend may be misused to stop/block/destroy WebRTC usage (e.g. to prote= ct income from carrier telephony traffic), I could understand and would fig= ht the same battle. But hopefully, those days are (soon) over - At least fo= rward thinking carrier's realize that already. Web RTC will happen. Which c= ustomers want to pay for an access with blocked WebRTC? The carrier's offer= ing/assuring good WebRTC will rather get the customers and income :). (Mayb= e the Web browser can detect and encourage this...) If there are technical concerns of bad result, or better methods allowing n= etwork providers and LAN managers to offer and inform the browser that ther= e are good media paths to be used, and that the web browser automatically c= an chose those, then let us all understand those, so we can achieve what sh= ould be achieved by this milestone. Skype, Hangouts, Facetime are doing billions of minutes per week and the In= ternet has not melted yet. If we need to do flow identification to allow tr= affic to be prioritized, fine (see above regarding my preferred approach), = but forcing all WebRTC traffic through a MITM (TURN server) is a much bigge= r jump that I don't yet see the justification for. In short: TURN is a technology that is supposed to fade away with the move = to IPv6. I don't think we want to make it a critical element of WebRTC. /Karl Fr=E5n: Dan Wing [mailto:dwing@cisco.com] Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl S= tahl; tram@ietf.org; Simon Perreault =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for en= terprise and ISPs On Feb 11, 2014, at 9:08 AM, Marc Blanchet > wrote: Le 2014-02-11 =E0 00:39, Dan Wing >= a =E9crit : On Feb 10, 2014, at 5:30 PM, Justin Uberti > wrote: Good to see there is a lot of interest for this milestone. But based on the= description here, it seems like we want to use TURN primarily to identify = WebRTC flows, as opposed to using it as a NAT traversal tool. This makes me= concerned that we may be using the wrong technology to solve the problem. +1. I would prefer allowing flows to establish themselves using their 'best' pa= th, and the best path is seldom through a TURN server. When we imagine IPv= 6 in our future, we don't want to force an application-level proxy (TURN) s= erver on the path solely for traversing an IPv6 firewall. It seems this thread is conflating all the possible reasons / justification= s for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping NAT= s) * firewall traversal (firewall blocks UDP) * enhancing privacy Unfortunately the TURN server nor the endpoint really know which of those u= se-cases is desired (by the user or by the IT network administrator) or nec= essary (for the call to work at all). Dan, while I agree in principle, I doubt that a user could ever say "I want= mobility or I want NAT traversal". I think the user only want the call to = succeed, whatever the properties of its network point of attachment are. So what can we do? Should the TURN server provide any and all services the= TURN client might possibly want, as that is what a robust TURN server will= do, and the endpoint should prefer TURN candidates over all others because= there might be some functionality / usefulness of TURN that the user might= gain through TURN (e.g., enhanced privacy)? -d This seems problematic. Perhaps we need a way to signal the desired use-c= ase ("trait"), or as Justin suggests, using a different technology for some= of these use-cases. -d On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl > wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F= =F6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for en= terprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =E9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, "automatically" does this.) I understand the STUN vs TURN priority issue. But I don't see how anycast a= ffects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is pro= vided and discovered, CURRENT usage of ICE may suggest a candidate from the= remote party that will make a connection without the need/usage of the TUR= N server (that we wanted to be used for the good purposes listed). The only way we found around this, was to stop STUN through the IP default = gateway (like a restrictive Enterprise firewall does inhibiting ICE connect= ivity, which others are concerned about...). Since the provisioning of auto= -discovery using the anycast mechanism, would be adding a route in a defaul= t gateway, adding a firewall rule to eat STUN packets would assure that the= provisioned TURN server actually becomes used (and not bypassed "by accide= nt"). (That was the thought behind the "automatically" within quotes.) BUT, since you brought up the question, assuming that we have the power to = enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-di= scovered TURN server instead of STUN, would solve the same problem. However= , thinking further (in relation to your next question - "anyone could set u= p a badly-maintained" - enforcing such ICE usage may not be good.) > - 3^rd The Anycast method below - I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) - The anycast discovered TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would this = not be subject to the same service quality issues that plagued 6to4? That i= s, anyone could set up a badly-maintained, under-provisioned TURN server an= d announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can we = prevent triangle routing? There is nothing guaranteeing that the anycast se= rver you see is being provided to you by your ISP, rather than a server sit= ting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready answer= ... An auto-discovered TURN server must be trusted (whatever method it is disco= vered by). We are trusting the one providing us with an IP address and defa= ult gateway anyway. It would be easy if we could reuse that trust, instead = of another mechanisms. Is there a good way for the browser to check that the anycast address is no= t handled beyond the network service provider's default gateway? Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DEB97xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

What if the user is multihomed, connected to 2 ISPs, and b= oth advertise a TURN server? How would you rank their intents?

 

Muthu

 

From: tram [ma= ilto:tram-bounces@ietf.org] On Behalf Of Karl Stahl
Sent: Thursday, February 13, 2014 5:10 PM
To: Muthu Arul Mozhi Perumal (mperumal); 'Oleg Moskalenko'
Cc: tireddy@icisco.com; 'Simon Perreault'; tram@ietf.org; 'Justin Ub= erti'; 'Marc Blanchet'; Dan Wing (dwing)
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

 

It is the Enterprise and/or NS= P/ISP making the announcement/offer of the TURN server (by the auto-discove= ry discussed here) that are the ones that knows and controls the path advised! And their intent/purpose should be good….

/Karl

 

Fr=E5n: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisc= o.com]
Skickat: den 12 februari 2014 10:28
Till: Oleg Moskalenko
Kopia: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet;= tram@ietf.org; Dan Wing (dwing); Simon Perreault
=C4mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism= for enterprise and ISPs

 

Yes, I believe the second case is rare, but would be bette= r than a rat race b/w administrators trying to block p2p traffic and force = it through a TURN server and apps/endpoints finding smarter ways to bypass them.

 

Muthu

 

From: Oleg Mos= kalenko [mailto:mom040267@gmail.com<= /a>]
Sent: Wednesday, February 12, 2014 1:07 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon= Perreault
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

 

The TURN server has to be used when it is either the= only option, or if it provides a better path (I guess the second case is r= ather rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi P= erumal (mperumal) <mperumal@cisco.com> wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would provide= the best user experience doesn't look the right approach. Instead, if a path through a TURN server exists and does provide= lower RTT, jitter etc, being able to detect and use (or switch to) that pa= th might be desirable..

 

Muthu

 

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl
Cc: tireddy@= icisco.com; Marc Blanchet; tram@ietf.org; Dan W= ing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> wr= ote:

Listening to this thread, I am afraid we are= missing the very point and necessity for this milestone!=

- There are severe NAT traversal and quality= issues that should and can be dealt with by a good auto-discovery mechanism and the right usage by the turn client (the WebRTC browser)

 

There are ways, not only: Enterprises or ISPs wishing to provide their own TURN server, in an attemp= t to reduce so-called "triangle routing",need a new auto-discover= y mechanism

But also: - NSPs (Network Service Providers)= want to provide a path where the bandwidth of WebRTC is better coped with.

- NSPs or Enterprises want to offer an Inter= net access quality pipe for prioritized RTC (Real Time Communication) traffic.

- Enterprises having restrictive firewalls, = want to provide a UDP-path for WebRTC and possibly also for better quality where RTC do not compete with data traffic.

Also considering

- Mobility; It is common to move from a LAN = to accessing via WiFi or 3G/4G OTT channels, all should be able to automatically offer their own optimal TURN server

 

This leads us into  “TURN…to identify WebRTC flows”= ; etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the right technolo= gy here, compared to a more transparent flow identification tool like MALIC= E. We don't force all HTTP requests to locate a HTTP proxy via anycast, I don't see why we need to do the same= for WebRTC. 

 

What are the hesitations raised here?=

> TURN primarily to identify WebRTC flows, as opp= osed to using it as a NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem=

It is correct that ICE/STUN/TURN was designe= d to address the NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw= /problem is that quality things were not (could not be?) considered. The me= thod’s very idea (like all similar methods for getting RTC through or= dinary NAT/Firewalls) is to fool the media through a NAT/Firewall that is unaware of what is happening. Thus, this is= root of quality issues (and bandwidth allocation optimization) that needs = to be dealt with: Real-time traffic fighting with a data traffic crowded co= ngestion point.

 

I think that "fooling" is an incorrect description. The = NAT is supposed to be transparent to the client.

 

But, a BLESSING of ICE/STUN/TURN is that it = can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. J

ICE is a pre-protocol you use because you wa= nt a path for real-time media between parties. Here: The browser says knock knock, I want to get media through (and of course with as good = quality as required and possible).

 

If the NAT/Firewall owner and network owner = are allowed to see these requests, they can help/assist in achieving the good media path. If they are not aware, they cannot help!

 

Hope this made it understandable on an overv= iew level how this can become “TURN…to identify WebRTC flows”

It is also the ONLY way I can see to achieve= what we want to achieve and should be the aim and requirement of this milestone.

 

I am talking about general usage of WebRTC o= ver Internet/mobile OTT (not feeding WebRTC into application specific networks like IMS where other methods may exist).

 

This is good, not evil!

 

If the hesitations are raised because of a b= elief/hope/wish that there are no or will not be severe quality issues “because it is all about bandwidth”, “it will res= olve itself with time” etc., I strongly object! That is wrong and wil= l be very detrimental for WebRTC usage. We already see it and I can give nu= merous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad= considering quality issues and allowing/encouraging methods to deal with t= hem?

 

If the hesitations are raised, because of su= spicion that the methods we may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to protect income from carrier telep= hony traffic), I could understand and would fight the same battle. But hope= fully, those days are (soon) over – At least forward thinking carrier= ’s realize that already. Web RTC will happen. Which customers want to pay for an access with blocked WebRTC? The= carrier’s offering/assuring good WebRTC will rather get the customer= s and income J<= /span>. (Maybe the Web browser can detect and encoura= ge this…) 

 

If there are technical concerns of bad resul= t, or better methods allowing network providers and LAN managers to offer and inform the browser that there are good media paths to be used= , and that the web browser automatically can chose those, then let us all u= nderstand those, so we can achieve what should be achieved by this mileston= e.

 

Skype, Hangouts, Facetime are doing billions of minutes per week a= nd the Internet has not melted yet. If we need to do flow identification to= allow traffic to be prioritized, fine (see above regarding my preferred approach), but forcing all WebRTC traffi= c through a MITM (TURN server) is a much bigger jump that I don't yet see t= he justification for.

 

In short: TURN is a technology that is supposed to fade away with = the move to IPv6. I don't think we want to make it a critical element of We= bRTC.

 

/Karl

 

 

Fr=E5n: Dan Wing [mailto:dwing@cisco.com]
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon Perreault


=C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism= for enterprise and ISPs

 

 

On Feb 11, 2014, at 9:08 AM, Marc Blanchet <<= a href=3D"mailto:marc.blanchet@viagenie.ca" target=3D"_blank">marc.blanchet= @viagenie.ca> wrote:

 

Le 2014-02-11 =E0 00:39, Dan Wing <dwing@cisco.com> a =E9cri= t :

 


On Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> wrote:

 

Good to see there is a lot of interest f= or this milestone. But based on the description here, it seems like we want to use TURN primarily to identify WebRTC flows, as opposed to= using it as a NAT traversal tool. This makes me concerned that we may be u= sing the wrong technology to solve the problem.

 

+1.

 

I would prefer allowing flows to establi= sh themselves using their 'best' path, and the best path is seldom through a TURN server.  When we imagine IPv6 in our future, we= don't want to force an application-level proxy (TURN) server on the path s= olely for traversing an IPv6 firewall.

 

 

It seems this thread is conflating all t= he possible reasons / justifications for TURN:

  * mobility

  * NAT traversal (both endpoints a= re behind endpoint-dependent mapping NATs)

  * firewall traversal (firewa= ll blocks UDP)

  * enhancing privacy

 

Unfortunately the TURN server nor the en= dpoint really know which of those use-cases is desired (by the user or by the IT network administrator) or necessary (for the call to wor= k at all).

 

Dan, while I agree in principle, I doubt that a = user could ever say "I want mobility or I want NAT traversal". I = think the user only want the call to succeed, whatever the properties of its network point of attachment are.

 

So what can we do?  Should the TURN server = provide any and all services the TURN client might possibly want, as that i= s what a robust TURN server will do, and the endpoint should prefer TURN candidates over all others because there might= be some functionality / usefulness of TURN that the user might gain throug= h TURN (e.g., enhanced privacy)?

 

-d

 

 

 

 This seems problematic.  Perh= aps we need a way to signal the desired use-case ("trait"), or as= Justin suggests, using a different technology for some of these use-cases.=

 

-d

 

 

 

 

On Mon, Feb 10, 2014 at 3:18 PM, Karl St= ahl <ka= rl.stahl@intertex.se> wrote:

Simon,

Good questions - see inline below --> .
Some more thought is required!

/Karl

-----Ursprungligt meddelande-----
Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl; t= ram@ietf.org; tireddy@icisco.com
=C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for en= terprise and ISPs


Karl,

It is great to see such enthusiasm! Thanks!

I have a couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a =E9crit :
> - Note that to achieve some of the above points, TURN must be favored<= br> > over STUN to enforce that the TURN-path actually is used. (The Anycast=
> method suggested below, “automatically” does this.)

I understand the STUN vs TURN priority issue. But I don't see how anycast a= ffects it in any way. Can you please explain?

--- Good point - I was a bit quick here = (maybe too quick)
We have given this quite bit of thought, since even if a TURN server is pro= vided and discovered, CURRENT usage of ICE may suggest a candidate from the= remote party that will make a connection without the need/usage of the TUR= N server (that we wanted to be used for the good purposes listed).

The only way we found around this, was to stop STUN through the IP default = gateway (like a restrictive Enterprise firewall does inhibiting ICE connect= ivity, which others are concerned about...). Since the provisioning of auto= -discovery using the anycast mechanism, would be adding a route in a default gateway, adding a firewall rule to ea= t STUN packets would assure that the provisioned TURN server actually becom= es used (and not bypassed "by accident"). (That was the thought b= ehind the “automatically” within quotes.)

BUT, since you brought up the question, assuming that we have the power to = enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-di= scovered TURN server instead of STUN, would solve the same problem. However= , thinking further (in relation to your next question - "anyone could set up a badly-maintained"= - enforcing such ICE usage may not be good.)



> - 3^rd The Anycast method below – I see no problem
>
> It also has the advantage of encouraging (but not requiring) the
> STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) – The anycast discovered TURN-serve= r can
> be the access gateway to such quality pipe for WebRTC media, in a
> single NSP provided CPE, scaling from residential and up.)

Suppose we define well-known anycast TURN server addresses. How would this = not be subject to the same service quality issues that plagued 6to4? That i= s, anyone could set up a badly-maintained, under-provisioned TURN server an= d announce it over BGP to the world, as it was done for
6to4 relays. Or just bad BGP outbound filter configuration. And how can we = prevent triangle routing? There is nothing guaranteeing that the anycast se= rver you see is being provided to you by your ISP, rather than a server sit= ting on the other side of the planet.

--- Good point - needs to be resolved. F= or this I don't have a ready answer...
An auto-discovered TURN server must be trusted (whatever method it is disco= vered by). We are trusting the one providing us with an IP address and defa= ult gateway anyway. It would be easy if we could reuse that trust, instead = of another mechanisms.

Is there a good way for the browser to check that the anycast address is no= t handled beyond the network service provider's default gateway? Ideas?




Thanks,
Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               -->&nb= sp;http://numb.viage= nie.ca
_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

 

________________________________________= _______
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


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

 

 

 


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

 

--_000_E721D8C6A2E1544DB2DEBC313AF54DE2243DEB97xmbrcdx02ciscoc_-- From karl.stahl@intertex.se Thu Feb 13 05:14:09 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3AC1A0237 for ; Thu, 13 Feb 2014 05:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 xIdDuL5OX5K5 for ; Thu, 13 Feb 2014 05:13:59 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 881641A0234 for ; Thu, 13 Feb 2014 05:13:57 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131413532179; Thu, 13 Feb 2014 14:13:53 +0100 From: "Karl Stahl" To: "'Muthu Arul Mozhi Perumal \(mperumal\)'" , "'Oleg Moskalenko'" References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> <008101cf28b0$433f97f0$c9bec7d0$@stahl@intertex.se> In-Reply-To: Date: Thu, 13 Feb 2014 14:13:53 +0100 Message-ID: <010901cf28bd$71b08ec0$5511ac40$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010A_01CF28C5.D374F6C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPKLZgRJjRuxRc20ObzyBWsfPM1pqzJd6g Content-Language: sv Cc: tireddy@icisco.com, 'Simon Perreault' , tram@ietf.org, 'Justin Uberti' , 'Marc Blanchet' , "'Dan Wing \(dwing\)'" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 13:14:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_010A_01CF28C5.D374F6C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good point! =20 Then the user/its enterprise must decide, which should be taken care by recommended=20 WEB BROWSER BEHAVIOUR: =20 It is previously suggested, and to some extent discussed, that the = WebRTC browser should select the TURN server to use in the following priority order, where ICE would assure that you get some connectivity if several candidates are found and needs to be tested: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing) 2) TURN server address configured by the network administrator via an = =93admin policy template=94 or a WPAD method as mentioned below 3) TURN server address auto-discovered by the mechanism discussed here 4) TURN server address being supplied by the web application =20 =20 Step 2) and step 3) allows the Enterprise to select/advice to place the media to the best ISP=20 (whether he will do it based on quality, cost or availability) =20 I cannot see there is a good way rank intents with the Enterprise in = charge (using 2, or 3) =20 /Karl =20 =20 =20 Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Muthu Arul Mozhi = Perumal (mperumal) Skickat: den 13 februari 2014 13:23 Till: Karl Stahl; 'Oleg Moskalenko' Kopia: tireddy@icisco.com; 'Simon Perreault'; tram@ietf.org; 'Justin Uberti'; 'Marc Blanchet'; Dan Wing (dwing) =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 What if the user is multihomed, connected to 2 ISPs, and both advertise = a TURN server? How would you rank their intents? =20 Muthu =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl Sent: Thursday, February 13, 2014 5:10 PM To: Muthu Arul Mozhi Perumal (mperumal); 'Oleg Moskalenko' Cc: tireddy@icisco.com; 'Simon Perreault'; tram@ietf.org; 'Justin = Uberti'; 'Marc Blanchet'; Dan Wing (dwing) Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 It is the Enterprise and/or NSP/ISP making the announcement/offer of the TURN server (by the auto-discovery discussed here) that are the ones = that knows and controls the path advised! And their intent/purpose should be good=85. /Karl =20 Fr=E5n: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 Skickat: den 12 februari 2014 10:28 Till: Oleg Moskalenko Kopia: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault =C4mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 Yes, I believe the second case is rare, but would be better than a rat = race b/w administrators trying to block p2p traffic and force it through a = TURN server and apps/endpoints finding smarter ways to bypass them. =20 Muthu =20 From: Oleg Moskalenko [mailto:mom040267@gmail.com]=20 Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The TURN server has to be used when it is either the only option, or if = it provides a better path (I guess the second case is rather rare). =20 On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) wrote: +1 =20 Forcing all traffic through a TURN server and expecting it would provide = the best user experience doesn't look the right approach. Instead, if a path through a TURN server exists and does provide lower RTT, jitter etc, = being able to detect and use (or switch to) that path might be desirable.. =20 Muthu =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle routing",need a = new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =93TURN=85to identify WebRTC flows=94 etc! It is not = a mistake, but the very need for this milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like MALICE. We don't force all HTTP requests to locate a HTTP proxy via anycast, I = don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw/problem is that quality things were not (could not be?) considered. The method=92s very idea (like all similar = methods for getting RTC through ordinary NAT/Firewalls) is to fool the media = through a NAT/Firewall that is unaware of what is happening. Thus, this is root = of quality issues (and bandwidth allocation optimization) that needs to be dealt with: Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get media through (and of course with as good quality as required and possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =93TURN=85to identify WebRTC flows=94 It is also the ONLY way I can see to achieve what we want to achieve and should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not feeding WebRTC into application specific networks like IMS where other methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =93because it is all about = bandwidth=94, =93it will resolve itself with time=94 etc., I strongly object! That is = wrong and will be very detrimental for WebRTC usage. We already see it and I = can give numerous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad = considering quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and would = fight the same battle. But hopefully, those days are (soon) over =96 At least forward thinking carrier=92s realize that already. Web RTC will happen. = Which customers want to pay for an access with blocked WebRTC? The carrier=92s offering/assuring good WebRTC will rather get the customers and income = J. (Maybe the Web browser can detect and encourage this=85)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the browser that there are good media paths to be used, and that the web browser automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) is a much = bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of WebRTC. =20 /Karl =20 =20 Fr=E5n: Dan Wing [mailto:dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; = Simon Perreault =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet wrote: =20 Le 2014-02-11 =E0 00:39, Dan Wing a =E9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. This makes = me concerned that we may be using the wrong technology to solve the = problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the call = to succeed, whatever the properties of its network point of attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the user = might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =E9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =93automatically=94 does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage of = the TURN server (that we wanted to be used for the good purposes listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be adding a route = in a default gateway, adding a firewall rule to eat STUN packets would assure that the provisioned TURN server actually becomes used (and not bypassed = "by accident"). (That was the thought behind the =93automatically=94 within = quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - "anyone = could set up a badly-maintained" - enforcing such ICE usage may not be good.) > - 3^rd The Anycast method below =96 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =96 The anycast discovered TURN-server = can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued 6to4? = That is, anyone could set up a badly-maintained, under-provisioned TURN = server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the anycast server you see is being provided to you by your ISP, rather than a = server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready answer... An auto-discovered TURN server must be trusted (whatever method it is discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca =20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca =20 STUN/TURN server --> http://numb.viagenie.ca =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 ------=_NextPart_000_010A_01CF28C5.D374F6C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Go= od point!

 

Th= en the user/its enterprise must decide, which should be taken care by = recommended

WE= B BROWSER BEHAVIOUR:

 

It= is previously suggested, and to some extent discussed, that the WebRTC = browser should select the TURN server to use in the following priority = order, where ICE would assure that you get some connectivity if several = candidates are found and needs to be tested:

 

1)= TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing)

2)= TURN server address configured by the network administrator via an = “admin policy template” or a WPAD method as mentioned = below

3)= TURN server address auto-discovered by the mechanism discussed = here

4)= TURN server address being supplied by the web = application

 

 

St= ep 2) and step 3) allows the Enterprise to select/advice to place the = media to the best ISP

(w= hether he will do it based on quality, cost or = availability)

 

I = cannot see there is a good way rank intents with the Enterprise in = charge (using 2, or 3)

 

/K= arl

 

 

 

Fr=E5n: tram = [mailto:tram-bounces@ietf.org] F=F6r Muthu Arul Mozhi Perumal = (mperumal)
Skickat: den 13 februari 2014 13:23
Till: = Karl Stahl; 'Oleg Moskalenko'
Kopia: tireddy@icisco.com; = 'Simon Perreault'; tram@ietf.org; 'Justin Uberti'; 'Marc Blanchet'; Dan = Wing (dwing)
=C4mne: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

What = if the user is multihomed, connected to 2 ISPs, and both advertise a = TURN server? How would you rank their intents?

 

Muthu

 

From:= tram [mailto:tram-bounces@ietf.org] = On Behalf Of Karl Stahl
Sent: Thursday, February 13, = 2014 5:10 PM
To: Muthu Arul Mozhi Perumal (mperumal); 'Oleg = Moskalenko'
Cc: tireddy@icisco.com; 'Simon = Perreault'; tram@ietf.org; 'Justin = Uberti'; 'Marc Blanchet'; Dan Wing (dwing)
Subject: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs

 

It= is the Enterprise and/or NSP/ISP making the announcement/offer of the = TURN server (by the auto-discovery discussed here) that are the ones = that knows and controls the path advised! And their intent/purpose = should be good….

/K= arl

&n= bsp;

Fr=E5n: Muthu Arul = Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] =
Skickat: den 12 februari 2014 10:28
Till: Oleg = Moskalenko
Kopia: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc = Blanchet; tram@ietf.org; Dan Wing = (dwing); Simon Perreault
=C4mne: RE: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and ISPs

 

Yes, I believe the = second case is rare, but would be better than a rat race b/w = administrators trying to block p2p traffic and force it through a TURN = server and apps/endpoints finding smarter ways to bypass = them.

 

Muthu

 

From:= Oleg = Moskalenko [mailto:mom040267@gmail.com] =
Sent: Wednesday, February 12, 2014 1:07 PM
To: = Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl = Stahl; tireddy@icisco.com; = Marc Blanchet; tram@ietf.org; Dan = Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: = TURN server auto-discovery mechanism for enterprise and ISPs

 

The TURN server has to be used when = it is either the only option, or if it provides a better path (I guess = the second case is rather rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would = provide the best user experience doesn't look the right approach. = Instead, if a path through a TURN server exists and does provide lower = RTT, jitter etc, being able to detect and use (or switch to) that path = might be desirable..

 

Muthu

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Justin = Uberti
Sent: Wednesday, February 12, 2014 11:43 = AM
To: Karl Stahl
Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan = Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: = TURN server auto-discovery mechanism for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  R= 20;TURN…to identify WebRTC flows” etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the right = technology here, compared to a more transparent flow identification tool = like MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for = WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method’s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion point.

 

I think that "fooling" is an incorrect = description. The NAT is supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = “TURN…to identify WebRTC flows”

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues “because it is all about = bandwidth”, “it will resolve itself with time” etc., I = strongly object! That is wrong and will be very detrimental for WebRTC = usage. We already see it and I can give numerous examples of how much = less quality demanding VoIP is/is not handled quality wise and that it = matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = – At least forward thinking carrier’s realize that already. = Web RTC will happen. Which customers want to pay for an access with = blocked WebRTC? The carrier’s offering/assuring good WebRTC will = rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this…) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone.

 

Skype, Hangouts, Facetime are doing billions of minutes per = week and the Internet has not melted yet. If we need to do flow = identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to fade = away with the move to IPv6. I don't think we want to make it a critical = element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=E5n: Dan Wing = [mailto:dwing@cisco.com]
Skickat: den 11 = februari 2014 18:25
Till: Marc = Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon = Perreault


=C4mn= e: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs

 

 

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

 

Le = 2014-02-11 =E0 00:39, Dan Wing <dwing@cisco.com> a =E9crit :

 


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> wrote:

 

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all).

 

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced privacy)?

 

-d

 

 

 

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these use-cases.

 

-d<= span lang=3DEN-US>

 

 

 

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Simon = Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C4mne: Re: [tram] Milestone = 3: TURN server auto-discovery mechanism for enterprise and = ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =E9crit :
> - Note that to achieve some of the above points, TURN = must be favored
> over STUN to enforce that the TURN-path actually = is used. (The Anycast
> method suggested below, = “automatically” does this.)

I understand the STUN vs = TURN priority issue. But I don't see how anycast affects it in any way. = Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the “automatically” within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below – I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) – The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://postellation.viagenie.ca
NAT64/DNS64 = open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server =               --> http://numb.viagenie.ca
________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

_= ______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

 

<= /div>

 


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

 

------=_NextPart_000_010A_01CF28C5.D374F6C0-- From karl.stahl@intertex.se Thu Feb 13 05:23:13 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6501A0248 for ; Thu, 13 Feb 2014 05:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 IMxZ76pJELrc for ; Thu, 13 Feb 2014 05:23:08 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5361A0237 for ; Thu, 13 Feb 2014 05:23:07 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131423034061; Thu, 13 Feb 2014 14:23:03 +0100 From: "Karl Stahl" To: "'Muthu Arul Mozhi Perumal \(mperumal\)'" , "'Justin Uberti'" References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> <007c01cf28b0$29a04c40$7ce0e4c0$@stahl@intertex.se> In-Reply-To: Date: Thu, 13 Feb 2014 14:23:03 +0100 Message-ID: <011d01cf28be$b9a4db40$2cee91c0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011E_01CF28C7.1B694340" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPKLXxPYEog8wgaUC6SJgg3H1nnZqzKbpg Content-Language: sv Cc: tireddy@icisco.com, 'Simon Perreault' , 'Oleg Moskalenko' , tram@ietf.org, 'Marc Blanchet' , "'Dan Wing \(dwing\)'" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 13:23:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_011E_01CF28C7.1B694340 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 Fr=C3=A5n: Muthu Arul Mozhi Perumal (mperumal) = [mailto:mperumal@cisco.com]=20 Skickat: den 13 februari 2014 13:20 Till: Karl Stahl; 'Justin Uberti' Kopia: tireddy@icisco.com; 'Simon Perreault'; 'Oleg Moskalenko'; = tram@ietf.org; 'Marc Blanchet'; Dan Wing (dwing) =C3=84mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 |Just ICE may result in that the remote end=E2=80=99s proposal overrides = a path=20 |that quality wise is better to use. =20 Then, that's an ICE implementation and should be fixed. --- ICE can unfortunately do this by itself. We and the browser have to = use ICE in a way that this is achieved (or the enterprise/NSP can stop = STUN tests from reaching the public side, thus inhibiting overriding = path-proposals from the remote side).=20 =20 |That is why we (also) must assure that an auto-discovered TURN server=20 |actually is used, (instead of a path suggested by the remote end). =20 Again, if the auto-discovered TURN server provides a better quality = path, ICE should be able to discover that path and use it -- that's the = best long term solution, IMO. --- Yes, but ICE needs our and the browsers help/advice how to do it (no = change to ICE needed) =20 Muthu =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Karl Stahl Sent: Thursday, February 13, 2014 5:09 PM To: 'Justin Uberti'; Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; 'Simon Perreault'; 'Oleg Moskalenko'; = tram@ietf.org; 'Marc Blanchet'; Dan Wing (dwing) Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Just ICE may result in that the remote end=E2=80=99s proposal overrides = a path that quality wise is better to use. =20 That is why we (also) must assure that an auto-discovered TURN server = actually is used, (instead of a path suggested by the remote end). =20 =20 /Karl =20 Fr=C3=A5n: Justin Uberti [mailto:juberti@google.com]=20 Skickat: den 12 februari 2014 18:46 Till: Muthu Arul Mozhi Perumal (mperumal) Kopia: Oleg Moskalenko; Karl Stahl; tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Agree. If TURN is indeed being provided for the user's benefit, the = client's ICE logic (based on RTT or similar) should result in it = preferring the TURN path. =20 On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) = wrote: Yes, I believe the second case is rare, but would be better than a rat = race b/w administrators trying to block p2p traffic and force it through = a TURN server and apps/endpoints finding smarter ways to bypass them. =20 Muthu =20 From: Oleg Moskalenko [mailto:mom040267@gmail.com]=20 Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The TURN server has to be used when it is either the only option, or if = it provides a better path (I guess the second case is rather rare). =20 On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) = wrote: +1 =20 Forcing all traffic through a TURN server and expecting it would provide = the best user experience doesn't look the right approach. Instead, if a = path through a TURN server exists and does provide lower RTT, jitter = etc, being able to detect and use (or switch to) that path might be = desirable.. =20 Muthu =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); = Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and = necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by = the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle = routing",need a new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D etc! It is not a mistake, but the very need for this = milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like = MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the = wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication = (SIP at that time). However, its largest flaw/problem is that quality = things were not (could not be?) considered. The method=E2=80=99s very = idea (like all similar methods for getting RTC through ordinary = NAT/Firewalls) is to fool the media through a NAT/Firewall that is = unaware of what is happening. Thus, this is root of quality issues (and = bandwidth allocation optimization) that needs to be dealt with: = Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get = media through (and of course with as good quality as required and = possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D It is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =E2=80=9Cbecause it is all = about bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with = time=E2=80=9D etc., I strongly object! That is wrong and will be very = detrimental for WebRTC usage. We already see it and I can give numerous = examples of how much less quality demanding VoIP is/is not handled = quality wise and that it matters. And, what would be bad considering = quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. (Maybe the Web browser can = detect and encourage this=E2=80=A6)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the = browser that there are good media paths to be used, and that the web = browser automatically can chose those, then let us all understand those, = so we can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the = Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) = is a much bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of = WebRTC. =20 /Karl =20 =20 Fr=C3=A5n: Dan Wing [mailto:dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; = Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet = wrote: =20 Le 2014-02-11 =C3=A0 00:39, Dan Wing a =C3=A9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' = path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN = server will do, and the endpoint should prefer TURN candidates over all = others because there might be some functionality / usefulness of TURN = that the user might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl = wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =E2=80=9Cautomatically=E2=80=9D within quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) > - 3^rd The Anycast method below =E2=80=93 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready = answer... An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca = =20 NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca = =20 STUN/TURN server --> http://numb.viagenie.ca = =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_011E_01CF28C7.1B694340 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

Fr=C3=A5n: Muthu Arul = Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com]
Skickat: = den 13 februari 2014 13:20
Till: Karl Stahl; 'Justin = Uberti'
Kopia: tireddy@icisco.com; 'Simon Perreault'; 'Oleg = Moskalenko'; tram@ietf.org; 'Marc Blanchet'; Dan Wing = (dwing)
=C3=84mne: RE: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

|Just = ICE may result in that the remote end=E2=80=99s proposal overrides a = path

|that quality wise = is better to use.

 

Then, = that's an ICE implementation and should be = fixed.

--= - ICE can unfortunately do this by itself. We and the browser have to = use ICE in a way that this is achieved (or the enterprise/NSP can stop = STUN tests from reaching the public side, thus inhibiting overriding = path-proposals from the remote side).

 

|That = is why we (also) must assure that an auto-discovered TURN server =

|actually is used, = (instead of a path suggested by the remote end).

 

Again, = if the auto-discovered TURN server provides a better quality path, ICE = should be able to discover that path and use it -- that's the best long = term solution, IMO.

--= - Yes, but ICE needs our and the browsers help/advice how to do it (no = change to ICE needed)

 

Muthu

 

From:= tram [mailto:tram-bounces@ietf.org] = On Behalf Of Karl Stahl
Sent: Thursday, February 13, = 2014 5:09 PM
To: 'Justin Uberti'; Muthu Arul Mozhi Perumal = (mperumal)
Cc: tireddy@icisco.com; 'Simon = Perreault'; 'Oleg Moskalenko'; tram@ietf.org; 'Marc Blanchet'; Dan = Wing (dwing)
Subject: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

Ju= st ICE may result in that the remote end=E2=80=99s proposal overrides a = path that quality wise is better to use.

 

Th= at is why we (also) must assure that an auto-discovered TURN server = actually is used, (instead of a path suggested by the remote end). =  

 

/K= arl

 

Fr=C3=A5n: Justin = Uberti [mailto:juberti@google.com] =
Skickat: den 12 februari 2014 18:46
Till: Muthu = Arul Mozhi Perumal (mperumal)
Kopia: Oleg Moskalenko; Karl = Stahl; tireddy@icisco.com; = Marc Blanchet; tram@ietf.org; Dan = Wing (dwing); Simon Perreault
=C3=84mne: Re: [tram] Milestone = 3: TURN server auto-discovery mechanism for enterprise and = ISPs

 

Agree. = If TURN is indeed being provided for the user's benefit, the client's = ICE logic (based on RTT or similar) should result in it preferring the = TURN path.

 

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi = Perumal (mperumal) <mperumal@cisco.com> = wrote:

Yes, I = believe the second case is rare, but would be better than a rat race b/w = administrators trying to block p2p traffic and force it through a TURN = server and apps/endpoints finding smarter ways to bypass = them.

 

Muthu

 

From:= Oleg = Moskalenko [mailto:mom040267@gmail.com]
Sent: Wednesday, = February 12, 2014 1:07 PM
To: Muthu Arul Mozhi Perumal = (mperumal)
Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan = Wing (dwing); Simon Perreault


Subject: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

The TURN server has to be used when it is either the only = option, or if it provides a better path (I guess the second case is = rather rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would = provide the best user experience doesn't look the right approach. = Instead, if a path through a TURN server exists and does provide lower = RTT, jitter etc, being able to detect and use (or switch to) that path = might be desirable..

 

Muthu

 

From:= tram = [mailto:tram-bounces@ietf.org] On Behalf Of Justin = Uberti
Sent: Wednesday, February 12, 2014 11:43 = AM
To: Karl Stahl
Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan = Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: = TURN server auto-discovery mechanism for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the right = technology here, compared to a more transparent flow identification tool = like MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for = WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method=E2=80=99s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion point.

 

I think that "fooling" is an incorrect = description. The NAT is supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues =E2=80=9Cbecause it is all about = bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D = etc., I strongly object! That is wrong and will be very detrimental for = WebRTC usage. We already see it and I can give numerous examples of how = much less quality demanding VoIP is/is not handled quality wise and that = it matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this=E2=80=A6) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone.

 

Skype, Hangouts, Facetime are doing billions of minutes per = week and the Internet has not melted yet. If we need to do flow = identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to fade = away with the move to IPv6. I don't think we want to make it a critical = element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=C3=A5n: Dan Wing = [mailto:dwing@cisco.com]
Skickat: den 11 = februari 2014 18:25
Till: Marc = Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon = Perreault


=C3=84= mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs

 

 

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

 

Le = 2014-02-11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit :

 


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> wrote:

 

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all).

 

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced privacy)?

 

-d

 

 

 

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these use-cases.

 

-d<= span lang=3DEN-US>

 

 

 

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon = Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C3=84mne: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =C3=A9crit :
> - Note that to achieve some of the above points, = TURN must be favored
> over STUN to enforce that the TURN-path = actually is used. (The Anycast
> method suggested below, = =E2=80=9Cautomatically=E2=80=9D does this.)

I understand the STUN = vs TURN priority issue. But I don't see how anycast affects it in any = way. Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the =E2=80=9Cautomatically=E2=80=9D within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below =E2=80=93 I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) =E2=80=93 The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://postellation.viagenie.ca
NAT64/DNS64 = open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server =               --> http://numb.viagenie.ca
________________________= _______________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

_= ______________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

 

<= /div>

 


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

 

 

------=_NextPart_000_011E_01CF28C7.1B694340-- From karl.stahl@intertex.se Thu Feb 13 03:35:07 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E650A1A01EA for ; Thu, 13 Feb 2014 03:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 jzwI6rNDop7z for ; Thu, 13 Feb 2014 03:34:59 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id BA3E41A01F9 for ; Thu, 13 Feb 2014 03:34:57 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131234511651; Thu, 13 Feb 2014 12:34:51 +0100 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Hutton, Andrew'" , "'Justin Uberti'" , "'Muthu Arul Mozhi Perumal \(mperumal\)'" References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> Date: Thu, 13 Feb 2014 12:34:51 +0100 Message-ID: <006701cf28af$9c2a27f0$d47e77d0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01CF28B7.FDEE8FF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8obNsCBHZfUz6PQqmEmyo5gqkf2AAIL2iQ Content-Language: sv X-Mailman-Approved-At: Thu, 13 Feb 2014 05:43:49 -0800 Cc: tireddy@icisco.com, 'Simon Perreault' , 'Oleg Moskalenko' , tram@ietf.org, 'Marc Blanchet' , "'Dan Wing \(dwing\)'" Subject: [tram] IMPORTANT CLARIFICATIONS: Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:35:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0068_01CF28B7.FDEE8FF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On the side of this TRAM-list, I also got this question: > Regarding the enterprise case, I am not sure I follow your argument. > Do you mean that by setting up an enterprise TURN server, and open the = firewall for media over UDP from/to TURN server be the solution? ---- As we all realize, that would of course not help or improve things =20 The intended solution in the enterprise case has not yet been spelled = out in this TRAM-list discussion, so for better understanding, let me = copy a few things from the discussion in September/October on the = RTCWEB-list and what is (since long) spelled out in the = draft-ietf-rtcweb-use-cases-and-requirements. =20 For better understanding, I also want to point out that a TURN can have = two interfaces (acting like a router for media between different = networks). This allows to easier understand that can TURN servers can = direct a best media path (rather than just thinking that a TURN service = is a device which media just bounces against at one interface).=20 =20 And, we can also hope for that a TURN server becomes a (common) = component of a firewall, which would allow the firewall to understand = that the media directed to it is RTC and should be prioritized whereby = the firewall can traffic shaped (back-off data traffic that may be = filling its Internet pipe) as well as e.g. set diffserve bits or take = other measures to assist proper quality handling thought the network. = (These are common mechanisms available and used in firewalls/NATs/access = routers, but TURN servers are not yet included such devices.) The same = goes for access routers/default gateways, DPIs in the transport network = itself =E2=80=93 TURN servers included in such points were media can = pass and quality measures applied may/will be very useful to get us = WebRTC media with through networks without quality destruction. =20 >From the RTCWEB mailing list September 20th (by me): An enterprise network that want to keep a restrictive firewall not = allowing UDP traffic, could provide a real-time path using a TURN server = paralleling the firewall, instead of tunneling RTP through always open = http or https ports resulting in RTP media over TCP =E2=80=93 with = severe quality problems from TCP retransmissions of dropped packets. The = TURN server address is most easily provided in the same way as the IP = address and DNS address. (That would also put the right party in control = =E2=80=93 The network provider (here the enterprise) decides what is = allowed on his network.) =20 The browser should select which available TURN server address to use in = the following priority order, where ICE could be used to try several: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used) 2) TURN server address configured by the network administrator via an = =E2=80=9Cadmin policy template=E2=80=9D 3) TURN server address supplied by DHCP or similar automatic network = method 4) TURN server address being supplied by the web application" =20 =20 And from yesterdays(!) = http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1= 4 these enterprise things and necessity are spelled out in: =20 F19 The browser must be able to use several STUN and TURN servers ---------------------------------------------------------------- =20 A22 = 3.3.5. Simple Video Communication Service, enterprise = aspects = 3.3.5.1. Description This use-case is similar to the Simple Video Communication Service use-case (Section 3.3.1 = ). =20 What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use-case. =20 An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application sessions used from inside the company towards any external peer. To be able to do this they deploy a TURN server that straddles the boundary between the internal and the external network. =20 The firewall will block all attempts to use STUN with an external destination unless they go to the enterprise auditing TURN server. In cases where employees are using RTCWEB applications provided by an external service provider they still want the traffic to stay inside their internal network and in addition not load the straddling TURN server, thus they deploy a STUN server allowing the RTCWEB client to determine its server reflexive address on the internal side. Thus enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possible to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to achieve by auto-configuration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. = 3.3.5.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F20 The browser must support the use of STUN and TURN servers that are supplied by entities other than the web application (i.e. the network provider). ---------------------------------------------------------------- =20 There are further requirement listed, helping us to understand the need = for auto discovery and a network provided TURN-server should be used to = ENFORCE that media takes that path (and thus, other paths e.g. suggested = by the remote MUST not happen to be used). This is related to the = mobility aspect (valid even without the roaming idea): = 3.3.6. Simple Video Communication Service, access = change = 3.3.6.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.3.1 = ). The difference is that the user changes network access during the session. =20 The communication device used by one of the users has several network adapters (Ethernet, WiFi, Cellular). The communication device is accessing the Internet using Ethernet, but the user has to start a trip during the session. The communication device automatically changes to use WiFi when the Ethernet cable is removed and then moves to cellular access to the Internet when moving out of WiFi coverage. The session continues even though the access method changes. = 3.3.6.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- = 3.3.7. Simple Video Communication Service, QoS = 3.3.7.1. Description This use-case is almost identical to the Simple Video Communication Service, access change use-case (Section 3.3.6 = ). The use of Quality of Service (QoS) capabilities = is added: =20 The user in the previous use case that starts a trip is behind a common residential router that supports prioritization of traffic. In addition, the user's provider of cellular access has QoS support enabled. The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular. = 3.3.7.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- F22 The browser must be able to receive streams and data from multiple peers concurrently. ---------------------------------------------------------------- =20 Further from the RTCWEB mailing list September 20th (by me): =20 There are several reasons for a network service provider to supply a = TURN server as part of his offered access: - to keep media paths short, specifically not sending media outside its = own network to some distant application provided TURN server - to support mobility, i.e. you may want to move from a LAN with a = configured TURN server to accessing via WiFi or 3G/4G OTT channels - to offer a media path with better quality (than best effort data = traffic). Getting =E2=80=9CWebRTC-ready=E2=80=9D access and we look forward to = telepresence for everyone. =20 =20 I hope this (a bit lengthy) summary of already thought-out and discussed = aspects/requirements will help us understand that the auto-discovered = TURN server is an ORDER from the enterprise and/or the NSP/ISP to send = the media through this TURN path, and that other media paths that may = exist MUST NOT BE USED. (That is why we especially have to watch/advice = that workable media paths proposed by the remote party not becomes used = =E2=80=9Cby accident=E2=80=9D. =20 /Karl =20 =20 Fr=C3=A5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Skickat: den 13 februari 2014 04:37 Till: Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Kopia: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; = tram@ietf.org; Marc Blanchet; Dan Wing (dwing); Karl Stahl =C3=84mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Hi Andy, =20 There are other ways to solve the problem for example using PCP. Can you = clarify how deploying a TURN server in the Enterprise protects the users = and the network ?=20 =20 -Tiru. From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Thursday, February 13, 2014 1:00 AM To: Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org; = Marc Blanchet; Dan Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The case where the TURN server is the only option may become common = within enterprise networks and that might be deliberate enterprise = policy because it provides the better path (UDP through the F/W) and = protects the users and the network. =20 Andy =20 =20 From: tram [ = mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 12 February 2014 17:46 To: Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ietf.org; Marc Blanchet; = Dan Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Agree. If TURN is indeed being provided for the user's benefit, the = client's ICE logic (based on RTT or similar) should result in it = preferring the TURN path. =20 On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) = wrote: Yes, I believe the second case is rare, but would be better than a rat = race b/w administrators trying to block p2p traffic and force it through = a TURN server and apps/endpoints finding smarter ways to bypass them. =20 Muthu =20 From: Oleg Moskalenko [mailto: = mom040267@gmail.com]=20 Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; = tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The TURN server has to be used when it is either the only option, or if = it provides a better path (I guess the second case is rather rare). =20 On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) = wrote: +1 =20 Forcing all traffic through a TURN server and expecting it would provide = the best user experience doesn't look the right approach. Instead, if a = path through a TURN server exists and does provide lower RTT, jitter = etc, being able to detect and use (or switch to) that path might be = desirable.. =20 Muthu =20 From: tram [mailto: = tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and = necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by = the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle = routing",need a new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D etc! It is not a mistake, but the very need for this = milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like = MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the = wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication = (SIP at that time). However, its largest flaw/problem is that quality = things were not (could not be?) considered. The method=E2=80=99s very = idea (like all similar methods for getting RTC through ordinary = NAT/Firewalls) is to fool the media through a NAT/Firewall that is = unaware of what is happening. Thus, this is root of quality issues (and = bandwidth allocation optimization) that needs to be dealt with: = Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get = media through (and of course with as good quality as required and = possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D It is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =E2=80=9Cbecause it is all = about bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with = time=E2=80=9D etc., I strongly object! That is wrong and will be very = detrimental for WebRTC usage. We already see it and I can give numerous = examples of how much less quality demanding VoIP is/is not handled = quality wise and that it matters. And, what would be bad considering = quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. (Maybe the Web browser can = detect and encourage this=E2=80=A6)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the = browser that there are good media paths to be used, and that the web = browser automatically can chose those, then let us all understand those, = so we can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the = Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) = is a much bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of = WebRTC. =20 /Karl =20 =20 Fr=C3=A5n: Dan Wing [mailto: dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; = Karl Stahl; tram@ietf.org; Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet < = marc.blanchet@viagenie.ca> wrote: =20 Le 2014-02-11 =C3=A0 00:39, Dan Wing < = dwing@cisco.com> a =C3=A9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti < = juberti@google.com> wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' = path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN = server will do, and the endpoint should prefer TURN candidates over all = others because there might be some functionality / usefulness of TURN = that the user might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl < = karl.stahl@intertex.se> wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto: = tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; = tireddy@icisco.com =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =E2=80=9Cautomatically=E2=80=9D within quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) > - 3^rd The Anycast method below =E2=80=93 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready = answer... An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> = http://postellation.viagenie.ca NAT64/DNS64 open-source --> = http://ecdysis.viagenie.ca STUN/TURN server --> = http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_0068_01CF28B7.FDEE8FF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

On= the side of this TRAM-list, I also got this = question:

> Regarding the enterprise case, I am not = sure I follow your argument.

> Do you = mean that by setting up an enterprise TURN server, and open the firewall = for media over UDP from/to TURN server be the = solution?

--= -- As we all realize, that would of course not help or improve = things

 

Th= e intended solution in the enterprise case has not yet been spelled out = in this TRAM-list discussion, so for better understanding, let me copy a = few things from the discussion in September/October on the RTCWEB-list = and what is (since long) spelled out in the = draft-ietf-rtcweb-use-cases-and-requirements.

 

Fo= r better understanding, I also want to point out that a TURN can have = two interfaces (acting like a router for media between different = networks). This allows to easier understand that can TURN servers can = direct a best media path (rather than just thinking that a TURN service = is a device which media just bounces against at one interface). =

 

An= d, we can also hope for that a TURN server becomes a (common) component = of a firewall, which would allow the firewall to understand that the = media directed to it is RTC and should be prioritized whereby the = firewall can traffic shaped (back-off data traffic that may be filling = its Internet pipe) as well as e.g. set diffserve bits or take other = measures to assist proper quality handling thought the network. (These = are common mechanisms available and used in firewalls/NATs/access = routers, but TURN servers are not yet included such devices.) The same = goes for access routers/default gateways, DPIs in the transport network = itself =E2=80=93 TURN servers included in such points were media can = pass and quality measures applied may/will be very useful to get us = WebRTC media with through networks without quality = destruction.

 

Fr= om the RTCWEB mailing list September 20th (by = me):

An = enterprise network that want to keep a restrictive firewall not allowing = UDP traffic, could provide a real-time path using a TURN server = paralleling the firewall, instead of tunneling RTP through always open = http or https ports resulting in RTP media over TCP =E2=80=93 with = severe quality problems from TCP retransmissions of dropped packets. The = TURN server address is most easily provided in the same way as the IP = address and DNS address. (That would also put the right party in control = =E2=80=93 The network provider (here the enterprise) decides what is = allowed on his network.)

 

The browser should select which = available TURN server address to use in the following priority order, = where ICE could be used to try several:

 

1) TURN server address = configured in the browser by the user (special cases, normally not = used)

2) = TURN server address configured by the network administrator via an = =E2=80=9Cadmin policy template=E2=80=9D

3) TURN server address supplied = by DHCP or similar automatic network method

4) TURN server address being = supplied by the web application"

 

 

An= d from yesterdays(!) http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-req= uirements-14 these enterprise things and necessity are spelled out = in:

 

F19=C2=A0=C2=A0=C2=A0=C2=A0 The = browser must be able to use several STUN and TURN = servers

=C2=A0=C2=A0 = ----------------------------------------------------------------

 

A22

3.3.5.=C2=A0 Simple Video Communication = Service, enterprise aspects

3.3.5.1.=C2=A0 = Description

=C2=A0=C2=A0 This use-case is = similar to the Simple Video Communication = Service

=C2=A0=C2=A0 use-case (Section 3.3.1).

 

=C2=A0=C2=A0 What is added is = aspects when using the service in enterprises.=C2=A0 = ICE

=C2=A0=C2=A0 is assumed in the = further description of this use-case.

 

=C2=A0=C2=A0 An enterprise that uses = a RTCWEB based web application for

=C2=A0=C2=A0 communication desires = to audit all RTCWEB based application sessions

=C2=A0=C2=A0 used from inside the = company towards any external peer.=C2=A0 To be = able

=C2=A0=C2=A0 to do this they deploy = a TURN server that straddles the boundary

=C2=A0=C2=A0 between the internal = and the external network.

 

=C2=A0=C2=A0 The firewall will block = all attempts to use STUN with an external

=C2=A0=C2=A0 destination unless they = go to the enterprise auditing TURN server.

=C2=A0=C2=A0 In cases where = employees are using RTCWEB applications provided by = an

=C2=A0=C2=A0 external service = provider they still want the traffic to stay = inside

=C2=A0=C2=A0 their internal network = and in addition not load the straddling TURN

=C2=A0=C2=A0 server, thus they = deploy a STUN server allowing the RTCWEB client = to

=C2=A0=C2=A0 determine its server = reflexive address on the internal side.=C2=A0 = Thus

=C2=A0=C2=A0 enabling cases where = peers are both on the internal side to connect

=C2=A0=C2=A0 without the traffic = leaving the internal network.=C2=A0 It must be

=C2=A0=C2=A0 possible to configure = the browsers used in the enterprise with

=C2=A0=C2=A0 network specific STUN = and TURN servers.=C2=A0 This should be possible = to

=C2=A0=C2=A0achieve by = auto-configuration methods.=C2=A0 The RTCWEB functionality = will

=C2=A0=C2=A0 need to utilize both = network specific STUN and TURN resources and

=C2=A0=C2=A0 STUN and TURN servers = provisioned by the web application.

3.3.5.2.=C2=A0 Additional = Requirements

=C2=A0=C2=A0 = ----------------------------------------------------------------

=C2=A0=C2=A0 = REQ-ID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DESCRIPTION

=C2=A0=C2=A0 = ----------------------------------------------------------------

=C2=A0=C2=A0 = F20=C2=A0=C2=A0=C2=A0=C2=A0 The browser must support the use of STUN and = TURN

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = servers that are supplied by entities other than

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the = web application (i.e. the network provider).

=C2=A0=C2=A0 = ----------------------------------------------------------------

 

Th= ere are further requirement listed, helping us to understand the need = for auto discovery and a network provided TURN-server should be used to = ENFORCE that media takes that path (and thus, other paths e.g. suggested = by the remote MUST not happen to be used). This is related to the = mobility aspect (valid even without the roaming = idea):

3.3.6.=C2=A0 Simple Video Communication Service, access = change

3.3.6.1.=C2=A0 Description
=C2=A0=C2=A0 This =
use-case is almost identical to the
=C2=A0=C2=A0 Simple =
Video Communication Service use-case (Section 3.3.1).=C2=A0 =
The
=C2=A0=C2=A0 difference is that the user changes network =
access during the
=C2=A0=C2=A0 =
session.
 
=C2=A0=C2=A0 The =
communication device used by one of the users has several =
network
=C2=A0=C2=A0 adapters =
(Ethernet, WiFi, Cellular).=C2=A0 The communication device =
is
=C2=A0=C2=A0 accessing the Internet using Ethernet, but the =
user has to start a
=C2=A0=C2=A0 trip =
during the session.=C2=A0 The communication device =
automatically
=C2=A0=C2=A0 changes =
to use WiFi when the Ethernet cable is removed and then =
moves
=C2=A0=C2=A0 to =
cellular access to the Internet when moving out of WiFi =
coverage.
=C2=A0=C2=A0 The =
session continues even though the access method =
changes.
3.3.6.2.=C2=A0 Additional Requirements
=C2=A0=C2=A0 =
----------------------------------------------------------------
=C2=A0=C2=A0 REQ-ID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
DESCRIPTION
=C2=A0=C2=A0 =
----------------------------------------------------------------
=C2=A0=C2=A0 F17=C2=A0=C2=A0=C2=A0=C2=A0 The communication =
session must survive across a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
change of the network interface used by the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
session
=C2=A0=C2=A0 =
----------------------------------------------------------------

3.3.7.=C2=A0 Simple Video Communication Service, = QoS

3.3.7.1.=C2=A0 Description
=C2=A0=C2=A0 This =
use-case is almost identical to the
=C2=A0=C2=A0 Simple =
Video Communication Service, access change =
use-case
=C2=A0=C2=A0 (Section 3.3.6).=C2=A0 The use of Quality of =
Service (QoS) capabilities is
=C2=A0=C2=A0 =
added:
 
=C2=A0=C2=A0 The user =
in the previous use case that starts a trip is behind =
a
=C2=A0=C2=A0 common residential router that supports =
prioritization of traffic.
=C2=A0=C2=A0 In =
addition, the user's provider of cellular access has QoS =
support
=C2=A0=C2=A0 =
enabled.=C2=A0 The user is able to take advantage of the QoS support =
both
=C2=A0=C2=A0 when =
accessing via the residential router and when using =
cellular.
3.3.7.2.=C2=A0 Additional Requirements
=C2=A0=C2=A0 =
----------------------------------------------------------------
=C2=A0=C2=A0 REQ-ID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
DESCRIPTION
=C2=A0=C2=A0 =
----------------------------------------------------------------
=C2=A0=C2=A0 F17=C2=A0=C2=A0=C2=A0=C2=A0 The communication =
session must survive across a
=C2=A0 =
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0change of the =
network interface used by the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
session
=C2=A0=C2=A0 =
----------------------------------------------------------------
=C2=A0=C2=A0 F22=C2=A0=C2=A0=C2=A0=C2=A0 The browser must be =
able to receive streams and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
data from multiple peers concurrently.
=C2=A0=C2=A0 =
----------------------------------------------------------------

 

Fu= rther from the RTCWEB mailing list September 20th (by = me):

 

There are several reasons for a network service provider to = supply a TURN server as part of his offered = access:

- to keep media paths short, specifically not sending media = outside its own network to some distant application provided TURN = server

- = to support mobility, i.e. you may want to move from a LAN with a = configured TURN server to accessing via WiFi or 3G/4G OTT = channels

- to offer a media path with better quality (than best = effort data traffic).

Getting =E2=80=9CWebRTC-ready=E2=80=9D access and we look = forward to telepresence for everyone.

 

 

I = hope this (a bit lengthy) summary of already thought-out and discussed = aspects/requirements will help us understand that the auto-discovered = TURN server is an ORDER from the enterprise and/or the NSP/ISP =C2=A0to = send the media through this TURN path, and that other media paths that = may exist MUST NOT BE USED. (That is why we especially have to = watch/advice that workable media paths proposed by the remote party not = becomes used =E2=80=9Cby accident=E2=80=9D.

 

/K= arl

 

 

Fr=C3=A5n: = Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] =
Skickat: den 13 februari 2014 04:37
Till: Hutton, = Andrew; Justin Uberti; Muthu Arul Mozhi Perumal = (mperumal)
Kopia: tireddy@icisco.com; Simon Perreault; Oleg = Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing (dwing); Karl = Stahl
=C3=84mne: RE: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

Hi Andy,

 

There are other ways to solve the problem for example using PCP. Can = you clarify how deploying a TURN server in the Enterprise protects the = users and the network ?

 

-Tiru.

From:= tram [mailto:tram-bounces@ietf.org] = On Behalf Of Hutton, Andrew
Sent: Thursday, February = 13, 2014 1:00 AM
To: Justin Uberti; Muthu Arul Mozhi Perumal = (mperumal)
Cc: tireddy@icisco.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing = (dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

The case where the TURN server is the only option may become common = within enterprise networks and that might be deliberate enterprise = policy because it provides the better path (UDP through the F/W) and = protects the users and the network.

 

Andy

 

 

From:= tram = [mailto:tram-= bounces@ietf.org] On = Behalf Of Justin Uberti
Sent: 12 February 2014 = 17:46
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: = tireddy@icis= co.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.or= g; Marc = Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs

 

Agree. If TURN is indeed being provided for the user's = benefit, the client's ICE logic (based on RTT or similar) should result = in it preferring the TURN path.

 

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

Yes, I = believe the second case is rare, but would be better than a rat race b/w = administrators trying to block p2p traffic and force it through a TURN = server and apps/endpoints finding smarter ways to bypass = them.

 

Muthu

 

From:= Oleg = Moskalenko [mailto:mom040267@gm= ail.com] =
Sent: Wednesday, February 12, 2014 1:07 PM
To: = Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl = Stahl; tireddy@icis= co.com; Marc = Blanchet; tram@ietf.or= g; Dan Wing = (dwing); Simon Perreault


Subject: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

The TURN server has to be used when it is either the only = option, or if it provides a better path (I guess the second case is = rather rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would = provide the best user experience doesn't look the right approach. = Instead, if a path through a TURN server exists and does provide lower = RTT, jitter etc, being able to detect and use (or switch to) that path = might be desirable..

 

Muthu

 

From:= tram = [mailto:tram-bounces= @ietf.org] On = Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 = 11:43 AM
To: Karl Stahl
Cc: tireddy@icis= co.com; Marc = Blanchet; tram@ietf.or= g; Dan Wing = (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the right = technology here, compared to a more transparent flow identification tool = like MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for = WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method=E2=80=99s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion point.

 

I think that "fooling" is an incorrect = description. The NAT is supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues =E2=80=9Cbecause it is all about = bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D = etc., I strongly object! That is wrong and will be very detrimental for = WebRTC usage. We already see it and I can give numerous examples of how = much less quality demanding VoIP is/is not handled quality wise and that = it matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this=E2=80=A6) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone.

 

Skype, Hangouts, Facetime are doing billions of minutes per = week and the Internet has not melted yet. If we need to do flow = identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to fade = away with the move to IPv6. I don't think we want to make it a critical = element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=C3=A5n: Dan Wing = [mailto:dwing@cisco.= com] =
Skickat: den 11 februari 2014 18:25
Till: = Marc = Blanchet
Kopia: Justin Uberti; tireddy@icis= co.com; Karl = Stahl; tram@ietf.or= g; Simon = Perreault


=C3=84= mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs

 

 

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

 

Le = 2014-02-11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit :

 


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@go= ogle.com> = wrote:

 

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all).

 

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced privacy)?

 

-d

 

 

 

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these use-cases.

 

-d<= span lang=3DEN-US>

 

 

 

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl= @intertex.se> = wrote:

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounc= es@ietf.org] = F=C3=B6r Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: = Karl Stahl; tram@ietf.= org; tireddy@ic= isco.com
=C3=84= mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =C3=A9crit :
> - Note that to achieve some of the above points, = TURN must be favored
> over STUN to enforce that the TURN-path = actually is used. (The Anycast
> method suggested below, = =E2=80=9Cautomatically=E2=80=9D does this.)

I understand the STUN = vs TURN priority issue. But I don't see how anycast affects it in any = way. Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the =E2=80=9Cautomatically=E2=80=9D within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below =E2=80=93 I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) =E2=80=93 The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://pos= tellation.viagenie.ca
NAT64/= DNS64 open-source        --> http://ecd= ysis.viagenie.ca
STUN/T= URN server               = --> http://num= b.viagenie.ca
______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

__= _____________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

 

<= /div>

 


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

 

 

<= /html> ------=_NextPart_000_0068_01CF28B7.FDEE8FF0-- From karl.stahl@intertex.se Thu Feb 13 03:46:03 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9991A01F8 for ; Thu, 13 Feb 2014 03:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 NKAURBL-4MiF for ; Thu, 13 Feb 2014 03:45:56 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 55E531A01F3 for ; Thu, 13 Feb 2014 03:45:54 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131245503480; Thu, 13 Feb 2014 12:45:50 +0100 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Hutton, Andrew'" , "'Justin Uberti'" , "'Muthu Arul Mozhi Perumal \(mperumal\)'" References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> In-Reply-To: Date: Thu, 13 Feb 2014 12:45:50 +0100 Message-ID: <00cb01cf28b1$24eba860$6ec2f920$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CC_01CF28B9.86B01060" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8obNsCBHZfUz6PQqmEmyo5gqkf2AAIL2iQAAjOOBA= Content-Language: sv X-Mailman-Approved-At: Thu, 13 Feb 2014 05:43:49 -0800 Cc: tireddy@icisco.com, 'Simon Perreault' , 'Oleg Moskalenko' , tram@ietf.org, 'Marc Blanchet' , "'Dan Wing \(dwing\)'" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:46:03 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00CC_01CF28B9.86B01060 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable IMPORTANT CLARIFICATIONS I THINK: =20 On the side of this TRAM-list, I also got this question: > Regarding the enterprise case, I am not sure I follow your argument. > Do you mean that by setting up an enterprise TURN server, and open the = firewall for media over UDP from/to TURN server be the solution? ---- As we all realize, that would of course not help or improve things =20 The intended solution in the enterprise case has not yet been spelled = out in this TRAM-list discussion, so for better understanding, let me = copy a few things from the discussion in September/October on the = RTCWEB-list and what is (since long) spelled out in the = draft-ietf-rtcweb-use-cases-and-requirements. =20 For better understanding, I also want to point out that a TURN can have = two interfaces (acting like a router for media between different = networks). This allows to easier understand that can TURN servers can = direct a best media path (rather than just thinking that a TURN service = is a device which media just bounces against at one interface).=20 =20 And, we can also hope for that a TURN server becomes a (common) = component of a firewall, which would allow the firewall to understand = that the media directed to it is RTC and should be prioritized whereby = the firewall can traffic shaped (back-off data traffic that may be = filling its Internet pipe) as well as e.g. set diffserve bits or take = other measures to assist proper quality handling thought the network. = (These are common mechanisms available and used in firewalls/NATs/access = routers, but TURN servers are not yet included such devices.) The same = goes for access routers/default gateways, DPIs in the transport network = itself =E2=80=93 TURN servers included in such points were media can = pass and quality measures applied may/will be very useful to get us = WebRTC media with through networks without quality destruction. =20 >From the RTCWEB mailing list September 20th (by me): An enterprise network that want to keep a restrictive firewall not = allowing UDP traffic, could provide a real-time path using a TURN server = paralleling the firewall, instead of tunneling RTP through always open = http or https ports resulting in RTP media over TCP =E2=80=93 with = severe quality problems from TCP retransmissions of dropped packets. The = TURN server address is most easily provided in the same way as the IP = address and DNS address. (That would also put the right party in control = =E2=80=93 The network provider (here the enterprise) decides what is = allowed on his network.) =20 The browser should select which available TURN server address to use in = the following priority order, where ICE could be used to try several: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used) 2) TURN server address configured by the network administrator via an = =E2=80=9Cadmin policy template=E2=80=9D 3) TURN server address supplied by DHCP or similar automatic network = method 4) TURN server address being supplied by the web application" =20 =20 And from yesterdays(!) = http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1= 4 these enterprise things and necessity are spelled out in: =20 F19 The browser must be able to use several STUN and TURN servers ---------------------------------------------------------------- =20 A22 = 3.3.5. Simple Video Communication Service, enterprise = aspects = 3.3.5.1. Description This use-case is similar to the Simple Video Communication Service use-case (Section 3.3.1 = ). =20 What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use-case. =20 An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application sessions used from inside the company towards any external peer. To be able to do this they deploy a TURN server that straddles the boundary between the internal and the external network. =20 The firewall will block all attempts to use STUN with an external destination unless they go to the enterprise auditing TURN server. In cases where employees are using RTCWEB applications provided by an external service provider they still want the traffic to stay inside their internal network and in addition not load the straddling TURN server, thus they deploy a STUN server allowing the RTCWEB client to determine its server reflexive address on the internal side. Thus enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possible to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to achieve by auto-configuration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. = 3.3.5.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F20 The browser must support the use of STUN and TURN servers that are supplied by entities other than the web application (i.e. the network provider). ---------------------------------------------------------------- =20 There are further requirement listed, helping us to understand the need = for auto discovery and a network provided TURN-server should be used to = ENFORCE that media takes that path (and thus, other paths e.g. suggested = by the remote MUST not happen to be used). This is related to the = mobility aspect (valid even without the roaming idea): = 3.3.6. Simple Video Communication Service, access = change = 3.3.6.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.3.1 = ). The difference is that the user changes network access during the session. =20 The communication device used by one of the users has several network adapters (Ethernet, WiFi, Cellular). The communication device is accessing the Internet using Ethernet, but the user has to start a trip during the session. The communication device automatically changes to use WiFi when the Ethernet cable is removed and then moves to cellular access to the Internet when moving out of WiFi coverage. The session continues even though the access method changes. = 3.3.6.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- = 3.3.7. Simple Video Communication Service, QoS = 3.3.7.1. Description This use-case is almost identical to the Simple Video Communication Service, access change use-case (Section 3.3.6 = ). The use of Quality of Service (QoS) capabilities = is added: =20 The user in the previous use case that starts a trip is behind a common residential router that supports prioritization of traffic. In addition, the user's provider of cellular access has QoS support enabled. The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular. = 3.3.7.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- F22 The browser must be able to receive streams and data from multiple peers concurrently. ---------------------------------------------------------------- =20 Further from the RTCWEB mailing list September 20th (by me): =20 There are several reasons for a network service provider to supply a = TURN server as part of his offered access: - to keep media paths short, specifically not sending media outside its = own network to some distant application provided TURN server - to support mobility, i.e. you may want to move from a LAN with a = configured TURN server to accessing via WiFi or 3G/4G OTT channels - to offer a media path with better quality (than best effort data = traffic). Getting =E2=80=9CWebRTC-ready=E2=80=9D access and we look forward to = telepresence for everyone. =20 =20 I hope this (a bit lengthy) summary of already thought-out and discussed = aspects/requirements will help us understand that the auto-discovered = TURN server is an ORDER from the enterprise and/or the NSP/ISP to send = the media through this TURN path, and that other media paths that may = exist MUST NOT BE USED. (That is why we especially have to watch/advice = that workable media paths proposed by the remote party not becomes used = =E2=80=9Cby accident=E2=80=9D. =20 /Karl =20 =20 Fr=C3=A5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Skickat: den 13 februari 2014 04:37 Till: Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Kopia: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; = tram@ietf.org; Marc Blanchet; Dan Wing (dwing); Karl Stahl =C3=84mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Hi Andy, =20 There are other ways to solve the problem for example using PCP. Can you = clarify how deploying a TURN server in the Enterprise protects the users = and the network ?=20 =20 -Tiru. From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Thursday, February 13, 2014 1:00 AM To: Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org; = Marc Blanchet; Dan Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The case where the TURN server is the only option may become common = within enterprise networks and that might be deliberate enterprise = policy because it provides the better path (UDP through the F/W) and = protects the users and the network. =20 Andy =20 =20 From: tram [ = mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 12 February 2014 17:46 To: Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ietf.org; Marc Blanchet; = Dan Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Agree. If TURN is indeed being provided for the user's benefit, the = client's ICE logic (based on RTT or similar) should result in it = preferring the TURN path. =20 On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) = wrote: Yes, I believe the second case is rare, but would be better than a rat = race b/w administrators trying to block p2p traffic and force it through = a TURN server and apps/endpoints finding smarter ways to bypass them. =20 Muthu =20 From: Oleg Moskalenko [mailto: = mom040267@gmail.com]=20 Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; = tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The TURN server has to be used when it is either the only option, or if = it provides a better path (I guess the second case is rather rare). =20 On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) = wrote: +1 =20 Forcing all traffic through a TURN server and expecting it would provide = the best user experience doesn't look the right approach. Instead, if a = path through a TURN server exists and does provide lower RTT, jitter = etc, being able to detect and use (or switch to) that path might be = desirable.. =20 Muthu =20 From: tram [mailto: = tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and = necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by = the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle = routing",need a new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D etc! It is not a mistake, but the very need for this = milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like = MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the = wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication = (SIP at that time). However, its largest flaw/problem is that quality = things were not (could not be?) considered. The method=E2=80=99s very = idea (like all similar methods for getting RTC through ordinary = NAT/Firewalls) is to fool the media through a NAT/Firewall that is = unaware of what is happening. Thus, this is root of quality issues (and = bandwidth allocation optimization) that needs to be dealt with: = Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get = media through (and of course with as good quality as required and = possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D It is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =E2=80=9Cbecause it is all = about bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with = time=E2=80=9D etc., I strongly object! That is wrong and will be very = detrimental for WebRTC usage. We already see it and I can give numerous = examples of how much less quality demanding VoIP is/is not handled = quality wise and that it matters. And, what would be bad considering = quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. (Maybe the Web browser can = detect and encourage this=E2=80=A6)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the = browser that there are good media paths to be used, and that the web = browser automatically can chose those, then let us all understand those, = so we can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the = Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) = is a much bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of = WebRTC. =20 /Karl =20 =20 Fr=C3=A5n: Dan Wing [mailto: dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; = Karl Stahl; tram@ietf.org; Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet < = marc.blanchet@viagenie.ca> wrote: =20 Le 2014-02-11 =C3=A0 00:39, Dan Wing < = dwing@cisco.com> a =C3=A9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti < = juberti@google.com> wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' = path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN = server will do, and the endpoint should prefer TURN candidates over all = others because there might be some functionality / usefulness of TURN = that the user might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl < = karl.stahl@intertex.se> wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto: = tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; = tireddy@icisco.com =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =E2=80=9Cautomatically=E2=80=9D within quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) > - 3^rd The Anycast method below =E2=80=93 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready = answer... An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> = http://postellation.viagenie.ca NAT64/DNS64 open-source --> = http://ecdysis.viagenie.ca STUN/TURN server --> = http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_00CC_01CF28B9.86B01060 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

IM= PORTANT CLARIFICATIONS I THINK:

 

On= the side of this TRAM-list, I also got this = question:

> Regarding the enterprise case, I am not = sure I follow your argument.

> Do you = mean that by setting up an enterprise TURN server, and open the firewall = for media over UDP from/to TURN server be the = solution?

--= -- As we all realize, that would of course not help or improve = things

 

Th= e intended solution in the enterprise case has not yet been spelled out = in this TRAM-list discussion, so for better understanding, let me copy a = few things from the discussion in September/October on the RTCWEB-list = and what is (since long) spelled out in the = draft-ietf-rtcweb-use-cases-and-requirements.

 

Fo= r better understanding, I also want to point out that a TURN can have = two interfaces (acting like a router for media between different = networks). This allows to easier understand that can TURN servers can = direct a best media path (rather than just thinking that a TURN service = is a device which media just bounces against at one interface). =

 

An= d, we can also hope for that a TURN server becomes a (common) component = of a firewall, which would allow the firewall to understand that the = media directed to it is RTC and should be prioritized whereby the = firewall can traffic shaped (back-off data traffic that may be filling = its Internet pipe) as well as e.g. set diffserve bits or take other = measures to assist proper quality handling thought the network. (These = are common mechanisms available and used in firewalls/NATs/access = routers, but TURN servers are not yet included such devices.) The same = goes for access routers/default gateways, DPIs in the transport network = itself =E2=80=93 TURN servers included in such points were media can = pass and quality measures applied may/will be very useful to get us = WebRTC media with through networks without quality = destruction.

 

Fr= om the RTCWEB mailing list September 20th (by = me):

An = enterprise network that want to keep a restrictive firewall not allowing = UDP traffic, could provide a real-time path using a TURN server = paralleling the firewall, instead of tunneling RTP through always open = http or https ports resulting in RTP media over TCP =E2=80=93 with = severe quality problems from TCP retransmissions of dropped packets. The = TURN server address is most easily provided in the same way as the IP = address and DNS address. (That would also put the right party in control = =E2=80=93 The network provider (here the enterprise) decides what is = allowed on his network.)

 

The browser should select which = available TURN server address to use in the following priority order, = where ICE could be used to try several:

 

1) TURN server address = configured in the browser by the user (special cases, normally not = used)

2) = TURN server address configured by the network administrator via an = =E2=80=9Cadmin policy template=E2=80=9D

3) TURN server address supplied = by DHCP or similar automatic network method

4) TURN server address being = supplied by the web application"

 

 

An= d from yesterdays(!) http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-req= uirements-14 these enterprise things and necessity are spelled out = in:

 

F19     The = browser must be able to use several STUN and TURN = servers

   = ----------------------------------------------------------------

 

A22

3.3.5.  Simple Video Communication = Service, enterprise aspects

3.3.5.1.  = Description

   This use-case is = similar to the Simple Video Communication = Service

   use-case (Section 3.3.1).

 

   What is added is = aspects when using the service in enterprises.  = ICE

   is assumed in the = further description of this use-case.

 

   An enterprise that uses = a RTCWEB based web application for

   communication desires = to audit all RTCWEB based application sessions

   used from inside the = company towards any external peer.  To be = able

   to do this they deploy = a TURN server that straddles the boundary

   between the internal = and the external network.

 

   The firewall will block = all attempts to use STUN with an external

   destination unless they = go to the enterprise auditing TURN server.

   In cases where = employees are using RTCWEB applications provided by = an

   external service = provider they still want the traffic to stay = inside

   their internal network = and in addition not load the straddling TURN

   server, thus they = deploy a STUN server allowing the RTCWEB client = to

   determine its server = reflexive address on the internal side.  = Thus

   enabling cases where = peers are both on the internal side to connect

   without the traffic = leaving the internal network.  It must be

   possible to configure = the browsers used in the enterprise with

   network specific STUN = and TURN servers.  This should be possible = to

  achieve by = auto-configuration methods.  The RTCWEB functionality = will

   need to utilize both = network specific STUN and TURN resources and

   STUN and TURN servers = provisioned by the web application.

3.3.5.2.  Additional = Requirements

   = ----------------------------------------------------------------

   = REQ-ID      DESCRIPTION

   = ----------------------------------------------------------------

   = F20     The browser must support the use of STUN and = TURN

           = servers that are supplied by entities other than

           the = web application (i.e. the network provider).

   = ----------------------------------------------------------------

 

Th= ere are further requirement listed, helping us to understand the need = for auto discovery and a network provided TURN-server should be used to = ENFORCE that media takes that path (and thus, other paths e.g. suggested = by the remote MUST not happen to be used). This is related to the = mobility aspect (valid even without the roaming = idea):

3.3.6.  Simple Video Communication Service, access = change

3.3.6.1.  Description
   This =
use-case is almost identical to the
   Simple =
Video Communication Service use-case (Section 3.3.1).  =
The
   difference is that the user changes network =
access during the
   =
session.
 
   The =
communication device used by one of the users has several =
network
   adapters =
(Ethernet, WiFi, Cellular).  The communication device =
is
   accessing the Internet using Ethernet, but the =
user has to start a
   trip =
during the session.  The communication device =
automatically
   changes =
to use WiFi when the Ethernet cable is removed and then =
moves
   to =
cellular access to the Internet when moving out of WiFi =
coverage.
   The =
session continues even though the access method =
changes.
3.3.6.2.  Additional Requirements
   =
----------------------------------------------------------------
   REQ-ID      =
DESCRIPTION
   =
----------------------------------------------------------------
   F17     The communication =
session must survive across a
           =
change of the network interface used by the
           =
session
   =
----------------------------------------------------------------

3.3.7.  Simple Video Communication Service, = QoS

3.3.7.1.  Description
   This =
use-case is almost identical to the
   Simple =
Video Communication Service, access change =
use-case
   (Section 3.3.6).  The use of Quality of =
Service (QoS) capabilities is
   =
added:
 
   The user =
in the previous use case that starts a trip is behind =
a
   common residential router that supports =
prioritization of traffic.
   In =
addition, the user's provider of cellular access has QoS =
support
   =
enabled.  The user is able to take advantage of the QoS support =
both
   when =
accessing via the residential router and when using =
cellular.
3.3.7.2.  Additional Requirements
   =
----------------------------------------------------------------
   REQ-ID      =
DESCRIPTION
   =
----------------------------------------------------------------
   F17     The communication =
session must survive across a
  =
         change of the =
network interface used by the
           =
session
   =
----------------------------------------------------------------
   F22     The browser must be =
able to receive streams and
           =
data from multiple peers concurrently.
   =
----------------------------------------------------------------

 

Fu= rther from the RTCWEB mailing list September 20th (by = me):

 

There are several reasons for a network service provider to = supply a TURN server as part of his offered = access:

- to keep media paths short, specifically not sending media = outside its own network to some distant application provided TURN = server

- = to support mobility, i.e. you may want to move from a LAN with a = configured TURN server to accessing via WiFi or 3G/4G OTT = channels

- to offer a media path with better quality (than best = effort data traffic).

Getting =E2=80=9CWebRTC-ready=E2=80=9D access and we look = forward to telepresence for everyone.

 

 

I = hope this (a bit lengthy) summary of already thought-out and discussed = aspects/requirements will help us understand that the auto-discovered = TURN server is an ORDER from the enterprise and/or the NSP/ISP  to = send the media through this TURN path, and that other media paths that = may exist MUST NOT BE USED. (That is why we especially have to = watch/advice that workable media paths proposed by the remote party not = becomes used =E2=80=9Cby accident=E2=80=9D.

 

/K= arl

 

 

Fr=C3=A5n: = Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] =
Skickat: den 13 februari 2014 04:37
Till: Hutton, = Andrew; Justin Uberti; Muthu Arul Mozhi Perumal = (mperumal)
Kopia: tireddy@icisco.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing = (dwing); Karl Stahl
=C3=84mne: RE: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

Hi Andy,

 

There are other ways to solve the problem for example using PCP. Can = you clarify how deploying a TURN server in the Enterprise protects the = users and the network ?

 

-Tiru.

From:= tram [mailto:tram-bounces@ietf.org] = On Behalf Of Hutton, Andrew
Sent: Thursday, February = 13, 2014 1:00 AM
To: Justin Uberti; Muthu Arul Mozhi Perumal = (mperumal)
Cc: tireddy@icisco.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing = (dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

The case where the TURN server is the only option may become common = within enterprise networks and that might be deliberate enterprise = policy because it provides the better path (UDP through the F/W) and = protects the users and the network.

 

Andy

 

 

From:= tram = [mailto:tram-= bounces@ietf.org] On = Behalf Of Justin Uberti
Sent: 12 February 2014 = 17:46
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: = tireddy@icis= co.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.or= g; Marc = Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs

 

Agree. If TURN is indeed being provided for the user's = benefit, the client's ICE logic (based on RTT or similar) should result = in it preferring the TURN path.

 

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

Yes, I = believe the second case is rare, but would be better than a rat race b/w = administrators trying to block p2p traffic and force it through a TURN = server and apps/endpoints finding smarter ways to bypass = them.

 

Muthu

 

From:= Oleg = Moskalenko [mailto:mom040267@gm= ail.com] =
Sent: Wednesday, February 12, 2014 1:07 PM
To: = Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl = Stahl; tireddy@icis= co.com; Marc = Blanchet; tram@ietf.or= g; Dan Wing = (dwing); Simon Perreault


Subject: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

The TURN server has to be used when it is either the only = option, or if it provides a better path (I guess the second case is = rather rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would = provide the best user experience doesn't look the right approach. = Instead, if a path through a TURN server exists and does provide lower = RTT, jitter etc, being able to detect and use (or switch to) that path = might be desirable..

 

Muthu

 

From:= tram = [mailto:tram-bounces= @ietf.org] On = Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 = 11:43 AM
To: Karl Stahl
Cc: tireddy@icis= co.com; Marc = Blanchet; tram@ietf.or= g; Dan Wing = (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the right = technology here, compared to a more transparent flow identification tool = like MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for = WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method=E2=80=99s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion point.

 

I think that "fooling" is an incorrect = description. The NAT is supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues =E2=80=9Cbecause it is all about = bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D = etc., I strongly object! That is wrong and will be very detrimental for = WebRTC usage. We already see it and I can give numerous examples of how = much less quality demanding VoIP is/is not handled quality wise and that = it matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this=E2=80=A6) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone.

 

Skype, Hangouts, Facetime are doing billions of minutes per = week and the Internet has not melted yet. If we need to do flow = identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to fade = away with the move to IPv6. I don't think we want to make it a critical = element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=C3=A5n: Dan Wing = [mailto:dwing@cisco.= com] =
Skickat: den 11 februari 2014 18:25
Till: = Marc = Blanchet
Kopia: Justin Uberti; tireddy@icis= co.com; Karl = Stahl; tram@ietf.or= g; Simon = Perreault


=C3=84= mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs

 

 

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

 

Le = 2014-02-11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit :

 


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@go= ogle.com> = wrote:

 

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all).

 

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced privacy)?

 

-d

 

 

 

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these use-cases.

 

-d<= span lang=3DEN-US>

 

 

 

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl= @intertex.se> = wrote:

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounc= es@ietf.org] = F=C3=B6r Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: = Karl Stahl; tram@ietf.= org; tireddy@ic= isco.com
=C3=84= mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =C3=A9crit :
> - Note that to achieve some of the above points, = TURN must be favored
> over STUN to enforce that the TURN-path = actually is used. (The Anycast
> method suggested below, = =E2=80=9Cautomatically=E2=80=9D does this.)

I understand the STUN = vs TURN priority issue. But I don't see how anycast affects it in any = way. Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the =E2=80=9Cautomatically=E2=80=9D within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below =E2=80=93 I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) =E2=80=93 The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://pos= tellation.viagenie.ca
NAT64/= DNS64 open-source        --> http://ecd= ysis.viagenie.ca
STUN/T= URN server               = --> http://num= b.viagenie.ca
______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

__= _____________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

 

<= /div>

 


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

 

 

<= /html> ------=_NextPart_000_00CC_01CF28B9.86B01060-- From karl.stahl@intertex.se Thu Feb 13 04:04:36 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD301A01AE for ; Thu, 13 Feb 2014 04:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 AloqkMgFA6NI for ; Thu, 13 Feb 2014 04:04:30 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id E75211A0201 for ; Thu, 13 Feb 2014 04:04:28 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402131304247703; Thu, 13 Feb 2014 13:04:24 +0100 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Hutton, Andrew'" , "'Justin Uberti'" , "'Muthu Arul Mozhi Perumal \(mperumal\)'" References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> In-Reply-To: Date: Thu, 13 Feb 2014 13:04:24 +0100 Message-ID: <00da01cf28b3$bcefe890$36cfb9b0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DB_01CF28BC.1EB477A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8obNsCBHZfUz6PQqmEmyo5gqkf2AAIL2iQAAjOOBAAAIbQ0A== Content-Language: sv X-Mailman-Approved-At: Thu, 13 Feb 2014 05:43:49 -0800 Cc: tireddy@icisco.com, 'Simon Perreault' , 'Oleg Moskalenko' , tram@ietf.org, 'Marc Blanchet' , "'Dan Wing \(dwing\)'" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 12:04:36 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00DB_01CF28BC.1EB477A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Note that some things being questioned in this discussion already are in = the draft-ietf-rtcweb-use-cases-and-requirements document (pointed out = below). I think this may clarify some things also=E2=80=A6 =20 =20 On the side of this TRAM-list, I also got this question: > Regarding the enterprise case, I am not sure I follow your argument. > Do you mean that by setting up an enterprise TURN server, and open the = firewall for media over UDP from/to TURN server be the solution? ---- As we all realize, that would of course not help or improve things =20 The intended solution in the enterprise case has not yet been spelled = out in this TRAM-list discussion, so for better understanding, let me = copy a few things from the discussion in September/October on the = RTCWEB-list and what is (since long) spelled out in the = draft-ietf-rtcweb-use-cases-and-requirements. =20 For better understanding, I also want to point out that a TURN can have = two interfaces (acting like a router for media between different = networks). This allows to easier understand that can TURN servers can = direct a best media path (rather than just thinking that a TURN service = is a device which media just bounces against at one interface).=20 =20 And, we can also hope for that a TURN server becomes a (common) = component of a firewall, which would allow the firewall to understand = that the media directed to it is RTC and should be prioritized whereby = the firewall can traffic shaped (back-off data traffic that may be = filling its Internet pipe) as well as e.g. set diffserve bits or take = other measures to assist proper quality handling thought the network. = (These are common mechanisms available and used in firewalls/NATs/access = routers, but TURN servers are not yet included such devices.) The same = goes for access routers/default gateways, DPIs in the transport network = itself =E2=80=93 TURN servers included in such points were media can = pass and quality measures applied may/will be very useful to get us = WebRTC media with through networks without quality destruction. =20 >From the RTCWEB mailing list September 20th (by me): An enterprise network that want to keep a restrictive firewall not = allowing UDP traffic, could provide a real-time path using a TURN server = paralleling the firewall, instead of tunneling RTP through always open = http or https ports resulting in RTP media over TCP =E2=80=93 with = severe quality problems from TCP retransmissions of dropped packets. The = TURN server address is most easily provided in the same way as the IP = address and DNS address. (That would also put the right party in control = =E2=80=93 The network provider (here the enterprise) decides what is = allowed on his network.) =20 The browser should select which available TURN server address to use in = the following priority order, where ICE could be used to try several: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used) 2) TURN server address configured by the network administrator via an = =E2=80=9Cadmin policy template=E2=80=9D 3) TURN server address supplied by DHCP or similar automatic network = method 4) TURN server address being supplied by the web application" =20 =20 And from yesterdays(!) = http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1= 4 these enterprise things and necessity are spelled out in: =20 F19 The browser must be able to use several STUN and TURN servers ---------------------------------------------------------------- =20 A22 = 3.3.5. Simple Video Communication Service, enterprise = aspects = 3.3.5.1. Description This use-case is similar to the Simple Video Communication Service use-case (Section 3.3.1 = ). =20 What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use-case. =20 An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application sessions used from inside the company towards any external peer. To be able to do this they deploy a TURN server that straddles the boundary between the internal and the external network. =20 The firewall will block all attempts to use STUN with an external destination unless they go to the enterprise auditing TURN server. In cases where employees are using RTCWEB applications provided by an external service provider they still want the traffic to stay inside their internal network and in addition not load the straddling TURN server, thus they deploy a STUN server allowing the RTCWEB client to determine its server reflexive address on the internal side. Thus enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possible to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to achieve by auto-configuration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. = 3.3.5.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F20 The browser must support the use of STUN and TURN servers that are supplied by entities other than the web application (i.e. the network provider). ---------------------------------------------------------------- =20 There are further requirement listed, helping us to understand the need = for auto discovery and a network provided TURN-server should be used to = ENFORCE that media takes that path (and thus, other paths e.g. suggested = by the remote MUST not happen to be used). This is related to the = mobility aspect (valid even without the roaming idea): = 3.3.6. Simple Video Communication Service, access = change = 3.3.6.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.3.1 = ). The difference is that the user changes network access during the session. =20 The communication device used by one of the users has several network adapters (Ethernet, WiFi, Cellular). The communication device is accessing the Internet using Ethernet, but the user has to start a trip during the session. The communication device automatically changes to use WiFi when the Ethernet cable is removed and then moves to cellular access to the Internet when moving out of WiFi coverage. The session continues even though the access method changes. = 3.3.6.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- = 3.3.7. Simple Video Communication Service, QoS = 3.3.7.1. Description This use-case is almost identical to the Simple Video Communication Service, access change use-case (Section 3.3.6 = ). The use of Quality of Service (QoS) capabilities = is added: =20 The user in the previous use case that starts a trip is behind a common residential router that supports prioritization of traffic. In addition, the user's provider of cellular access has QoS support enabled. The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular. = 3.3.7.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- F22 The browser must be able to receive streams and data from multiple peers concurrently. ---------------------------------------------------------------- =20 Further from the RTCWEB mailing list September 20th (by me): =20 There are several reasons for a network service provider to supply a = TURN server as part of his offered access: - to keep media paths short, specifically not sending media outside its = own network to some distant application provided TURN server - to support mobility, i.e. you may want to move from a LAN with a = configured TURN server to accessing via WiFi or 3G/4G OTT channels - to offer a media path with better quality (than best effort data = traffic). Getting =E2=80=9CWebRTC-ready=E2=80=9D access and we look forward to = telepresence for everyone. =20 =20 I hope this (a bit lengthy) summary of already thought-out and discussed = aspects/requirements will help us understand that the auto-discovered = TURN server is an ORDER from the enterprise and/or the NSP/ISP to send = the media through this TURN path, and that other media paths that may = exist MUST NOT BE USED. (That is why we especially have to watch/advice = that workable media paths proposed by the remote party not becomes used = =E2=80=9Cby accident=E2=80=9D. =20 /Karl =20 =20 Fr=C3=A5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Skickat: den 13 februari 2014 04:37 Till: Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Kopia: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; = tram@ietf.org; Marc Blanchet; Dan Wing (dwing); Karl Stahl =C3=84mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Hi Andy, =20 There are other ways to solve the problem for example using PCP. Can you = clarify how deploying a TURN server in the Enterprise protects the users = and the network ?=20 =20 -Tiru. From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Thursday, February 13, 2014 1:00 AM To: Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org; = Marc Blanchet; Dan Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The case where the TURN server is the only option may become common = within enterprise networks and that might be deliberate enterprise = policy because it provides the better path (UDP through the F/W) and = protects the users and the network. =20 Andy =20 =20 From: tram [ = mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 12 February 2014 17:46 To: Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ietf.org; Marc Blanchet; = Dan Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Agree. If TURN is indeed being provided for the user's benefit, the = client's ICE logic (based on RTT or similar) should result in it = preferring the TURN path. =20 On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) = wrote: Yes, I believe the second case is rare, but would be better than a rat = race b/w administrators trying to block p2p traffic and force it through = a TURN server and apps/endpoints finding smarter ways to bypass them. =20 Muthu =20 From: Oleg Moskalenko [mailto: = mom040267@gmail.com]=20 Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; = tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The TURN server has to be used when it is either the only option, or if = it provides a better path (I guess the second case is rather rare). =20 On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) = wrote: +1 =20 Forcing all traffic through a TURN server and expecting it would provide = the best user experience doesn't look the right approach. Instead, if a = path through a TURN server exists and does provide lower RTT, jitter = etc, being able to detect and use (or switch to) that path might be = desirable.. =20 Muthu =20 From: tram [mailto: = tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and = necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by = the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle = routing",need a new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D etc! It is not a mistake, but the very need for this = milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like = MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the = wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication = (SIP at that time). However, its largest flaw/problem is that quality = things were not (could not be?) considered. The method=E2=80=99s very = idea (like all similar methods for getting RTC through ordinary = NAT/Firewalls) is to fool the media through a NAT/Firewall that is = unaware of what is happening. Thus, this is root of quality issues (and = bandwidth allocation optimization) that needs to be dealt with: = Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get = media through (and of course with as good quality as required and = possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D It is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =E2=80=9Cbecause it is all = about bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with = time=E2=80=9D etc., I strongly object! That is wrong and will be very = detrimental for WebRTC usage. We already see it and I can give numerous = examples of how much less quality demanding VoIP is/is not handled = quality wise and that it matters. And, what would be bad considering = quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. (Maybe the Web browser can = detect and encourage this=E2=80=A6)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the = browser that there are good media paths to be used, and that the web = browser automatically can chose those, then let us all understand those, = so we can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the = Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) = is a much bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of = WebRTC. =20 /Karl =20 =20 Fr=C3=A5n: Dan Wing [mailto: dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; = Karl Stahl; tram@ietf.org; Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet < = marc.blanchet@viagenie.ca> wrote: =20 Le 2014-02-11 =C3=A0 00:39, Dan Wing < = dwing@cisco.com> a =C3=A9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti < = juberti@google.com> wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' = path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN = server will do, and the endpoint should prefer TURN candidates over all = others because there might be some functionality / usefulness of TURN = that the user might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl < = karl.stahl@intertex.se> wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto: = tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; = tireddy@icisco.com =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =E2=80=9Cautomatically=E2=80=9D within quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) > - 3^rd The Anycast method below =E2=80=93 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready = answer... An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> = http://postellation.viagenie.ca NAT64/DNS64 open-source --> = http://ecdysis.viagenie.ca STUN/TURN server --> = http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_00DB_01CF28BC.1EB477A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

No= te that some things being questioned in this discussion already are in = the draft-ietf-rtcweb-use-cases-and-requirements document (pointed out = below). I think this may clarify some things = also=E2=80=A6

 

 

On= the side of this TRAM-list, I also got this = question:

> Regarding the enterprise case, I am not = sure I follow your argument.

> Do you = mean that by setting up an enterprise TURN server, and open the firewall = for media over UDP from/to TURN server be the = solution?

--= -- As we all realize, that would of course not help or improve = things

 

Th= e intended solution in the enterprise case has not yet been spelled out = in this TRAM-list discussion, so for better understanding, let me copy a = few things from the discussion in September/October on the RTCWEB-list = and what is (since long) spelled out in the = draft-ietf-rtcweb-use-cases-and-requirements.

 

Fo= r better understanding, I also want to point out that a TURN can have = two interfaces (acting like a router for media between different = networks). This allows to easier understand that can TURN servers can = direct a best media path (rather than just thinking that a TURN service = is a device which media just bounces against at one interface). =

 

An= d, we can also hope for that a TURN server becomes a (common) component = of a firewall, which would allow the firewall to understand that the = media directed to it is RTC and should be prioritized whereby the = firewall can traffic shaped (back-off data traffic that may be filling = its Internet pipe) as well as e.g. set diffserve bits or take other = measures to assist proper quality handling thought the network. (These = are common mechanisms available and used in firewalls/NATs/access = routers, but TURN servers are not yet included such devices.) The same = goes for access routers/default gateways, DPIs in the transport network = itself =E2=80=93 TURN servers included in such points were media can = pass and quality measures applied may/will be very useful to get us = WebRTC media with through networks without quality = destruction.

 

Fr= om the RTCWEB mailing list September 20th (by = me):

An = enterprise network that want to keep a restrictive firewall not allowing = UDP traffic, could provide a real-time path using a TURN server = paralleling the firewall, instead of tunneling RTP through always open = http or https ports resulting in RTP media over TCP =E2=80=93 with = severe quality problems from TCP retransmissions of dropped packets. The = TURN server address is most easily provided in the same way as the IP = address and DNS address. (That would also put the right party in control = =E2=80=93 The network provider (here the enterprise) decides what is = allowed on his network.)

 

The browser should select which = available TURN server address to use in the following priority order, = where ICE could be used to try several:

 

1) TURN server address = configured in the browser by the user (special cases, normally not = used)

2) = TURN server address configured by the network administrator via an = =E2=80=9Cadmin policy template=E2=80=9D

3) TURN server address supplied = by DHCP or similar automatic network method

4) TURN server address being = supplied by the web application"

 

 

An= d from yesterdays(!) http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-req= uirements-14 these enterprise things and necessity are spelled out = in:

 

F19     The = browser must be able to use several STUN and TURN = servers

   = ----------------------------------------------------------------

 

A22

3.3.5.  Simple Video Communication = Service, enterprise aspects

3.3.5.1.  = Description

   This use-case is = similar to the Simple Video Communication = Service

   use-case (Section 3.3.1).

 

   What is added is = aspects when using the service in enterprises.  = ICE

   is assumed in the = further description of this use-case.

 

   An enterprise that uses = a RTCWEB based web application for

   communication desires = to audit all RTCWEB based application sessions

   used from inside the = company towards any external peer.  To be = able

   to do this they deploy = a TURN server that straddles the boundary

   between the internal = and the external network.

 

   The firewall will block = all attempts to use STUN with an external

   destination unless they = go to the enterprise auditing TURN server.

   In cases where = employees are using RTCWEB applications provided by = an

   external service = provider they still want the traffic to stay = inside

   their internal network = and in addition not load the straddling TURN

   server, thus they = deploy a STUN server allowing the RTCWEB client = to

   determine its server = reflexive address on the internal side.  = Thus

   enabling cases where = peers are both on the internal side to connect

   without the traffic = leaving the internal network.  It must be

   possible to configure = the browsers used in the enterprise with

   network specific STUN = and TURN servers.  This should be possible = to

  achieve by = auto-configuration methods.  The RTCWEB functionality = will

   need to utilize both = network specific STUN and TURN resources and

   STUN and TURN servers = provisioned by the web application.

3.3.5.2.  Additional = Requirements

   = ----------------------------------------------------------------

   = REQ-ID      DESCRIPTION

   = ----------------------------------------------------------------

   = F20     The browser must support the use of STUN and = TURN

           = servers that are supplied by entities other than

           the = web application (i.e. the network provider).

   = ----------------------------------------------------------------

 

Th= ere are further requirement listed, helping us to understand the need = for auto discovery and a network provided TURN-server should be used to = ENFORCE that media takes that path (and thus, other paths e.g. suggested = by the remote MUST not happen to be used). This is related to the = mobility aspect (valid even without the roaming = idea):

3.3.6.  Simple Video Communication Service, access = change

3.3.6.1.  Description
   This =
use-case is almost identical to the
   Simple =
Video Communication Service use-case (Section 3.3.1).  =
The
   difference is that the user changes network =
access during the
   =
session.
 
   The =
communication device used by one of the users has several =
network
   adapters =
(Ethernet, WiFi, Cellular).  The communication device =
is
   accessing the Internet using Ethernet, but the =
user has to start a
   trip =
during the session.  The communication device =
automatically
   changes =
to use WiFi when the Ethernet cable is removed and then =
moves
   to =
cellular access to the Internet when moving out of WiFi =
coverage.
   The =
session continues even though the access method =
changes.
3.3.6.2.  Additional Requirements
   =
----------------------------------------------------------------
   REQ-ID      =
DESCRIPTION
   =
----------------------------------------------------------------
   F17     The communication =
session must survive across a
           =
change of the network interface used by the
           =
session
   =
----------------------------------------------------------------

3.3.7.  Simple Video Communication Service, = QoS

3.3.7.1.  Description
   This =
use-case is almost identical to the
   Simple =
Video Communication Service, access change =
use-case
   (Section 3.3.6).  The use of Quality of =
Service (QoS) capabilities is
   =
added:
 
   The user =
in the previous use case that starts a trip is behind =
a
   common residential router that supports =
prioritization of traffic.
   In =
addition, the user's provider of cellular access has QoS =
support
   =
enabled.  The user is able to take advantage of the QoS support =
both
   when =
accessing via the residential router and when using =
cellular.
3.3.7.2.  Additional Requirements
   =
----------------------------------------------------------------
   REQ-ID      =
DESCRIPTION
   =
----------------------------------------------------------------
   F17     The communication =
session must survive across a
  =
         change of the =
network interface used by the
           =
session
   =
----------------------------------------------------------------
   F22     The browser must be =
able to receive streams and
           =
data from multiple peers concurrently.
   =
----------------------------------------------------------------

 

Fu= rther from the RTCWEB mailing list September 20th (by = me):

 

There are several reasons for a network service provider to = supply a TURN server as part of his offered = access:

- to keep media paths short, specifically not sending media = outside its own network to some distant application provided TURN = server

- = to support mobility, i.e. you may want to move from a LAN with a = configured TURN server to accessing via WiFi or 3G/4G OTT = channels

- to offer a media path with better quality (than best = effort data traffic).

Getting =E2=80=9CWebRTC-ready=E2=80=9D access and we look = forward to telepresence for everyone.

 

 

I = hope this (a bit lengthy) summary of already thought-out and discussed = aspects/requirements will help us understand that the auto-discovered = TURN server is an ORDER from the enterprise and/or the NSP/ISP  to = send the media through this TURN path, and that other media paths that = may exist MUST NOT BE USED. (That is why we especially have to = watch/advice that workable media paths proposed by the remote party not = becomes used =E2=80=9Cby accident=E2=80=9D.

 

/K= arl

 

 

Fr=C3=A5n: = Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] =
Skickat: den 13 februari 2014 04:37
Till: Hutton, = Andrew; Justin Uberti; Muthu Arul Mozhi Perumal = (mperumal)
Kopia: tireddy@icisco.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing = (dwing); Karl Stahl
=C3=84mne: RE: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

Hi Andy,

 

There are other ways to solve the problem for example using PCP. Can = you clarify how deploying a TURN server in the Enterprise protects the = users and the network ?

 

-Tiru.

From:= tram [mailto:tram-bounces@ietf.org] = On Behalf Of Hutton, Andrew
Sent: Thursday, February = 13, 2014 1:00 AM
To: Justin Uberti; Muthu Arul Mozhi Perumal = (mperumal)
Cc: tireddy@icisco.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing = (dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

The case where the TURN server is the only option may become common = within enterprise networks and that might be deliberate enterprise = policy because it provides the better path (UDP through the F/W) and = protects the users and the network.

 

Andy

 

 

From:= tram = [mailto:tram-= bounces@ietf.org] On = Behalf Of Justin Uberti
Sent: 12 February 2014 = 17:46
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: = tireddy@icis= co.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.or= g; Marc = Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs

 

Agree. If TURN is indeed being provided for the user's = benefit, the client's ICE logic (based on RTT or similar) should result = in it preferring the TURN path.

 

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

Yes, I = believe the second case is rare, but would be better than a rat race b/w = administrators trying to block p2p traffic and force it through a TURN = server and apps/endpoints finding smarter ways to bypass = them.

 

Muthu

 

From:= Oleg = Moskalenko [mailto:mom040267@gm= ail.com] =
Sent: Wednesday, February 12, 2014 1:07 PM
To: = Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl = Stahl; tireddy@icis= co.com; Marc = Blanchet; tram@ietf.or= g; Dan Wing = (dwing); Simon Perreault


Subject: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

The TURN server has to be used when it is either the only = option, or if it provides a better path (I guess the second case is = rather rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would = provide the best user experience doesn't look the right approach. = Instead, if a path through a TURN server exists and does provide lower = RTT, jitter etc, being able to detect and use (or switch to) that path = might be desirable..

 

Muthu

 

From:= tram = [mailto:tram-bounces= @ietf.org] On = Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 = 11:43 AM
To: Karl Stahl
Cc: tireddy@icis= co.com; Marc = Blanchet; tram@ietf.or= g; Dan Wing = (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the right = technology here, compared to a more transparent flow identification tool = like MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for = WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method=E2=80=99s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion point.

 

I think that "fooling" is an incorrect = description. The NAT is supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues =E2=80=9Cbecause it is all about = bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D = etc., I strongly object! That is wrong and will be very detrimental for = WebRTC usage. We already see it and I can give numerous examples of how = much less quality demanding VoIP is/is not handled quality wise and that = it matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this=E2=80=A6) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone.

 

Skype, Hangouts, Facetime are doing billions of minutes per = week and the Internet has not melted yet. If we need to do flow = identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to fade = away with the move to IPv6. I don't think we want to make it a critical = element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=C3=A5n: Dan Wing = [mailto:dwing@cisco.= com] =
Skickat: den 11 februari 2014 18:25
Till: = Marc = Blanchet
Kopia: Justin Uberti; tireddy@icis= co.com; Karl = Stahl; tram@ietf.or= g; Simon = Perreault


=C3=84= mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs

 

 

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

 

Le = 2014-02-11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit :

 


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@go= ogle.com> = wrote:

 

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all).

 

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced privacy)?

 

-d

 

 

 

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these use-cases.

 

-d<= span lang=3DEN-US>

 

 

 

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl= @intertex.se> = wrote:

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounc= es@ietf.org] = F=C3=B6r Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: = Karl Stahl; tram@ietf.= org; tireddy@ic= isco.com
=C3=84= mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =C3=A9crit :
> - Note that to achieve some of the above points, = TURN must be favored
> over STUN to enforce that the TURN-path = actually is used. (The Anycast
> method suggested below, = =E2=80=9Cautomatically=E2=80=9D does this.)

I understand the STUN = vs TURN priority issue. But I don't see how anycast affects it in any = way. Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the =E2=80=9Cautomatically=E2=80=9D within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below =E2=80=93 I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) =E2=80=93 The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://pos= tellation.viagenie.ca
NAT64/= DNS64 open-source        --> http://ecd= ysis.viagenie.ca
STUN/T= URN server               = --> http://num= b.viagenie.ca
______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

__= _____________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

 

<= /div>

 


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

 

 

<= /html> ------=_NextPart_000_00DB_01CF28BC.1EB477A0-- From simon.perreault@viagenie.ca Thu Feb 13 06:17:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9441A0273 for ; Thu, 13 Feb 2014 06:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 Zlp3b-WY3Jcp for ; Thu, 13 Feb 2014 06:17:09 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 390161A0237 for ; Thu, 13 Feb 2014 06:17:09 -0800 (PST) Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D88C140222 for ; Thu, 13 Feb 2014 09:17:07 -0500 (EST) Message-ID: <52FCD3E3.5060301@viagenie.ca> Date: Thu, 13 Feb 2014 09:17:07 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> <9F33F40F6F2CD847824537F3C4E37DDF17CF2EDD@MCHP04MSX.global-ad.net> <913383AAA69FF945B8F946018B75898A242AD1F4@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242AD1F4@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:17:11 -0000 Le 2014-02-12 22:40, Tirumaleswar Reddy (tireddy) a écrit : > There are other ways to solve the problem for example using PCP. True. > Can you clarify how deploying a TURN server in the Enterprise > protects the users and the network ? IMHO that's not the right question to ask. It is pretty clear to me that, technically, TURN does indeed have the potential to solve the problem identified by Karl. (I understand the problem to be: "ISP wants to provide enhanced QoS to WebRTC.") I have two questions in my mind: a) Is this a real problem that is worth fixing? b) Is TURN the best, most appropriate solution? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From palmarti@cisco.com Thu Feb 13 06:40:38 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630361A02A1 for ; Thu, 13 Feb 2014 06:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ZFrQ3NlL5v_Z for ; Thu, 13 Feb 2014 06:40:33 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9801A02A4 for ; Thu, 13 Feb 2014 06:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2988; q=dns/txt; s=iport; t=1392302431; x=1393512031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wHwM7zX2zSPbLQdQWArravSYYgwofSOi9kUHNorGpgw=; b=FC796uqjAIOebE30CFiAHsNICQWFZDx/9DHwajiWQxKepR5FTt+zgCAB PiUmMseUS9AQ4ewsAEnIyNzDbAmtUtyd7ChFt/mU4Zr/dLUhkR9hurp84 l80AMlj4RUaZg7yUt2MfA/un1TFgx+OKi72TQ3gxkJqZWhS4G0LiEWpmf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8FAAHZ/FKtJXG+/2dsb2JhbABZgwY4V79MgRYWdIIlAQEBAwEBAQEkRwsFCwIBCEYnCyUCBA4FG4diCA3HeheORjMHgySBFASYLIEykHGBb4E+gio X-IronPort-AV: E=Sophos;i="4.95,838,1384300800"; d="scan'208";a="20173826" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-2.cisco.com with ESMTP; 13 Feb 2014 14:40:31 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1DEeVeR001304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 14:40:31 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.65]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 08:40:31 -0600 From: "Pal Martinsen (palmarti)" To: "tram@ietf.org" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPJ7mlTNEKdEV/S06oVknK3f+v9pqxnjCAgAABbgCAAB7xgIAAizSAgAAdCoCAAIjhgIAAsgGAgAAGhYA= Date: Thu, 13 Feb 2014 14:40:30 +0000 Message-ID: <54984825-37D2-4C21-A0CF-F03C6D30162D@cisco.com> References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> <9F33F40F6F2CD847824537F3C4E37DDF17CF2EDD@MCHP04MSX.global-ad.net> <913383AAA69FF945B8F946018B75898A242AD1F4@xmb-rcd-x10.cisco.com> <52FCD3E3.5060301@viagenie.ca> In-Reply-To: <52FCD3E3.5060301@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.70] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:40:38 -0000 On 13 Feb 2014, at 15:17 pm, Simon Perreault = wrote: > Le 2014-02-12 22:40, Tirumaleswar Reddy (tireddy) a =E9crit : >> There are other ways to solve the problem for example using PCP. >=20 > True. >=20 >> Can you clarify how deploying a TURN server in the Enterprise >> protects the users and the network ? >=20 > IMHO that's not the right question to ask. It is pretty clear to me > that, technically, TURN does indeed have the potential to solve the > problem identified by Karl. (I understand the problem to be: "ISP wants > to provide enhanced QoS to WebRTC.") >=20 > I have two questions in my mind: >=20 > a) Is this a real problem that is worth fixing? Yes.. But not just QoS. There should be some kind fairness and =93share the= resources=94 so everyone can get the best result. If the link is getting c= rowed it would be nice of the endpoint than can would for example reduce it= s bandwidth by dropping from 1080p to 720p. Tis have some impact on user ex= perience, but uses half the bandwidth.=20 I would like us to move away from hard reservations as that does not give u= s the best usage of a scarce resource (bandwidth) as video codecs are very = elastic in its nature and it would be hard to know how much bandwidth to al= locate for a video stream.=20 But i might be dreaming. > b) Is TURN the best, most appropriate solution? >=20 Probably a part of the solution, It is a nice way of =93forcing=94 media th= rough a certain path. But I think that path only should be chosen by the en= dpoint if that is the best(*1) path. (*1) For certain values of best.. I have been planning to write a draft: POLICE, Path Optimisation done Local= ly with ICE. But that probably belongs to MMUSIC. But to get that of the gr= ound we need to figure out how to get more information from the network reg= arding bandwidth, cost and other decisions that might influence the path se= lection. (RTT we get from the connectivity checks). That would be something= for the TRAM WG to figure out.. (And maybe the PCP WG) Another thing to remember is that webRTC is probably going to use Trickle-I= CE. In clear that means the host candidates will be tested as soon as they = are ready. The rest of the candidate discovery might happen in parallel or = after. This might affect how we discover the available TURN servers. Due to security concerns the webRTC also severely limits the speed the conn= ectivity checks happen. So unless Trickle ICE is in use it is good to keep = the number o candidates to a minimum. =20 .-. P=E5l-Erik > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From tireddy@cisco.com Thu Feb 13 07:34:21 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197711A02D7 for ; Thu, 13 Feb 2014 07:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Pyg3vIQnKzN3 for ; Thu, 13 Feb 2014 07:34:14 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A95731A02D6 for ; Thu, 13 Feb 2014 07:34:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=105464; q=dns/txt; s=iport; t=1392305653; x=1393515253; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mnTySic3QkW80gA5pF3HGdGRu7/yI+t7r7+C/vRH+UM=; b=Fiz3QoaP17FZzXBDZucBsNzkZ4AB54UkcsRME/y6endI0aBrP1zBcocZ kC7+4u5GwpFKz8i1nIeq7MxumEwD+Ad1MQ2PQ8yNBOyooIFltueljIeYY 1nv36TXehVlWz9kETi1kYnIikkUkffSPyeMrPdcM4rHV8WpLUtaPagYr5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4IAMvk/FKtJXHA/2dsb2JhbABPCoJCRDhXgwCndYwDiFQYfxZ0giUBAQEDAQEBARcBCAQGOgUCBAQDBQsCAQgRBAEBCxYBBgMCAgIfBgsUCQgBAQQOBQgTh1YDCQgNpVmZYA2IPBeMX4EuEA4dFhcEBgEJgmY1gRQElkCDHosshUWBb4E+gXE5 X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="scan'208,217";a="303859520" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 13 Feb 2014 15:34:11 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1DFYBPI012150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 15:34:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 09:34:10 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Hutton, Andrew" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: Ac8obNsCBHZfUz6PQqmEmyo5gqkf2AAbnmgAAAkaV9A= Date: Thu, 13 Feb 2014 15:34:10 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242AD903@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF17CF4032@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17CF4032@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.62.22] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242AD903xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:34:21 -0000 --_000_913383AAA69FF945B8F946018B75898A242AD903xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KWWVzLCBXZWJSVEMgYnJvd3NlciB3aWxsIGhhdmUgdG8gYSBzdXBwb3J0IGEg bnVtYmVyIG9mIG1lY2hhbmlzbXMuIFRoaXMgd2FzIGRpc2N1c3NlZCBpbiBSVENXRUIgbWFpbGlu ZyBsaXN0IHNvbWV0aW1lIGJhY2sgYW5kIHNlY3Rpb24gMy4zLjQuMSBpbiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50 cy0xNCBoYXMgYmVlbiB1cGRhdGVkIHRvIHJlZmxlY3QgdGhpcyBwb2ludC4NCkNhbiB5b3UgcGxl YXNlIGNsYXJpZnkgdGhlIGVuaGFuY2VtZW50cyBUVVJOIHNlcnZlciB5b3UgYXJlIGxvb2tpbmcg Zm9yIGFuZCB3aGF0IHByb2JsZW1zIGRvZXMgaXQgc29sdmUgPw0KDQotVGlydS4NCkZyb206IEh1 dHRvbiwgQW5kcmV3IFttYWlsdG86YW5kcmV3Lmh1dHRvbkB1bmlmeS5jb21dDQpTZW50OiBUaHVy c2RheSwgRmVicnVhcnkgMTMsIDIwMTQgNDoxOCBQTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAo dGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3RyYW1dIE1pbGVzdG9u ZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2Ug YW5kIElTUHMNCg0KVGhlIHByaW1lIHVzZSBjYXNlIGZvciB0aGlzIGlzIGRvY3VtZW50ZWQgaW4g aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFu ZC1yZXF1aXJlbWVudHMtMTIjc2VjdGlvbi0zLjMuNS4xIGFuZCBJIHRoaW5rIHRoYXQgVFJBTSB3 aWxsIHByb2JhYmx5IG1ha2UgZW5oYW5jZW1lbnRzIHRvIFRVUk4gZW5hYmxpbmcgc3VjaCBhbiDi gJxlbnRlcnByaXNlIGF1ZGl0aW5nIFRVUk4gc2VydmVy4oCdIHRvIGRvIGFuIGVmZmVjdGl2ZSBq b2Igb2YgbWFuYWdpbmcgV2ViUlRDIHRyYWZmaWMgaW4gYW4gZW50ZXJwcmlzZS4NCg0KVGhlcmUg YXJlIG9mIGNvdXJzZSBtb3JlIHRoYW4gb25lIHByb2JsZW0gYW5kIG1hbnkgcG9zc2libHkgd2F5 cyB0byBzb2x2ZSB0aGVtIGFuZCBJIHJlY2VudGx5IHVwZGF0ZWQgaHR0cDovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaHV0dG9uLXJ0Y3dlYi1uYXQtZmlyZXdhbGwtY29uc2lkZXJhdGlvbnMt MDMgdG8gbGlzdCB0aGVzZSBmb3IgZGlzY3Vzc2lvbiBpbmNsdWRpbmcgUENQLg0KDQpVbmZvcnR1 bmF0ZWx5IHNvbHV0aW9ucyBhcmUgbmVlZGVkIHRvZGF5IHdpdGhpbiBleGlzdGluZyBuZXR3b3Jr cyBhbmQgUENQIGRvZXMgbm90IHNlZW0gc28gdXNlZnVsIGhlcmUgc28gd2UgaGF2ZSB0byBsb29r IGF0IG11bHRpcGxlIHNvbHV0aW9ucyBhbmQgcHJvYmFibHkgV2ViUlRDIGJyb3dzZXJzIGhhdmUg dG8gc3VwcG9ydCBhIG51bWJlciBvZiBtZWNoYW5pc21zLg0KDQpSZWdhcmRzDQpBbmR5DQoNCg0K DQpGcm9tOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIFttYWlsdG86dGlyZWRkeUBjaXNj by5jb21dDQpTZW50OiAxMyBGZWJydWFyeSAyMDE0IDAzOjM3DQpUbzogSHV0dG9uLCBBbmRyZXc7 IEp1c3RpbiBVYmVydGk7IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpDQpDYzog dGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGljaXNjby5jb20+OyBTaW1vbiBQZXJy ZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9y Zz47IE1hcmMgQmxhbmNoZXQ7IERhbiBXaW5nIChkd2luZyk7IEthcmwgU3RhaGwNClN1YmplY3Q6 IFJFOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hh bmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpIaSBBbmR5LA0KDQpUaGVyZSBhcmUgb3Ro ZXIgd2F5cyB0byBzb2x2ZSB0aGUgcHJvYmxlbSBmb3IgZXhhbXBsZSB1c2luZyBQQ1AuIENhbiB5 b3UgY2xhcmlmeSBob3cgZGVwbG95aW5nIGEgVFVSTiBzZXJ2ZXIgaW4gdGhlIEVudGVycHJpc2Ug cHJvdGVjdHMgdGhlIHVzZXJzIGFuZCB0aGUgbmV0d29yayA/DQoNCi1UaXJ1Lg0KRnJvbTogdHJh bSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEh1dHRvbiwgQW5k cmV3DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgMTowMCBBTQ0KVG86IEp1c3Rp biBVYmVydGk7IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpDQpDYzogdGlyZWRk eUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGljaXNjby5jb20+OyBTaW1vbiBQZXJyZWF1bHQ7 IE9sZWcgTW9za2FsZW5rbzsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IE1h cmMgQmxhbmNoZXQ7IERhbiBXaW5nIChkd2luZyk7IEthcmwgU3RhaGwNClN1YmplY3Q6IFJlOiBb dHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBm b3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpUaGUgY2FzZSB3aGVyZSB0aGUgVFVSTiBzZXJ2ZXIg aXMgdGhlIG9ubHkgb3B0aW9uIG1heSBiZWNvbWUgY29tbW9uIHdpdGhpbiBlbnRlcnByaXNlIG5l dHdvcmtzIGFuZCB0aGF0IG1pZ2h0IGJlIGRlbGliZXJhdGUgZW50ZXJwcmlzZSBwb2xpY3kgYmVj YXVzZSBpdCBwcm92aWRlcyB0aGUgYmV0dGVyIHBhdGggKFVEUCB0aHJvdWdoIHRoZSBGL1cpIGFu ZCBwcm90ZWN0cyB0aGUgdXNlcnMgYW5kIHRoZSBuZXR3b3JrLg0KDQpBbmR5DQoNCg0KRnJvbTog dHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEp1c3RpbiBV YmVydGkNClNlbnQ6IDEyIEZlYnJ1YXJ5IDIwMTQgMTc6NDYNClRvOiBNdXRodSBBcnVsIE1vemhp IFBlcnVtYWwgKG1wZXJ1bWFsKQ0KQ2M6IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWlsdG86dGlyZWRk eUBpY2lzY28uY29tPjsgU2ltb24gUGVycmVhdWx0OyBPbGVnIE1vc2thbGVua287IHRyYW1AaWV0 Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+OyBNYXJjIEJsYW5jaGV0OyBEYW4gV2luZyAoZHdp bmcpOyBLYXJsIFN0YWhsDQpTdWJqZWN0OiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNl cnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0K QWdyZWUuIElmIFRVUk4gaXMgaW5kZWVkIGJlaW5nIHByb3ZpZGVkIGZvciB0aGUgdXNlcidzIGJl bmVmaXQsIHRoZSBjbGllbnQncyBJQ0UgbG9naWMgKGJhc2VkIG9uIFJUVCBvciBzaW1pbGFyKSBz aG91bGQgcmVzdWx0IGluIGl0IHByZWZlcnJpbmcgdGhlIFRVUk4gcGF0aC4NCg0KT24gV2VkLCBG ZWIgMTIsIDIwMTQgYXQgMToyNyBBTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1h bCkgPG1wZXJ1bWFsQGNpc2NvLmNvbTxtYWlsdG86bXBlcnVtYWxAY2lzY28uY29tPj4gd3JvdGU6 DQpZZXMsIEkgYmVsaWV2ZSB0aGUgc2Vjb25kIGNhc2UgaXMgcmFyZSwgYnV0IHdvdWxkIGJlIGJl dHRlciB0aGFuIGEgcmF0IHJhY2UgYi93IGFkbWluaXN0cmF0b3JzIHRyeWluZyB0byBibG9jayBw MnAgdHJhZmZpYyBhbmQgZm9yY2UgaXQgdGhyb3VnaCBhIFRVUk4gc2VydmVyIGFuZCBhcHBzL2Vu ZHBvaW50cyBmaW5kaW5nIHNtYXJ0ZXIgd2F5cyB0byBieXBhc3MgdGhlbS4NCg0KTXV0aHUNCg0K RnJvbTogT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbTxtYWlsdG86 bW9tMDQwMjY3QGdtYWlsLmNvbT5dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0 IDE6MDcgUE0NClRvOiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KQ2M6IEp1 c3RpbiBVYmVydGk7IEthcmwgU3RhaGw7IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWlsdG86dGlyZWRk eUBpY2lzY28uY29tPjsgTWFyYyBCbGFuY2hldDsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBp ZXRmLm9yZz47IERhbiBXaW5nIChkd2luZyk7IFNpbW9uIFBlcnJlYXVsdA0KDQpTdWJqZWN0OiBS ZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5p c20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KVGhlIFRVUk4gc2VydmVyIGhhcyB0byBiZSB1 c2VkIHdoZW4gaXQgaXMgZWl0aGVyIHRoZSBvbmx5IG9wdGlvbiwgb3IgaWYgaXQgcHJvdmlkZXMg YSBiZXR0ZXIgcGF0aCAoSSBndWVzcyB0aGUgc2Vjb25kIGNhc2UgaXMgcmF0aGVyIHJhcmUpLg0K DQpPbiBUdWUsIEZlYiAxMSwgMjAxNCBhdCAxMTozMiBQTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1 bWFsIChtcGVydW1hbCkgPG1wZXJ1bWFsQGNpc2NvLmNvbTxtYWlsdG86bXBlcnVtYWxAY2lzY28u Y29tPj4gd3JvdGU6DQorMQ0KDQpGb3JjaW5nIGFsbCB0cmFmZmljIHRocm91Z2ggYSBUVVJOIHNl cnZlciBhbmQgZXhwZWN0aW5nIGl0IHdvdWxkIHByb3ZpZGUgdGhlIGJlc3QgdXNlciBleHBlcmll bmNlIGRvZXNuJ3QgbG9vayB0aGUgcmlnaHQgYXBwcm9hY2guIEluc3RlYWQsIGlmIGEgcGF0aCB0 aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgZXhpc3RzIGFuZCBkb2VzIHByb3ZpZGUgbG93ZXIgUlRULCBq aXR0ZXIgZXRjLCBiZWluZyBhYmxlIHRvIGRldGVjdCBhbmQgdXNlIChvciBzd2l0Y2ggdG8pIHRo YXQgcGF0aCBtaWdodCBiZSBkZXNpcmFibGUuLg0KDQpNdXRodQ0KDQpGcm9tOiB0cmFtIFttYWls dG86dHJhbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwg MjAxNCAxMTo0MyBBTQ0KVG86IEthcmwgU3RhaGwNCkNjOiB0aXJlZGR5QGljaXNjby5jb208bWFp bHRvOnRpcmVkZHlAaWNpc2NvLmNvbT47IE1hcmMgQmxhbmNoZXQ7IHRyYW1AaWV0Zi5vcmc8bWFp bHRvOnRyYW1AaWV0Zi5vcmc+OyBEYW4gV2luZyAoZHdpbmcpOyBTaW1vbiBQZXJyZWF1bHQNClN1 YmplY3Q6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5 IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpJbmxpbmUuDQoNCk9uIFR1ZSwg RmViIDExLCAyMDE0IGF0IDI6MzcgUE0sIEthcmwgU3RhaGwgPGthcmwuc3RhaGxAaW50ZXJ0ZXgu c2U8bWFpbHRvOmthcmwuc3RhaGxAaW50ZXJ0ZXguc2U+PiB3cm90ZToNCkxpc3RlbmluZyB0byB0 aGlzIHRocmVhZCwgSSBhbSBhZnJhaWQgd2UgYXJlIG1pc3NpbmcgdGhlIHZlcnkgcG9pbnQgYW5k IG5lY2Vzc2l0eSBmb3IgdGhpcyBtaWxlc3RvbmUhDQotIFRoZXJlIGFyZSBzZXZlcmUgTkFUIHRy YXZlcnNhbCBhbmQgcXVhbGl0eSBpc3N1ZXMgdGhhdCBzaG91bGQgYW5kIGNhbiBiZSBkZWFsdCB3 aXRoIGJ5IGEgZ29vZCBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gYW5kIHRoZSByaWdodCB1c2Fn ZSBieSB0aGUgdHVybiBjbGllbnQgKHRoZSBXZWJSVEMgYnJvd3NlcikNCg0KVGhlcmUgYXJlIHdh eXMsIG5vdCBvbmx5OiBFbnRlcnByaXNlcyBvciBJU1BzIHdpc2hpbmcgdG8gcHJvdmlkZSB0aGVp ciBvd24gVFVSTiBzZXJ2ZXIsIGluIGFuIGF0dGVtcHQgdG8gcmVkdWNlIHNvLWNhbGxlZCAidHJp YW5nbGUgcm91dGluZyIsbmVlZCBhIG5ldyBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20NCkJ1dCBh bHNvOiAtIE5TUHMgKE5ldHdvcmsgU2VydmljZSBQcm92aWRlcnMpIHdhbnQgdG8gcHJvdmlkZSBh IHBhdGggd2hlcmUgdGhlIGJhbmR3aWR0aCBvZiBXZWJSVEMgaXMgYmV0dGVyIGNvcGVkIHdpdGgu DQotIE5TUHMgb3IgRW50ZXJwcmlzZXMgd2FudCB0byBvZmZlciBhbiBJbnRlcm5ldCBhY2Nlc3Mg cXVhbGl0eSBwaXBlIGZvciBwcmlvcml0aXplZCBSVEMgKFJlYWwgVGltZSBDb21tdW5pY2F0aW9u KSB0cmFmZmljLg0KLSBFbnRlcnByaXNlcyBoYXZpbmcgcmVzdHJpY3RpdmUgZmlyZXdhbGxzLCB3 YW50IHRvIHByb3ZpZGUgYSBVRFAtcGF0aCBmb3IgV2ViUlRDIGFuZCBwb3NzaWJseSBhbHNvIGZv ciBiZXR0ZXIgcXVhbGl0eSB3aGVyZSBSVEMgZG8gbm90IGNvbXBldGUgd2l0aCBkYXRhIHRyYWZm aWMuDQpBbHNvIGNvbnNpZGVyaW5nDQotIE1vYmlsaXR5OyBJdCBpcyBjb21tb24gdG8gbW92ZSBm cm9tIGEgTEFOIHRvIGFjY2Vzc2luZyB2aWEgV2lGaSBvciAzRy80RyBPVFQgY2hhbm5lbHMsIGFs bCBzaG91bGQgYmUgYWJsZSB0byBhdXRvbWF0aWNhbGx5IG9mZmVyIHRoZWlyIG93biBvcHRpbWFs IFRVUk4gc2VydmVyDQoNClRoaXMgbGVhZHMgdXMgaW50byAg4oCcVFVSTuKApnRvIGlkZW50aWZ5 IFdlYlJUQyBmbG93c+KAnSBldGMhIEl0IGlzIG5vdCBhIG1pc3Rha2UsIGJ1dCB0aGUgdmVyeSBu ZWVkIGZvciB0aGlzIG1pbGVzdG9uZSENCg0KQWdhaW4sIGl0IGhhcyBub3QgYmVlbiBkZW1vbnN0 cmF0ZWQgd2h5IFRVUk4gaXMgdGhlIHJpZ2h0IHRlY2hub2xvZ3kgaGVyZSwgY29tcGFyZWQgdG8g YSBtb3JlIHRyYW5zcGFyZW50IGZsb3cgaWRlbnRpZmljYXRpb24gdG9vbCBsaWtlIE1BTElDRS4g V2UgZG9uJ3QgZm9yY2UgYWxsIEhUVFAgcmVxdWVzdHMgdG8gbG9jYXRlIGEgSFRUUCBwcm94eSB2 aWEgYW55Y2FzdCwgSSBkb24ndCBzZWUgd2h5IHdlIG5lZWQgdG8gZG8gdGhlIHNhbWUgZm9yIFdl YlJUQy4NCg0KV2hhdCBhcmUgdGhlIGhlc2l0YXRpb25zIHJhaXNlZCBoZXJlPw0KPiBUVVJOIHBy aW1hcmlseSB0byBpZGVudGlmeSBXZWJSVEMgZmxvd3MsIGFzIG9wcG9zZWQgdG8gdXNpbmcgaXQg YXMgYSBOQVQgdHJhdmVyc2FsIHRvb2wuIFRoaXMgbWFrZXMgbWUgY29uY2VybmVkIHRoYXQgd2Ug bWF5IGJlIHVzaW5nIHRoZSB3cm9uZyB0ZWNobm9sb2d5IHRvIHNvbHZlIHRoZSBwcm9ibGVtDQpJ dCBpcyBjb3JyZWN0IHRoYXQgSUNFL1NUVU4vVFVSTiB3YXMgZGVzaWduZWQgdG8gYWRkcmVzcyB0 aGUgTkFUL0ZpcmV3YWxsIHRyYXZlcnNhbCBwcm9ibGVtIGFzc29jaWF0ZWQgd2l0aCByZWFsLXRp bWUgY29tbXVuaWNhdGlvbiAoU0lQIGF0IHRoYXQgdGltZSkuIEhvd2V2ZXIsIGl0cyBsYXJnZXN0 IGZsYXcvcHJvYmxlbSBpcyB0aGF0IHF1YWxpdHkgdGhpbmdzIHdlcmUgbm90IChjb3VsZCBub3Qg YmU/KSBjb25zaWRlcmVkLiBUaGUgbWV0aG9k4oCZcyB2ZXJ5IGlkZWEgKGxpa2UgYWxsIHNpbWls YXIgbWV0aG9kcyBmb3IgZ2V0dGluZyBSVEMgdGhyb3VnaCBvcmRpbmFyeSBOQVQvRmlyZXdhbGxz KSBpcyB0byBmb29sIHRoZSBtZWRpYSB0aHJvdWdoIGEgTkFUL0ZpcmV3YWxsIHRoYXQgaXMgdW5h d2FyZSBvZiB3aGF0IGlzIGhhcHBlbmluZy4gVGh1cywgdGhpcyBpcyByb290IG9mIHF1YWxpdHkg aXNzdWVzIChhbmQgYmFuZHdpZHRoIGFsbG9jYXRpb24gb3B0aW1pemF0aW9uKSB0aGF0IG5lZWRz IHRvIGJlIGRlYWx0IHdpdGg6IFJlYWwtdGltZSB0cmFmZmljIGZpZ2h0aW5nIHdpdGggYSBkYXRh IHRyYWZmaWMgY3Jvd2RlZCBjb25nZXN0aW9uIHBvaW50Lg0KDQpJIHRoaW5rIHRoYXQgImZvb2xp bmciIGlzIGFuIGluY29ycmVjdCBkZXNjcmlwdGlvbi4gVGhlIE5BVCBpcyBzdXBwb3NlZCB0byBi ZSB0cmFuc3BhcmVudCB0byB0aGUgY2xpZW50Lg0KDQpCdXQsIGEgQkxFU1NJTkcgb2YgSUNFL1NU VU4vVFVSTiBpcyB0aGF0IGl0IGNhbiBiZSBzZWVuIGFzIGEgbGVnaXRpbWF0ZSByZXF1ZXN0IGZv ciBhIHN1aXRhYmxlIHBpcGUgZm9yIHF1YWxpdHkgZGVtYW5kaW5nIHJlYWwgdGltZSB0cmFmZmlj LiDimLoNCklDRSBpcyBhIHByZS1wcm90b2NvbCB5b3UgdXNlIGJlY2F1c2UgeW91IHdhbnQgYSBw YXRoIGZvciByZWFsLXRpbWUgbWVkaWEgYmV0d2VlbiBwYXJ0aWVzLiBIZXJlOiBUaGUgYnJvd3Nl ciBzYXlzIGtub2NrIGtub2NrLCBJIHdhbnQgdG8gZ2V0IG1lZGlhIHRocm91Z2ggKGFuZCBvZiBj b3Vyc2Ugd2l0aCBhcyBnb29kIHF1YWxpdHkgYXMgcmVxdWlyZWQgYW5kIHBvc3NpYmxlKS4NCg0K SWYgdGhlIE5BVC9GaXJld2FsbCBvd25lciBhbmQgbmV0d29yayBvd25lciBhcmUgYWxsb3dlZCB0 byBzZWUgdGhlc2UgcmVxdWVzdHMsIHRoZXkgY2FuIGhlbHAvYXNzaXN0IGluIGFjaGlldmluZyB0 aGUgZ29vZCBtZWRpYSBwYXRoLiBJZiB0aGV5IGFyZSBub3QgYXdhcmUsIHRoZXkgY2Fubm90IGhl bHAhDQoNCkhvcGUgdGhpcyBtYWRlIGl0IHVuZGVyc3RhbmRhYmxlIG9uIGFuIG92ZXJ2aWV3IGxl dmVsIGhvdyB0aGlzIGNhbiBiZWNvbWUg4oCcVFVSTuKApnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93 c+KAnQ0KSXQgaXMgYWxzbyB0aGUgT05MWSB3YXkgSSBjYW4gc2VlIHRvIGFjaGlldmUgd2hhdCB3 ZSB3YW50IHRvIGFjaGlldmUgYW5kIHNob3VsZCBiZSB0aGUgYWltIGFuZCByZXF1aXJlbWVudCBv ZiB0aGlzIG1pbGVzdG9uZS4NCg0KSSBhbSB0YWxraW5nIGFib3V0IGdlbmVyYWwgdXNhZ2Ugb2Yg V2ViUlRDIG92ZXIgSW50ZXJuZXQvbW9iaWxlIE9UVCAobm90IGZlZWRpbmcgV2ViUlRDIGludG8g YXBwbGljYXRpb24gc3BlY2lmaWMgbmV0d29ya3MgbGlrZSBJTVMgd2hlcmUgb3RoZXIgbWV0aG9k cyBtYXkgZXhpc3QpLg0KDQpUaGlzIGlzIGdvb2QsIG5vdCBldmlsIQ0KDQpJZiB0aGUgaGVzaXRh dGlvbnMgYXJlIHJhaXNlZCBiZWNhdXNlIG9mIGEgYmVsaWVmL2hvcGUvd2lzaCB0aGF0IHRoZXJl IGFyZSBubyBvciB3aWxsIG5vdCBiZSBzZXZlcmUgcXVhbGl0eSBpc3N1ZXMg4oCcYmVjYXVzZSBp dCBpcyBhbGwgYWJvdXQgYmFuZHdpZHRo4oCdLCDigJxpdCB3aWxsIHJlc29sdmUgaXRzZWxmIHdp dGggdGltZeKAnSBldGMuLCBJIHN0cm9uZ2x5IG9iamVjdCEgVGhhdCBpcyB3cm9uZyBhbmQgd2ls bCBiZSB2ZXJ5IGRldHJpbWVudGFsIGZvciBXZWJSVEMgdXNhZ2UuIFdlIGFscmVhZHkgc2VlIGl0 IGFuZCBJIGNhbiBnaXZlIG51bWVyb3VzIGV4YW1wbGVzIG9mIGhvdyBtdWNoIGxlc3MgcXVhbGl0 eSBkZW1hbmRpbmcgVm9JUCBpcy9pcyBub3QgaGFuZGxlZCBxdWFsaXR5IHdpc2UgYW5kIHRoYXQg aXQgbWF0dGVycy4gQW5kLCB3aGF0IHdvdWxkIGJlIGJhZCBjb25zaWRlcmluZyBxdWFsaXR5IGlz c3VlcyBhbmQgYWxsb3dpbmcvZW5jb3VyYWdpbmcgbWV0aG9kcyB0byBkZWFsIHdpdGggdGhlbT8N Cg0KSWYgdGhlIGhlc2l0YXRpb25zIGFyZSByYWlzZWQsIGJlY2F1c2Ugb2Ygc3VzcGljaW9uIHRo YXQgdGhlIG1ldGhvZHMgd2UgbWF5IHJlY29tbWVuZCBtYXkgYmUgbWlzdXNlZCB0byBzdG9wL2Js b2NrL2Rlc3Ryb3kgV2ViUlRDIHVzYWdlIChlLmcuIHRvIHByb3RlY3QgaW5jb21lIGZyb20gY2Fy cmllciB0ZWxlcGhvbnkgdHJhZmZpYyksIEkgY291bGQgdW5kZXJzdGFuZCBhbmQgd291bGQgZmln aHQgdGhlIHNhbWUgYmF0dGxlLiBCdXQgaG9wZWZ1bGx5LCB0aG9zZSBkYXlzIGFyZSAoc29vbikg b3ZlciDigJMgQXQgbGVhc3QgZm9yd2FyZCB0aGlua2luZyBjYXJyaWVy4oCZcyByZWFsaXplIHRo YXQgYWxyZWFkeS4gV2ViIFJUQyB3aWxsIGhhcHBlbi4gV2hpY2ggY3VzdG9tZXJzIHdhbnQgdG8g cGF5IGZvciBhbiBhY2Nlc3Mgd2l0aCBibG9ja2VkIFdlYlJUQz8gVGhlIGNhcnJpZXLigJlzIG9m ZmVyaW5nL2Fzc3VyaW5nIGdvb2QgV2ViUlRDIHdpbGwgcmF0aGVyIGdldCB0aGUgY3VzdG9tZXJz IGFuZCBpbmNvbWUg4pi6LiAoTWF5YmUgdGhlIFdlYiBicm93c2VyIGNhbiBkZXRlY3QgYW5kIGVu Y291cmFnZSB0aGlz4oCmKQ0KDQpJZiB0aGVyZSBhcmUgdGVjaG5pY2FsIGNvbmNlcm5zIG9mIGJh ZCByZXN1bHQsIG9yIGJldHRlciBtZXRob2RzIGFsbG93aW5nIG5ldHdvcmsgcHJvdmlkZXJzIGFu ZCBMQU4gbWFuYWdlcnMgdG8gb2ZmZXIgYW5kIGluZm9ybSB0aGUgYnJvd3NlciB0aGF0IHRoZXJl IGFyZSBnb29kIG1lZGlhIHBhdGhzIHRvIGJlIHVzZWQsIGFuZCB0aGF0IHRoZSB3ZWIgYnJvd3Nl ciBhdXRvbWF0aWNhbGx5IGNhbiBjaG9zZSB0aG9zZSwgdGhlbiBsZXQgdXMgYWxsIHVuZGVyc3Rh bmQgdGhvc2UsIHNvIHdlIGNhbiBhY2hpZXZlIHdoYXQgc2hvdWxkIGJlIGFjaGlldmVkIGJ5IHRo aXMgbWlsZXN0b25lLg0KDQpTa3lwZSwgSGFuZ291dHMsIEZhY2V0aW1lIGFyZSBkb2luZyBiaWxs aW9ucyBvZiBtaW51dGVzIHBlciB3ZWVrIGFuZCB0aGUgSW50ZXJuZXQgaGFzIG5vdCBtZWx0ZWQg eWV0LiBJZiB3ZSBuZWVkIHRvIGRvIGZsb3cgaWRlbnRpZmljYXRpb24gdG8gYWxsb3cgdHJhZmZp YyB0byBiZSBwcmlvcml0aXplZCwgZmluZSAoc2VlIGFib3ZlIHJlZ2FyZGluZyBteSBwcmVmZXJy ZWQgYXBwcm9hY2gpLCBidXQgZm9yY2luZyBhbGwgV2ViUlRDIHRyYWZmaWMgdGhyb3VnaCBhIE1J VE0gKFRVUk4gc2VydmVyKSBpcyBhIG11Y2ggYmlnZ2VyIGp1bXAgdGhhdCBJIGRvbid0IHlldCBz ZWUgdGhlIGp1c3RpZmljYXRpb24gZm9yLg0KDQpJbiBzaG9ydDogVFVSTiBpcyBhIHRlY2hub2xv Z3kgdGhhdCBpcyBzdXBwb3NlZCB0byBmYWRlIGF3YXkgd2l0aCB0aGUgbW92ZSB0byBJUHY2LiBJ IGRvbid0IHRoaW5rIHdlIHdhbnQgdG8gbWFrZSBpdCBhIGNyaXRpY2FsIGVsZW1lbnQgb2YgV2Vi UlRDLg0KDQovS2FybA0KDQoNCkZyw6VuOiBEYW4gV2luZyBbbWFpbHRvOmR3aW5nQGNpc2NvLmNv bTxtYWlsdG86ZHdpbmdAY2lzY28uY29tPl0NClNraWNrYXQ6IGRlbiAxMSBmZWJydWFyaSAyMDE0 IDE4OjI1DQpUaWxsOiBNYXJjIEJsYW5jaGV0DQpLb3BpYTogSnVzdGluIFViZXJ0aTsgdGlyZWRk eUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGljaXNjby5jb20+OyBLYXJsIFN0YWhsOyB0cmFt QGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPjsgU2ltb24gUGVycmVhdWx0DQoNCsOEbW5l OiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNo YW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KDQpPbiBGZWIgMTEsIDIwMTQsIGF0IDk6 MDggQU0sIE1hcmMgQmxhbmNoZXQgPG1hcmMuYmxhbmNoZXRAdmlhZ2VuaWUuY2E8bWFpbHRvOm1h cmMuYmxhbmNoZXRAdmlhZ2VuaWUuY2E+PiB3cm90ZToNCg0KTGUgMjAxNC0wMi0xMSDDoCAwMDoz OSwgRGFuIFdpbmcgPGR3aW5nQGNpc2NvLmNvbTxtYWlsdG86ZHdpbmdAY2lzY28uY29tPj4gYSDD qWNyaXQgOg0KDQoNCk9uIEZlYiAxMCwgMjAxNCwgYXQgNTozMCBQTSwgSnVzdGluIFViZXJ0aSA8 anViZXJ0aUBnb29nbGUuY29tPG1haWx0bzpqdWJlcnRpQGdvb2dsZS5jb20+PiB3cm90ZToNCg0K R29vZCB0byBzZWUgdGhlcmUgaXMgYSBsb3Qgb2YgaW50ZXJlc3QgZm9yIHRoaXMgbWlsZXN0b25l LiBCdXQgYmFzZWQgb24gdGhlIGRlc2NyaXB0aW9uIGhlcmUsIGl0IHNlZW1zIGxpa2Ugd2Ugd2Fu dCB0byB1c2UgVFVSTiBwcmltYXJpbHkgdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dzLCBhcyBvcHBv c2VkIHRvIHVzaW5nIGl0IGFzIGEgTkFUIHRyYXZlcnNhbCB0b29sLiBUaGlzIG1ha2VzIG1lIGNv bmNlcm5lZCB0aGF0IHdlIG1heSBiZSB1c2luZyB0aGUgd3JvbmcgdGVjaG5vbG9neSB0byBzb2x2 ZSB0aGUgcHJvYmxlbS4NCg0KKzEuDQoNCkkgd291bGQgcHJlZmVyIGFsbG93aW5nIGZsb3dzIHRv IGVzdGFibGlzaCB0aGVtc2VsdmVzIHVzaW5nIHRoZWlyICdiZXN0JyBwYXRoLCBhbmQgdGhlIGJl c3QgcGF0aCBpcyBzZWxkb20gdGhyb3VnaCBhIFRVUk4gc2VydmVyLiAgV2hlbiB3ZSBpbWFnaW5l IElQdjYgaW4gb3VyIGZ1dHVyZSwgd2UgZG9uJ3Qgd2FudCB0byBmb3JjZSBhbiBhcHBsaWNhdGlv bi1sZXZlbCBwcm94eSAoVFVSTikgc2VydmVyIG9uIHRoZSBwYXRoIHNvbGVseSBmb3IgdHJhdmVy c2luZyBhbiBJUHY2IGZpcmV3YWxsLg0KDQoNCkl0IHNlZW1zIHRoaXMgdGhyZWFkIGlzIGNvbmZs YXRpbmcgYWxsIHRoZSBwb3NzaWJsZSByZWFzb25zIC8ganVzdGlmaWNhdGlvbnMgZm9yIFRVUk46 DQogICogbW9iaWxpdHkNCiAgKiBOQVQgdHJhdmVyc2FsIChib3RoIGVuZHBvaW50cyBhcmUgYmVo aW5kIGVuZHBvaW50LWRlcGVuZGVudCBtYXBwaW5nIE5BVHMpDQogICogZmlyZXdhbGwgdHJhdmVy c2FsIChmaXJld2FsbCBibG9ja3MgVURQKQ0KICAqIGVuaGFuY2luZyBwcml2YWN5DQoNClVuZm9y dHVuYXRlbHkgdGhlIFRVUk4gc2VydmVyIG5vciB0aGUgZW5kcG9pbnQgcmVhbGx5IGtub3cgd2hp Y2ggb2YgdGhvc2UgdXNlLWNhc2VzIGlzIGRlc2lyZWQgKGJ5IHRoZSB1c2VyIG9yIGJ5IHRoZSBJ VCBuZXR3b3JrIGFkbWluaXN0cmF0b3IpIG9yIG5lY2Vzc2FyeSAoZm9yIHRoZSBjYWxsIHRvIHdv cmsgYXQgYWxsKS4NCg0KRGFuLCB3aGlsZSBJIGFncmVlIGluIHByaW5jaXBsZSwgSSBkb3VidCB0 aGF0IGEgdXNlciBjb3VsZCBldmVyIHNheSAiSSB3YW50IG1vYmlsaXR5IG9yIEkgd2FudCBOQVQg dHJhdmVyc2FsIi4gSSB0aGluayB0aGUgdXNlciBvbmx5IHdhbnQgdGhlIGNhbGwgdG8gc3VjY2Vl ZCwgd2hhdGV2ZXIgdGhlIHByb3BlcnRpZXMgb2YgaXRzIG5ldHdvcmsgcG9pbnQgb2YgYXR0YWNo bWVudCBhcmUuDQoNClNvIHdoYXQgY2FuIHdlIGRvPyAgU2hvdWxkIHRoZSBUVVJOIHNlcnZlciBw cm92aWRlIGFueSBhbmQgYWxsIHNlcnZpY2VzIHRoZSBUVVJOIGNsaWVudCBtaWdodCBwb3NzaWJs eSB3YW50LCBhcyB0aGF0IGlzIHdoYXQgYSByb2J1c3QgVFVSTiBzZXJ2ZXIgd2lsbCBkbywgYW5k IHRoZSBlbmRwb2ludCBzaG91bGQgcHJlZmVyIFRVUk4gY2FuZGlkYXRlcyBvdmVyIGFsbCBvdGhl cnMgYmVjYXVzZSB0aGVyZSBtaWdodCBiZSBzb21lIGZ1bmN0aW9uYWxpdHkgLyB1c2VmdWxuZXNz IG9mIFRVUk4gdGhhdCB0aGUgdXNlciBtaWdodCBnYWluIHRocm91Z2ggVFVSTiAoZS5nLiwgZW5o YW5jZWQgcHJpdmFjeSk/DQoNCi1kDQoNCg0KDQogVGhpcyBzZWVtcyBwcm9ibGVtYXRpYy4gIFBl cmhhcHMgd2UgbmVlZCBhIHdheSB0byBzaWduYWwgdGhlIGRlc2lyZWQgdXNlLWNhc2UgKCJ0cmFp dCIpLCBvciBhcyBKdXN0aW4gc3VnZ2VzdHMsIHVzaW5nIGEgZGlmZmVyZW50IHRlY2hub2xvZ3kg Zm9yIHNvbWUgb2YgdGhlc2UgdXNlLWNhc2VzLg0KDQotZA0KDQoNCg0KDQpPbiBNb24sIEZlYiAx MCwgMjAxNCBhdCAzOjE4IFBNLCBLYXJsIFN0YWhsIDxrYXJsLnN0YWhsQGludGVydGV4LnNlPG1h aWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlPj4gd3JvdGU6DQpTaW1vbiwNCg0KR29vZCBxdWVz dGlvbnMgLSBzZWUgaW5saW5lIGJlbG93IC0tPiAuDQpTb21lIG1vcmUgdGhvdWdodCBpcyByZXF1 aXJlZCENCg0KL0thcmwNCg0KLS0tLS1VcnNwcnVuZ2xpZ3QgbWVkZGVsYW5kZS0tLS0tDQpGcsOl bjogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHJhbS1ib3VuY2Vz QGlldGYub3JnPl0gRsO2ciBTaW1vbiBQZXJyZWF1bHQNClNraWNrYXQ6IGRlbiAxMCBmZWJydWFy aSAyMDE0IDE1OjE2DQpUaWxsOiBLYXJsIFN0YWhsOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFt QGlldGYub3JnPjsgdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGljaXNjby5jb20+ DQrDhG1uZTogUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3Zl cnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNCkthcmwsDQoNCkl0IGlzIGdy ZWF0IHRvIHNlZSBzdWNoIGVudGh1c2lhc20hIFRoYW5rcyENCg0KSSBoYXZlIGEgY291cGxlIHRl Y2huaWNhbCBxdWVzdGlvbnMuLi4NCg0KTGUgMjAxNC0wMi0wOCAwODoxMSwgS2FybCBTdGFobCBh IMOpY3JpdCA6DQo+IC0gTm90ZSB0aGF0IHRvIGFjaGlldmUgc29tZSBvZiB0aGUgYWJvdmUgcG9p bnRzLCBUVVJOIG11c3QgYmUgZmF2b3JlZA0KPiBvdmVyIFNUVU4gdG8gZW5mb3JjZSB0aGF0IHRo ZSBUVVJOLXBhdGggYWN0dWFsbHkgaXMgdXNlZC4gKFRoZSBBbnljYXN0DQo+IG1ldGhvZCBzdWdn ZXN0ZWQgYmVsb3csIOKAnGF1dG9tYXRpY2FsbHnigJ0gZG9lcyB0aGlzLikNCg0KSSB1bmRlcnN0 YW5kIHRoZSBTVFVOIHZzIFRVUk4gcHJpb3JpdHkgaXNzdWUuIEJ1dCBJIGRvbid0IHNlZSBob3cg YW55Y2FzdCBhZmZlY3RzIGl0IGluIGFueSB3YXkuIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4/DQot LS0gR29vZCBwb2ludCAtIEkgd2FzIGEgYml0IHF1aWNrIGhlcmUgKG1heWJlIHRvbyBxdWljaykN CldlIGhhdmUgZ2l2ZW4gdGhpcyBxdWl0ZSBiaXQgb2YgdGhvdWdodCwgc2luY2UgZXZlbiBpZiBh IFRVUk4gc2VydmVyIGlzIHByb3ZpZGVkIGFuZCBkaXNjb3ZlcmVkLCBDVVJSRU5UIHVzYWdlIG9m IElDRSBtYXkgc3VnZ2VzdCBhIGNhbmRpZGF0ZSBmcm9tIHRoZSByZW1vdGUgcGFydHkgdGhhdCB3 aWxsIG1ha2UgYSBjb25uZWN0aW9uIHdpdGhvdXQgdGhlIG5lZWQvdXNhZ2Ugb2YgdGhlIFRVUk4g c2VydmVyICh0aGF0IHdlIHdhbnRlZCB0byBiZSB1c2VkIGZvciB0aGUgZ29vZCBwdXJwb3NlcyBs aXN0ZWQpLg0KDQpUaGUgb25seSB3YXkgd2UgZm91bmQgYXJvdW5kIHRoaXMsIHdhcyB0byBzdG9w IFNUVU4gdGhyb3VnaCB0aGUgSVAgZGVmYXVsdCBnYXRld2F5IChsaWtlIGEgcmVzdHJpY3RpdmUg RW50ZXJwcmlzZSBmaXJld2FsbCBkb2VzIGluaGliaXRpbmcgSUNFIGNvbm5lY3Rpdml0eSwgd2hp Y2ggb3RoZXJzIGFyZSBjb25jZXJuZWQgYWJvdXQuLi4pLiBTaW5jZSB0aGUgcHJvdmlzaW9uaW5n IG9mIGF1dG8tZGlzY292ZXJ5IHVzaW5nIHRoZSBhbnljYXN0IG1lY2hhbmlzbSwgd291bGQgYmUg YWRkaW5nIGEgcm91dGUgaW4gYSBkZWZhdWx0IGdhdGV3YXksIGFkZGluZyBhIGZpcmV3YWxsIHJ1 bGUgdG8gZWF0IFNUVU4gcGFja2V0cyB3b3VsZCBhc3N1cmUgdGhhdCB0aGUgcHJvdmlzaW9uZWQg VFVSTiBzZXJ2ZXIgYWN0dWFsbHkgYmVjb21lcyB1c2VkIChhbmQgbm90IGJ5cGFzc2VkICJieSBh Y2NpZGVudCIpLiAoVGhhdCB3YXMgdGhlIHRob3VnaHQgYmVoaW5kIHRoZSDigJxhdXRvbWF0aWNh bGx54oCdIHdpdGhpbiBxdW90ZXMuKQ0KDQpCVVQsIHNpbmNlIHlvdSBicm91Z2h0IHVwIHRoZSBx dWVzdGlvbiwgYXNzdW1pbmcgdGhhdCB3ZSBoYXZlIHRoZSBwb3dlciB0byBlbmZvcmNlIFdlYlJU QyB1c2FnZSBvZiBJQ0UsIEkgYmVsaWV2ZSBhIE1VU1QgcmVxdWlyZW1lbnQgdG8gdXNlIGFuIGF1 dG8tZGlzY292ZXJlZCBUVVJOIHNlcnZlciBpbnN0ZWFkIG9mIFNUVU4sIHdvdWxkIHNvbHZlIHRo ZSBzYW1lIHByb2JsZW0uIEhvd2V2ZXIsIHRoaW5raW5nIGZ1cnRoZXIgKGluIHJlbGF0aW9uIHRv IHlvdXIgbmV4dCBxdWVzdGlvbiAtICJhbnlvbmUgY291bGQgc2V0IHVwIGEgYmFkbHktbWFpbnRh aW5lZCIgLSBlbmZvcmNpbmcgc3VjaCBJQ0UgdXNhZ2UgbWF5IG5vdCBiZSBnb29kLikNCg0KDQo+ IC0gM15yZCBUaGUgQW55Y2FzdCBtZXRob2QgYmVsb3cg4oCTIEkgc2VlIG5vIHByb2JsZW0NCj4N Cj4gSXQgYWxzbyBoYXMgdGhlIGFkdmFudGFnZSBvZiBlbmNvdXJhZ2luZyAoYnV0IG5vdCByZXF1 aXJpbmcpIHRoZQ0KPiBTVFVOL1RVUk4gdG8gYmUgYnVpbHQgaW4gdGhlIGRlZmF1bHQgZ2F0ZXdh eSBvciBOQVQvZmlyZXdhbGwvYWNjZXNzDQo+IHJvdXRlciBpdHNlbGYsIHdpdGggYSBzZWNvbmQg aW50ZXJmYWNlIHRvIGEgcHVibGljIElQIGFkZHJlc3Mgb24gdGhlDQo+IFdBTiBzaWRlLiAoQ3Vy cmVudCB2b2x1bWUgZGVwbG95ZWQsIGxvdyBjb3N0IE5TUCB0cmlwbGUgcGxheSBtb2RlbXMNCj4g dXN1YWxseSBoYXZlIGEgcXVhbGl0eSBhc3N1cmVkIGxldmVsIDIgb3IgbGV2ZWwgMyBXQU4gcGlw ZSBmb3IganVzdA0KPiB2b2ljZSAoYW5kIGFub3RoZXIgZm9yIElQVFYpIOKAkyBUaGUgYW55Y2Fz dCBkaXNjb3ZlcmVkIFRVUk4tc2VydmVyIGNhbg0KPiBiZSB0aGUgYWNjZXNzIGdhdGV3YXkgdG8g c3VjaCBxdWFsaXR5IHBpcGUgZm9yIFdlYlJUQyBtZWRpYSwgaW4gYQ0KPiBzaW5nbGUgTlNQIHBy b3ZpZGVkIENQRSwgc2NhbGluZyBmcm9tIHJlc2lkZW50aWFsIGFuZCB1cC4pDQoNClN1cHBvc2Ug d2UgZGVmaW5lIHdlbGwta25vd24gYW55Y2FzdCBUVVJOIHNlcnZlciBhZGRyZXNzZXMuIEhvdyB3 b3VsZCB0aGlzIG5vdCBiZSBzdWJqZWN0IHRvIHRoZSBzYW1lIHNlcnZpY2UgcXVhbGl0eSBpc3N1 ZXMgdGhhdCBwbGFndWVkIDZ0bzQ/IFRoYXQgaXMsIGFueW9uZSBjb3VsZCBzZXQgdXAgYSBiYWRs eS1tYWludGFpbmVkLCB1bmRlci1wcm92aXNpb25lZCBUVVJOIHNlcnZlciBhbmQgYW5ub3VuY2Ug aXQgb3ZlciBCR1AgdG8gdGhlIHdvcmxkLCBhcyBpdCB3YXMgZG9uZSBmb3INCjZ0bzQgcmVsYXlz LiBPciBqdXN0IGJhZCBCR1Agb3V0Ym91bmQgZmlsdGVyIGNvbmZpZ3VyYXRpb24uIEFuZCBob3cg Y2FuIHdlIHByZXZlbnQgdHJpYW5nbGUgcm91dGluZz8gVGhlcmUgaXMgbm90aGluZyBndWFyYW50 ZWVpbmcgdGhhdCB0aGUgYW55Y2FzdCBzZXJ2ZXIgeW91IHNlZSBpcyBiZWluZyBwcm92aWRlZCB0 byB5b3UgYnkgeW91ciBJU1AsIHJhdGhlciB0aGFuIGEgc2VydmVyIHNpdHRpbmcgb24gdGhlIG90 aGVyIHNpZGUgb2YgdGhlIHBsYW5ldC4NCi0tLSBHb29kIHBvaW50IC0gbmVlZHMgdG8gYmUgcmVz b2x2ZWQuIEZvciB0aGlzIEkgZG9uJ3QgaGF2ZSBhIHJlYWR5IGFuc3dlci4uLg0KQW4gYXV0by1k aXNjb3ZlcmVkIFRVUk4gc2VydmVyIG11c3QgYmUgdHJ1c3RlZCAod2hhdGV2ZXIgbWV0aG9kIGl0 IGlzIGRpc2NvdmVyZWQgYnkpLiBXZSBhcmUgdHJ1c3RpbmcgdGhlIG9uZSBwcm92aWRpbmcgdXMg d2l0aCBhbiBJUCBhZGRyZXNzIGFuZCBkZWZhdWx0IGdhdGV3YXkgYW55d2F5LiBJdCB3b3VsZCBi ZSBlYXN5IGlmIHdlIGNvdWxkIHJldXNlIHRoYXQgdHJ1c3QsIGluc3RlYWQgb2YgYW5vdGhlciBt ZWNoYW5pc21zLg0KDQpJcyB0aGVyZSBhIGdvb2Qgd2F5IGZvciB0aGUgYnJvd3NlciB0byBjaGVj ayB0aGF0IHRoZSBhbnljYXN0IGFkZHJlc3MgaXMgbm90IGhhbmRsZWQgYmV5b25kIHRoZSBuZXR3 b3JrIHNlcnZpY2UgcHJvdmlkZXIncyBkZWZhdWx0IGdhdGV3YXk/IElkZWFzPw0KDQoNCg0KVGhh bmtzLA0KU2ltb24NCi0tDQpEVE4gbWFkZSBlYXN5LCBsZWFuLCBhbmQgc21hcnQgLS0+IGh0dHA6 Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUuY2E8aHR0cDovL3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5j YS8+DQpOQVQ2NC9ETlM2NCBvcGVuLXNvdXJjZSAgICAgICAgLS0+IGh0dHA6Ly9lY2R5c2lzLnZp YWdlbmllLmNhPGh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhLz4NClNUVU4vVFVSTiBzZXJ2ZXIg ICAgICAgICAgICAgICAtLT4gaHR0cDovL251bWIudmlhZ2VuaWUuY2E8aHR0cDovL251bWIudmlh Z2VuaWUuY2EvPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlz dA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFp bHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyYW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcg bGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQoNCg== --_000_913383AAA69FF945B8F946018B75898A242AD903xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIEFuZHksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMsIFdlYlJUQyBicm93c2VyIHdpbGwg aGF2ZSB0byBhIHN1cHBvcnQgYSBudW1iZXIgb2YgbWVjaGFuaXNtcy4gVGhpcyB3YXMgZGlzY3Vz c2VkIGluIFJUQ1dFQiBtYWlsaW5nIGxpc3Qgc29tZXRpbWUgYmFjayBhbmQgc2VjdGlvbiAzLjMu NC4xIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1j YXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0DQogaGFzIGJlZW4gdXBkYXRlZCB0byByZWZsZWN0IHRo aXMgcG9pbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNhbiB5b3UgcGxlYXNlIGNs YXJpZnkgdGhlIGVuaGFuY2VtZW50cyBUVVJOIHNlcnZlciB5b3UgYXJlIGxvb2tpbmcgZm9yIGFu ZCB3aGF0IHByb2JsZW1zIGRvZXMgaXQgc29sdmUgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g SHV0dG9uLCBBbmRyZXcgW21haWx0bzphbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgNDoxOCBQTTxicj4NCjxiPlRv OjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxiPkNjOjwvYj4gdHJhbUBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJO IHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIHByaW1lIHVzZSBjYXNlIGZvciB0 aGlzIGlzIGRvY3VtZW50ZWQgaW4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTEyI3NlY3Rpb24t My4zLjUuMSI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi11 c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xMiNzZWN0aW9uLTMuMy41LjE8L2E+IGFuZCBJIHRo aW5rIHRoYXQgVFJBTSB3aWxsIHByb2JhYmx5IG1ha2UgZW5oYW5jZW1lbnRzIHRvIFRVUk4gZW5h Ymxpbmcgc3VjaCBhbiDigJxlbnRlcnByaXNlIGF1ZGl0aW5nIFRVUk4gc2VydmVy4oCdIHRvIGRv IGFuIGVmZmVjdGl2ZSBqb2Igb2YgbWFuYWdpbmcgV2ViUlRDIHRyYWZmaWMNCiBpbiBhbiBlbnRl cnByaXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIG9mIGNvdXJzZSBtb3JlIHRoYW4gb25lIHByb2Js ZW0gYW5kIG1hbnkgcG9zc2libHkgd2F5cyB0byBzb2x2ZSB0aGVtIGFuZCBJIHJlY2VudGx5IHVw ZGF0ZWQNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1dHRvbi1y dGN3ZWItbmF0LWZpcmV3YWxsLWNvbnNpZGVyYXRpb25zLTAzIj4NCmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWh1dHRvbi1ydGN3ZWItbmF0LWZpcmV3YWxsLWNvbnNpZGVyYXRpb25z LTAzPC9hPiB0byBsaXN0IHRoZXNlIGZvciBkaXNjdXNzaW9uIGluY2x1ZGluZyBQQ1AuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5VbmZvcnR1bmF0ZWx5IHNvbHV0aW9ucyBhcmUgbmVlZGVkIHRvZGF5IHdpdGhpbiBleGlz dGluZyBuZXR3b3JrcyBhbmQgUENQIGRvZXMgbm90IHNlZW0gc28gdXNlZnVsIGhlcmUgc28gd2Ug aGF2ZSB0byBsb29rIGF0IG11bHRpcGxlIHNvbHV0aW9ucyBhbmQgcHJvYmFibHkNCiBXZWJSVEMg YnJvd3NlcnMgaGF2ZSB0byBzdXBwb3J0IGEgbnVtYmVyIG9mIG1lY2hhbmlzbXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5SZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZHk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpIFs8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20i Pm1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTMgRmVi cnVhcnkgMjAxNCAwMzozNzxicj4NCjxiPlRvOjwvYj4gSHV0dG9uLCBBbmRyZXc7IEp1c3RpbiBV YmVydGk7IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpPGJyPg0KPGI+Q2M6PC9i PiA8YSBocmVmPSJtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tIj50aXJlZGR5QGljaXNjby5jb208 L2E+OyBTaW1vbiBQZXJyZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsNCjxhIGhyZWY9Im1haWx0bzp0 cmFtQGlldGYub3JnIj50cmFtQGlldGYub3JnPC9hPjsgTWFyYyBCbGFuY2hldDsgRGFuIFdpbmcg KGR3aW5nKTsgS2FybCBTdGFobDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3RyYW1dIE1pbGVz dG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJp c2UgYW5kIElTUHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgQW5keSw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRoZXJlIGFyZSBvdGhlciB3YXlzIHRvIHNvbHZlIHRoZSBwcm9ibGVtIGZvciBleGFt cGxlIHVzaW5nIFBDUC4gQ2FuIHlvdSBjbGFyaWZ5IGhvdyBkZXBsb3lpbmcgYSBUVVJOIHNlcnZl ciBpbiB0aGUgRW50ZXJwcmlzZSBwcm90ZWN0cyB0aGUgdXNlcnMgYW5kIHRoZSBuZXR3b3JrDQog PyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPi1UaXJ1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRyYW0gWzxhIGhyZWY9Im1haWx0bzp0cmFtLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5IdXR0b24sIEFuZHJldzxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg RmVicnVhcnkgMTMsIDIwMTQgMTowMCBBTTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFViZXJ0aTsg TXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk8YnI+DQo8Yj5DYzo8L2I+IDxhIGhy ZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5jb20iPnRpcmVkZHlAaWNpc2NvLmNvbTwvYT47IFNp bW9uIFBlcnJlYXVsdDsgT2xlZyBNb3NrYWxlbmtvOw0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0 Zi5vcmciPnRyYW1AaWV0Zi5vcmc8L2E+OyBNYXJjIEJsYW5jaGV0OyBEYW4gV2luZyAoZHdpbmcp OyBLYXJsIFN0YWhsPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6 IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQg SVNQczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgY2FzZSB3aGVyZSB0aGUg VFVSTiBzZXJ2ZXIgaXMgdGhlIG9ubHkgb3B0aW9uIG1heSBiZWNvbWUgY29tbW9uIHdpdGhpbiBl bnRlcnByaXNlIG5ldHdvcmtzIGFuZCB0aGF0IG1pZ2h0IGJlIGRlbGliZXJhdGUgZW50ZXJwcmlz ZSBwb2xpY3kgYmVjYXVzZSBpdCBwcm92aWRlcw0KIHRoZSBiZXR0ZXIgcGF0aCAoVURQIHRocm91 Z2ggdGhlIEYvVykgYW5kIHByb3RlY3RzIHRoZSB1c2VycyBhbmQgdGhlIG5ldHdvcmsuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0cmFtIFs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pm1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBVYmVydGk8YnI+DQo8Yj5T ZW50OjwvYj4gMTIgRmVicnVhcnkgMjAxNCAxNzo0Njxicj4NCjxiPlRvOjwvYj4gTXV0aHUgQXJ1 bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk8YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48YSBocmVm PSJtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ dGlyZWRkeUBpY2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ OyBTaW1vbiBQZXJyZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsNCjwvc3Bhbj48YSBocmVmPSJtYWls dG86dHJhbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5v cmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47IE1hcmMgQmxhbmNoZXQ7 IERhbiBXaW5nIChkd2luZyk7IEthcmwgU3RhaGw8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0 cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZv ciBlbnRlcnByaXNlIGFuZCBJU1BzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFncmVlLiBJZiBUVVJOIGlzIGluZGVlZCBiZWluZyBwcm92aWRl ZCBmb3IgdGhlIHVzZXIncyBiZW5lZml0LCB0aGUgY2xpZW50J3MgSUNFIGxvZ2ljIChiYXNlZCBv biBSVFQgb3Igc2ltaWxhcikgc2hvdWxkIHJlc3VsdCBpbiBpdCBwcmVmZXJyaW5nIHRoZSBUVVJO IHBhdGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDEyLCAyMDE0IGF0IDE6MjcgQU0s IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpICZsdDs8YSBocmVmPSJtYWlsdG86 bXBlcnVtYWxAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bXBlcnVtYWxAY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPlllcywgSSBiZWxpZXZlIHRoZSBzZWNvbmQgY2FzZSBpcyByYXJl LCBidXQgd291bGQgYmUgYmV0dGVyIHRoYW4gYSByYXQgcmFjZSBiL3cgYWRtaW5pc3RyYXRvcnMg dHJ5aW5nIHRvIGJsb2NrIHAycCB0cmFmZmljDQogYW5kIGZvcmNlIGl0IHRocm91Z2ggYSBUVVJO IHNlcnZlciBhbmQgYXBwcy9lbmRwb2ludHMgZmluZGluZyBzbWFydGVyIHdheXMgdG8gYnlwYXNz IHRoZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+TXV0aHU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9sZWcgTW9za2FsZW5rbyBbbWFpbHRv Ojwvc3Bhbj48YSBocmVmPSJtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tb20wNDAyNjdAZ21haWwuY29tPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQgMTowNyBQTTxicj4NCjxiPlRvOjwvYj4gTXV0aHUg QXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk8YnI+DQo8Yj5DYzo8L2I+IEp1c3RpbiBVYmVy dGk7IEthcmwgU3RhaGw7IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGlyZWRkeUBpY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRpcmVkZHlAaWNp c2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsNCiBNYXJjIEJs YW5jaGV0OyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgRGFuIFdpbmcgKGR3aW5nKTsgU2ltb24gUGVy cmVhdWx0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVS TiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1Bz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBUVVJOIHNlcnZlciBoYXMgdG8gYmUgdXNlZCB3 aGVuIGl0IGlzIGVpdGhlciB0aGUgb25seSBvcHRpb24sIG9yIGlmIGl0IHByb3ZpZGVzIGEgYmV0 dGVyIHBhdGggKEkgZ3Vlc3MgdGhlIHNlY29uZCBjYXNlIGlzIHJhdGhlciByYXJlKS48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBGZWIgMTEsIDIwMTQgYXQgMTE6 MzIgUE0sIE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpICZsdDs8YSBocmVmPSJt YWlsdG86bXBlcnVtYWxAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bXBlcnVtYWxAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiYjNDM7MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZvcmNpbmcgYWxsIHRyYWZmaWMg dGhyb3VnaCBhIFRVUk4gc2VydmVyIGFuZCBleHBlY3RpbmcgaXQgd291bGQgcHJvdmlkZSB0aGUg YmVzdCB1c2VyIGV4cGVyaWVuY2UgZG9lc24ndCBsb29rIHRoZSByaWdodA0KIGFwcHJvYWNoLiBJ bnN0ZWFkLCBpZiBhIHBhdGggdGhyb3VnaCBhIFRVUk4gc2VydmVyIGV4aXN0cyBhbmQgZG9lcyBw cm92aWRlIGxvd2VyIFJUVCwgaml0dGVyIGV0YywgYmVpbmcgYWJsZSB0byBkZXRlY3QgYW5kIHVz ZSAob3Igc3dpdGNoIHRvKSB0aGF0IHBhdGggbWlnaHQgYmUgZGVzaXJhYmxlLi48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NdXRo dTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBbbWFpbHRvOjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJh bS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPnRyYW0tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0IDExOjQzIEFNPGJyPg0KPGI+VG86 PC9iPiBLYXJsIFN0YWhsPGJyPg0KPGI+Q2M6PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRp cmVkZHlAaWNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij50aXJlZGR5QGljaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij47IE1hcmMgQmxhbmNoZXQ7DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRm Lm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgRGFuIFdpbmcgKGR3 aW5nKTsgU2ltb24gUGVycmVhdWx0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gTWls ZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJw cmlzZSBhbmQgSVNQczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbmxpbmUuPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgRmViIDExLCAyMDE0IGF0IDI6MzcgUE0sIEth cmwgU3RhaGwgJmx0OzxhIGhyZWY9Im1haWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlIiB0YXJn ZXQ9Il9ibGFuayI+a2FybC5zdGFobEBpbnRlcnRleC5zZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+TGlzdGVuaW5nIHRvIHRoaXMgdGhyZWFkLCBJIGFt IGFmcmFpZCB3ZSBhcmUgbWlzc2luZyB0aGUgdmVyeSBwb2ludCBhbmQgbmVjZXNzaXR5IGZvciB0 aGlzIG1pbGVzdG9uZSE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LSBUaGVyZSBhcmUgc2V2 ZXJlIE5BVCB0cmF2ZXJzYWwgYW5kIHF1YWxpdHkgaXNzdWVzIHRoYXQgc2hvdWxkIGFuZCBjYW4g YmUgZGVhbHQgd2l0aCBieSBhIGdvb2QgYXV0by1kaXNjb3ZlcnkNCiBtZWNoYW5pc20gYW5kIHRo ZSByaWdodCB1c2FnZSBieSB0aGUgdHVybiBjbGllbnQgKHRoZSBXZWJSVEMgYnJvd3Nlcik8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi PlRoZXJlIGFyZSB3YXlzLCBub3Qgb25seToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RW50ZXJwcmlzZXMg b3IgSVNQcyB3aXNoaW5nIHRvIHByb3ZpZGUgdGhlaXIgb3duIFRVUk4gc2VydmVyLCBpbiBhbiBh dHRlbXB0IHRvIHJlZHVjZSBzby1jYWxsZWQgJnF1b3Q7dHJpYW5nbGUgcm91dGluZyZxdW90Oyxu ZWVkIGEgbmV3IGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj5CdXQgYWxzbzogLSBOU1BzIChOZXR3b3JrIFNlcnZpY2UgUHJvdmlkZXJzKSB3YW50IHRv IHByb3ZpZGUgYSBwYXRoIHdoZXJlIHRoZSBiYW5kd2lkdGggb2YgV2ViUlRDIGlzIGJldHRlcg0K IGNvcGVkIHdpdGguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIE5TUHMgb3Ig RW50ZXJwcmlzZXMgd2FudCB0byBvZmZlciBhbiBJbnRlcm5ldCBhY2Nlc3MgcXVhbGl0eSBwaXBl IGZvciBwcmlvcml0aXplZCBSVEMgKFJlYWwgVGltZSBDb21tdW5pY2F0aW9uKQ0KIHRyYWZmaWMu IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIEVudGVycHJpc2VzIGhhdmluZyByZXN0cmlj dGl2ZSBmaXJld2FsbHMsIHdhbnQgdG8gcHJvdmlkZSBhIFVEUC1wYXRoIGZvciBXZWJSVEMgYW5k IHBvc3NpYmx5IGFsc28gZm9yDQogYmV0dGVyIHF1YWxpdHkgd2hlcmUgUlRDIGRvIG5vdCBjb21w ZXRlIHdpdGggZGF0YSB0cmFmZmljLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVl Ij5BbHNvIGNvbnNpZGVyaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIE1v YmlsaXR5OyBJdCBpcyBjb21tb24gdG8gbW92ZSBmcm9tIGEgTEFOIHRvIGFjY2Vzc2luZyB2aWEg V2lGaSBvciAzRy80RyBPVFQgY2hhbm5lbHMsIGFsbCBzaG91bGQgYmUNCiBhYmxlIHRvIGF1dG9t YXRpY2FsbHkgb2ZmZXIgdGhlaXIgb3duIG9wdGltYWwgVFVSTiBzZXJ2ZXI8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ VGhpcyBsZWFkcyB1cyBpbnRvDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A74oCcVFVSTuKApnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnQ0KPHNwYW4gc3R5bGU9 ImNvbG9yOmJsdWUiPmV0YyEgSXQgaXMgbm90IGEgbWlzdGFrZSwgYnV0IHRoZSB2ZXJ5IG5lZWQg Zm9yIHRoaXMgbWlsZXN0b25lITwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFnYWluLCBpdCBoYXMg bm90IGJlZW4gZGVtb25zdHJhdGVkIHdoeSBUVVJOIGlzIHRoZSByaWdodCB0ZWNobm9sb2d5IGhl cmUsIGNvbXBhcmVkIHRvIGEgbW9yZSB0cmFuc3BhcmVudCBmbG93IGlkZW50aWZpY2F0aW9uIHRv b2wgbGlrZSBNQUxJQ0UuIFdlIGRvbid0IGZvcmNlIGFsbCBIVFRQIHJlcXVlc3RzDQogdG8gbG9j YXRlIGEgSFRUUCBwcm94eSB2aWEgYW55Y2FzdCwgSSBkb24ndCBzZWUgd2h5IHdlIG5lZWQgdG8g ZG8gdGhlIHNhbWUgZm9yIFdlYlJUQy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+V2hhdCBhcmUgdGhlIGhl c2l0YXRpb25zIHJhaXNlZCBoZXJlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgVFVS TiBwcmltYXJpbHkgdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dzLCBhcyBvcHBvc2VkIHRvIHVzaW5n IGl0IGFzIGEgTkFUIHRyYXZlcnNhbCB0b29sLiBUaGlzIG1ha2VzIG1lIGNvbmNlcm5lZA0KIHRo YXQgd2UgbWF5IGJlIHVzaW5nIHRoZSB3cm9uZyB0ZWNobm9sb2d5IHRvIHNvbHZlIHRoZSBwcm9i bGVtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SXQgaXMgY29ycmVjdCB0aGF0 IElDRS9TVFVOL1RVUk4gd2FzIGRlc2lnbmVkIHRvIGFkZHJlc3MgdGhlIE5BVC9GaXJld2FsbCB0 cmF2ZXJzYWwgcHJvYmxlbSBhc3NvY2lhdGVkDQogd2l0aCByZWFsLXRpbWUgY29tbXVuaWNhdGlv biAoU0lQIGF0IHRoYXQgdGltZSkuIEhvd2V2ZXIsIGl0cyBsYXJnZXN0IGZsYXcvcHJvYmxlbSBp cyB0aGF0IHF1YWxpdHkgdGhpbmdzIHdlcmUgbm90IChjb3VsZCBub3QgYmU/KSBjb25zaWRlcmVk LiBUaGUgbWV0aG9k4oCZcyB2ZXJ5IGlkZWEgKGxpa2UgYWxsIHNpbWlsYXIgbWV0aG9kcyBmb3Ig Z2V0dGluZyBSVEMgdGhyb3VnaCBvcmRpbmFyeSBOQVQvRmlyZXdhbGxzKSBpcyB0byBmb29sIHRo ZSBtZWRpYQ0KIHRocm91Z2ggYSBOQVQvRmlyZXdhbGwgdGhhdCBpcyB1bmF3YXJlIG9mIHdoYXQg aXMgaGFwcGVuaW5nLiBUaHVzLCB0aGlzIGlzIHJvb3Qgb2YgcXVhbGl0eSBpc3N1ZXMgKGFuZCBi YW5kd2lkdGggYWxsb2NhdGlvbiBvcHRpbWl6YXRpb24pIHRoYXQgbmVlZHMgdG8gYmUgZGVhbHQg d2l0aDogUmVhbC10aW1lIHRyYWZmaWMgZmlnaHRpbmcgd2l0aCBhIGRhdGEgdHJhZmZpYyBjcm93 ZGVkIGNvbmdlc3Rpb24gcG9pbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRo aW5rIHRoYXQgJnF1b3Q7Zm9vbGluZyZxdW90OyBpcyBhbiBpbmNvcnJlY3QgZGVzY3JpcHRpb24u IFRoZSBOQVQgaXMgc3VwcG9zZWQgdG8gYmUgdHJhbnNwYXJlbnQgdG8gdGhlIGNsaWVudC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6Ymx1ZSI+QnV0LCBhIEJMRVNTSU5HIG9mIElDRS9TVFVOL1RVUk4gaXMgdGhhdCBpdCBjYW4g YmUgc2VlbiBhcyBhIGxlZ2l0aW1hdGUgcmVxdWVzdCBmb3IgYSBzdWl0YWJsZSBwaXBlIGZvcg0K IHF1YWxpdHkgZGVtYW5kaW5nIHJlYWwgdGltZSB0cmFmZmljLiA8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOmJsdWUiPko8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj5JQ0UgaXMgYSBwcmUtcHJvdG9jb2wgeW91IHVzZSBiZWNhdXNlIHlvdSB3 YW50IGEgcGF0aCBmb3IgcmVhbC10aW1lIG1lZGlhIGJldHdlZW4gcGFydGllcy4gSGVyZTogVGhl IGJyb3dzZXINCiBzYXlzIGtub2NrIGtub2NrLCBJIHdhbnQgdG8gZ2V0IG1lZGlhIHRocm91Z2gg KGFuZCBvZiBjb3Vyc2Ugd2l0aCBhcyBnb29kIHF1YWxpdHkgYXMgcmVxdWlyZWQgYW5kIHBvc3Np YmxlKS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Ymx1ZSI+SWYgdGhlIE5BVC9GaXJld2FsbCBvd25lciBhbmQgbmV0d29yayBvd25lciBh cmUgYWxsb3dlZCB0byBzZWUgdGhlc2UgcmVxdWVzdHMsIHRoZXkgY2FuIGhlbHAvYXNzaXN0IGlu DQogYWNoaWV2aW5nIHRoZSBnb29kIG1lZGlhIHBhdGguIElmIHRoZXkgYXJlIG5vdCBhd2FyZSwg dGhleSBjYW5ub3QgaGVscCE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1 ZSI+SG9wZSB0aGlzIG1hZGUgaXQgdW5kZXJzdGFuZGFibGUgb24gYW4gb3ZlcnZpZXcgbGV2ZWwg aG93IHRoaXMgY2FuIGJlY29tZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4N CiDigJxUVVJO4oCmdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dz4oCdPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPkl0IGlzIGFsc28gdGhlIE9OTFkgd2F5IEkgY2FuIHNlZSB0byBhY2hpZXZlIHdo YXQgd2Ugd2FudCB0byBhY2hpZXZlIGFuZCBzaG91bGQgYmUgdGhlIGFpbSBhbmQgcmVxdWlyZW1l bnQNCiBvZiB0aGlzIG1pbGVzdG9uZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkkgYW0gdGFsa2luZyBhYm91dCBnZW5lcmFsIHVz YWdlIG9mIFdlYlJUQyBvdmVyIEludGVybmV0L21vYmlsZSBPVFQgKG5vdCBmZWVkaW5nIFdlYlJU QyBpbnRvIGFwcGxpY2F0aW9uDQogc3BlY2lmaWMgbmV0d29ya3MgbGlrZSBJTVMgd2hlcmUgb3Ro ZXIgbWV0aG9kcyBtYXkgZXhpc3QpLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlRoaXMgaXMgZ29vZCwgbm90IGV2aWwhPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5J ZiB0aGUgaGVzaXRhdGlvbnMgYXJlIHJhaXNlZCBiZWNhdXNlIG9mIGEgYmVsaWVmL2hvcGUvd2lz aCB0aGF0IHRoZXJlIGFyZSBubyBvciB3aWxsIG5vdCBiZSBzZXZlcmUgcXVhbGl0eQ0KIGlzc3Vl cyDigJxiZWNhdXNlIGl0IGlzIGFsbCBhYm91dCBiYW5kd2lkdGjigJ0sIOKAnGl0IHdpbGwgcmVz b2x2ZSBpdHNlbGYgd2l0aCB0aW1l4oCdIGV0Yy4sIEkgc3Ryb25nbHkgb2JqZWN0ISBUaGF0IGlz IHdyb25nIGFuZCB3aWxsIGJlIHZlcnkgZGV0cmltZW50YWwgZm9yIFdlYlJUQyB1c2FnZS4gV2Ug YWxyZWFkeSBzZWUgaXQgYW5kIEkgY2FuIGdpdmUgbnVtZXJvdXMgZXhhbXBsZXMgb2YgaG93IG11 Y2ggbGVzcyBxdWFsaXR5IGRlbWFuZGluZyBWb0lQDQogaXMvaXMgbm90IGhhbmRsZWQgcXVhbGl0 eSB3aXNlIGFuZCB0aGF0IGl0IG1hdHRlcnMuIEFuZCwgd2hhdCB3b3VsZCBiZSBiYWQgY29uc2lk ZXJpbmcgcXVhbGl0eSBpc3N1ZXMgYW5kIGFsbG93aW5nL2VuY291cmFnaW5nIG1ldGhvZHMgdG8g ZGVhbCB3aXRoIHRoZW0/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi PklmIHRoZSBoZXNpdGF0aW9ucyBhcmUgcmFpc2VkLCBiZWNhdXNlIG9mIHN1c3BpY2lvbiB0aGF0 IHRoZSBtZXRob2RzIHdlIG1heSByZWNvbW1lbmQgbWF5IGJlIG1pc3VzZWQgdG8NCiBzdG9wL2Js b2NrL2Rlc3Ryb3kgV2ViUlRDIHVzYWdlIChlLmcuIHRvIHByb3RlY3QgaW5jb21lIGZyb20gY2Fy cmllciB0ZWxlcGhvbnkgdHJhZmZpYyksIEkgY291bGQgdW5kZXJzdGFuZCBhbmQgd291bGQgZmln aHQgdGhlIHNhbWUgYmF0dGxlLiBCdXQgaG9wZWZ1bGx5LCB0aG9zZSBkYXlzIGFyZSAoc29vbikg b3ZlciDigJMgQXQgbGVhc3QgZm9yd2FyZCB0aGlua2luZyBjYXJyaWVy4oCZcyByZWFsaXplIHRo YXQgYWxyZWFkeS4gV2ViIFJUQyB3aWxsDQogaGFwcGVuLiBXaGljaCBjdXN0b21lcnMgd2FudCB0 byBwYXkgZm9yIGFuIGFjY2VzcyB3aXRoIGJsb2NrZWQgV2ViUlRDPyBUaGUgY2FycmllcuKAmXMg b2ZmZXJpbmcvYXNzdXJpbmcgZ29vZCBXZWJSVEMgd2lsbCByYXRoZXIgZ2V0IHRoZSBjdXN0b21l cnMgYW5kIGluY29tZQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibHVlIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+LiAoTWF5YmUgdGhlIFdlYiBicm93c2VyIGNhbiBkZXRlY3QgYW5k IGVuY291cmFnZSB0aGlz4oCmKTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPklmIHRoZXJlIGFyZSB0ZWNobmljYWwg Y29uY2VybnMgb2YgYmFkIHJlc3VsdCwgb3IgYmV0dGVyIG1ldGhvZHMgYWxsb3dpbmcgbmV0d29y ayBwcm92aWRlcnMgYW5kIExBTiBtYW5hZ2Vycw0KIHRvIG9mZmVyIGFuZCBpbmZvcm0gdGhlIGJy b3dzZXIgdGhhdCB0aGVyZSBhcmUgZ29vZCBtZWRpYSBwYXRocyB0byBiZSB1c2VkLCBhbmQgdGhh dCB0aGUgd2ViIGJyb3dzZXIgYXV0b21hdGljYWxseSBjYW4gY2hvc2UgdGhvc2UsIHRoZW4gbGV0 IHVzIGFsbCB1bmRlcnN0YW5kIHRob3NlLCBzbyB3ZSBjYW4gYWNoaWV2ZSB3aGF0IHNob3VsZCBi ZSBhY2hpZXZlZCBieSB0aGlzIG1pbGVzdG9uZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlNreXBlLCBIYW5nb3V0cywgRmFjZXRpbWUgYXJlIGRvaW5nIGJpbGxpb25zIG9mIG1pbnV0 ZXMgcGVyIHdlZWsgYW5kIHRoZSBJbnRlcm5ldCBoYXMgbm90IG1lbHRlZCB5ZXQuIElmIHdlIG5l ZWQgdG8gZG8gZmxvdyBpZGVudGlmaWNhdGlvbiB0byBhbGxvdyB0cmFmZmljIHRvIGJlIHByaW9y aXRpemVkLCBmaW5lDQogKHNlZSBhYm92ZSByZWdhcmRpbmcgbXkgcHJlZmVycmVkIGFwcHJvYWNo KSwgYnV0IGZvcmNpbmcgYWxsIFdlYlJUQyB0cmFmZmljIHRocm91Z2ggYSBNSVRNIChUVVJOIHNl cnZlcikgaXMgYSBtdWNoIGJpZ2dlciBqdW1wIHRoYXQgSSBkb24ndCB5ZXQgc2VlIHRoZSBqdXN0 aWZpY2F0aW9uIGZvci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkluIHNob3J0OiBUVVJOIGlzIGEgdGVjaG5vbG9neSB0aGF0IGlzIHN1 cHBvc2VkIHRvIGZhZGUgYXdheSB3aXRoIHRoZSBtb3ZlIHRvIElQdjYuIEkgZG9uJ3QgdGhpbmsg d2Ugd2FudCB0byBtYWtlIGl0IGEgY3JpdGljYWwgZWxlbWVudCBvZiBXZWJSVEMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPi9LYXJsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnLDpW46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IERhbiBXaW5nIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkd2luZ0BjaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHdpbmdA Y2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGJyPg0K PGI+U2tpY2thdDo8L2I+IGRlbiAxMSBmZWJydWFyaSAyMDE0IDE4OjI1PGJyPg0KPGI+VGlsbDo8 L2I+IDwvc3Bhbj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk1hcmMgQmxh bmNoZXQ8YnI+DQo8Yj5Lb3BpYTo8L2I+IEp1c3RpbiBVYmVydGk7IDwvc3Bhbj48YSBocmVmPSJt YWlsdG86dGlyZWRkeUBpY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1Yi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50aXJlZGR5QGljaXNjby5jb208L3NwYW4+PC9hPjxzcGFu IGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ow0KIEthcmwgU3RhaGw7IDwvc3Bhbj48 YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47IFNpbW9uIFBlcnJlYXVsdDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJTViI+PGJyPg0KPGI+w4RtbmU6PC9iPiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBU VVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElT UHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5PbiBGZWIgMTEsIDIwMTQsIGF0IDk6 MDggQU0sIE1hcmMgQmxhbmNoZXQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWFyYy5ibGFu Y2hldEB2aWFnZW5pZS5jYSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIj5tYXJjLmJs YW5jaGV0QHZpYWdlbmllLmNhPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViI+Jmd0Ow0KIHdyb3Rl Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBs YW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPkxlIDIwMTQtMDItMTEgw6AgMDA6MzksIERhbiBX aW5nICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmR3aW5nQGNpc2NvLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIGxhbmc9IlNWIj5kd2luZ0BjaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIGxh bmc9IlNWIj4mZ3Q7IGEgw6ljcml0IDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpPbiBGZWIgMTAsIDIwMTQsIGF0IDU6MzAgUE0s IEp1c3RpbiBVYmVydGkgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUu Y29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPmp1YmVydGlAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZndDsNCiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Hb29kIHRvIHNlZSB0aGVyZSBpcyBhIGxvdCBvZiBpbnRl cmVzdCBmb3IgdGhpcyBtaWxlc3RvbmUuIEJ1dCBiYXNlZCBvbiB0aGUgZGVzY3JpcHRpb24gaGVy ZSwgaXQgc2VlbXMNCiBsaWtlIHdlIHdhbnQgdG8gdXNlIFRVUk4gcHJpbWFyaWx5IHRvIGlkZW50 aWZ5IFdlYlJUQyBmbG93cywgYXMgb3Bwb3NlZCB0byB1c2luZyBpdCBhcyBhIE5BVCB0cmF2ZXJz YWwgdG9vbC4gVGhpcyBtYWtlcyBtZSBjb25jZXJuZWQgdGhhdCB3ZSBtYXkgYmUgdXNpbmcgdGhl IHdyb25nIHRlY2hub2xvZ3kgdG8gc29sdmUgdGhlIHByb2JsZW0uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+JiM0MzsxLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkkgd291bGQgcHJlZmVyIGFsbG93aW5nIGZsb3dzIHRvIGVzdGFibGlzaCB0aGVt c2VsdmVzIHVzaW5nIHRoZWlyICdiZXN0JyBwYXRoLCBhbmQgdGhlIGJlc3QgcGF0aCBpcw0KIHNl bGRvbSB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIuICZuYnNwO1doZW4gd2UgaW1hZ2luZSBJUHY2IGlu IG91ciBmdXR1cmUsIHdlIGRvbid0IHdhbnQgdG8gZm9yY2UgYW4gYXBwbGljYXRpb24tbGV2ZWwg cHJveHkgKFRVUk4pIHNlcnZlciBvbiB0aGUgcGF0aCBzb2xlbHkgZm9yIHRyYXZlcnNpbmcgYW4g SVB2NiBmaXJld2FsbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JdCBzZWVtcyB0 aGlzIHRocmVhZCBpcyBjb25mbGF0aW5nIGFsbCB0aGUgcG9zc2libGUgcmVhc29ucyAvIGp1c3Rp ZmljYXRpb25zIGZvciBUVVJOOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOyAqIG1vYmlsaXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7ICogTkFUIHRyYXZlcnNhbCAoYm90aCBlbmRwb2ludHMgYXJlIGJl aGluZCBlbmRwb2ludC1kZXBlbmRlbnQgbWFwcGluZyBOQVRzKTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1Yi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAqJm5ic3A7ZmlyZXdhbGwgdHJhdmVyc2Fs IChmaXJld2FsbCBibG9ja3MgVURQKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOyAqIGVuaGFuY2luZyBwcml2YWN5PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+VW5mb3J0dW5hdGVseSB0aGUgVFVSTiBzZXJ2ZXIgbm9yIHRoZSBl bmRwb2ludCByZWFsbHkga25vdyB3aGljaCBvZiB0aG9zZSB1c2UtY2FzZXMgaXMgZGVzaXJlZCAo YnkgdGhlDQogdXNlciBvciBieSB0aGUgSVQgbmV0d29yayBhZG1pbmlzdHJhdG9yKSBvciBuZWNl c3NhcnkgKGZvciB0aGUgY2FsbCB0byB3b3JrIGF0IGFsbCkuDQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPkRhbiwgd2hpbGUgSSBhZ3JlZSBp biBwcmluY2lwbGUsIEkgZG91YnQgdGhhdCBhIHVzZXIgY291bGQgZXZlciBzYXkgJnF1b3Q7SSB3 YW50IG1vYmlsaXR5IG9yIEkgd2FudCBOQVQgdHJhdmVyc2FsJnF1b3Q7LiBJIHRoaW5rIHRoZSB1 c2VyIG9ubHkgd2FudCB0aGUgY2FsbCB0byBzdWNjZWVkLCB3aGF0ZXZlcg0KIHRoZSBwcm9wZXJ0 aWVzIG9mIGl0cyBuZXR3b3JrIHBvaW50IG9mIGF0dGFjaG1lbnQgYXJlLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5TbyB3aGF0 IGNhbiB3ZSBkbz8gJm5ic3A7U2hvdWxkIHRoZSBUVVJOIHNlcnZlciBwcm92aWRlIGFueSBhbmQg YWxsIHNlcnZpY2VzIHRoZSBUVVJOIGNsaWVudCBtaWdodCBwb3NzaWJseSB3YW50LCBhcyB0aGF0 IGlzIHdoYXQgYSByb2J1c3QgVFVSTiBzZXJ2ZXIgd2lsbCBkbywgYW5kIHRoZQ0KIGVuZHBvaW50 IHNob3VsZCBwcmVmZXIgVFVSTiBjYW5kaWRhdGVzIG92ZXIgYWxsIG90aGVycyBiZWNhdXNlIHRo ZXJlIG1pZ2h0IGJlIHNvbWUgZnVuY3Rpb25hbGl0eSAvIHVzZWZ1bG5lc3Mgb2YgVFVSTiB0aGF0 IHRoZSB1c2VyIG1pZ2h0IGdhaW4gdGhyb3VnaCBUVVJOIChlLmcuLCBlbmhhbmNlZCBwcml2YWN5 KT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4tZDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7VGhpcyBzZWVtcyBwcm9ibGVtYXRpYy4gJm5ic3A7UGVyaGFwcyB3ZSBu ZWVkIGEgd2F5IHRvIHNpZ25hbCB0aGUgZGVzaXJlZCB1c2UtY2FzZSAoJnF1b3Q7dHJhaXQmcXVv dDspLCBvciBhcyBKdXN0aW4NCiBzdWdnZXN0cywgdXNpbmcgYSBkaWZmZXJlbnQgdGVjaG5vbG9n eSBmb3Igc29tZSBvZiB0aGVzZSB1c2UtY2FzZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+LWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g bGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gTW9uLCBGZWIgMTAsIDIwMTQgYXQg MzoxOCBQTSwgS2FybCBTdGFobCZuYnNwOyZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmthcmwu c3RhaGxAaW50ZXJ0ZXguc2UiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+a2FybC5zdGFobEBpbnRlcnRleC5zZTwvc3Bhbj48L2E+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsmbmJzcDt3cm90ZTo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TaW1vbiw8YnI+DQo8YnI+DQpHb29kIHF1ZXN0aW9ucyAt IHNlZSBpbmxpbmUgYmVsb3cgLS0mZ3Q7IC48YnI+DQpTb21lIG1vcmUgdGhvdWdodCBpcyByZXF1 aXJlZCE8YnI+DQo8YnI+DQovS2FybDxicj4NCjxicj4NCi0tLS0tVXJzcHJ1bmdsaWd0IG1lZGRl bGFuZGUtLS0tLTxicj4NCkZyw6VuOiB0cmFtIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KIEbDtnIgU2ltb24gUGVy cmVhdWx0PGJyPg0KU2tpY2thdDogZGVuIDEwIGZlYnJ1YXJpIDIwMTQgMTU6MTY8YnI+DQpUaWxs OiBLYXJsIFN0YWhsOyZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50 cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+OyZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRp cmVkZHlAaWNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxicj4NCsOEbW5lOiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZl ciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KS2FybCw8YnI+DQo8YnI+DQpJdCBpcyBncmVh dCB0byBzZWUgc3VjaCBlbnRodXNpYXNtISBUaGFua3MhPGJyPg0KPGJyPg0KSSBoYXZlIGEgY291 cGxlIHRlY2huaWNhbCBxdWVzdGlvbnMuLi48YnI+DQo8YnI+DQpMZSAyMDE0LTAyLTA4IDA4OjEx LCBLYXJsIFN0YWhsIGEgw6ljcml0IDo8YnI+DQomZ3Q7IC0gTm90ZSB0aGF0IHRvIGFjaGlldmUg c29tZSBvZiB0aGUgYWJvdmUgcG9pbnRzLCBUVVJOIG11c3QgYmUgZmF2b3JlZDxicj4NCiZndDsg b3ZlciBTVFVOIHRvIGVuZm9yY2UgdGhhdCB0aGUgVFVSTi1wYXRoIGFjdHVhbGx5IGlzIHVzZWQu IChUaGUgQW55Y2FzdDxicj4NCiZndDsgbWV0aG9kIHN1Z2dlc3RlZCBiZWxvdywg4oCcYXV0b21h dGljYWxseeKAnSBkb2VzIHRoaXMuKTxicj4NCjxicj4NCkkgdW5kZXJzdGFuZCB0aGUgU1RVTiB2 cyBUVVJOIHByaW9yaXR5IGlzc3VlLiBCdXQgSSBkb24ndCBzZWUgaG93IGFueWNhc3QgYWZmZWN0 cyBpdCBpbiBhbnkgd2F5LiBDYW4geW91IHBsZWFzZSBleHBsYWluPzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS0tIEdvb2QgcG9pbnQgLSBJIHdhcyBhIGJpdCBxdWljayBo ZXJlIChtYXliZSB0b28gcXVpY2spPGJyPg0KV2UgaGF2ZSBnaXZlbiB0aGlzIHF1aXRlIGJpdCBv ZiB0aG91Z2h0LCBzaW5jZSBldmVuIGlmIGEgVFVSTiBzZXJ2ZXIgaXMgcHJvdmlkZWQgYW5kIGRp c2NvdmVyZWQsIENVUlJFTlQgdXNhZ2Ugb2YgSUNFIG1heSBzdWdnZXN0IGEgY2FuZGlkYXRlIGZy b20gdGhlIHJlbW90ZSBwYXJ0eSB0aGF0IHdpbGwgbWFrZSBhIGNvbm5lY3Rpb24gd2l0aG91dCB0 aGUgbmVlZC91c2FnZSBvZiB0aGUgVFVSTiBzZXJ2ZXIgKHRoYXQgd2Ugd2FudGVkIHRvIGJlIHVz ZWQNCiBmb3IgdGhlIGdvb2QgcHVycG9zZXMgbGlzdGVkKS48YnI+DQo8YnI+DQpUaGUgb25seSB3 YXkgd2UgZm91bmQgYXJvdW5kIHRoaXMsIHdhcyB0byBzdG9wIFNUVU4gdGhyb3VnaCB0aGUgSVAg ZGVmYXVsdCBnYXRld2F5IChsaWtlIGEgcmVzdHJpY3RpdmUgRW50ZXJwcmlzZSBmaXJld2FsbCBk b2VzIGluaGliaXRpbmcgSUNFIGNvbm5lY3Rpdml0eSwgd2hpY2ggb3RoZXJzIGFyZSBjb25jZXJu ZWQgYWJvdXQuLi4pLiBTaW5jZSB0aGUgcHJvdmlzaW9uaW5nIG9mIGF1dG8tZGlzY292ZXJ5IHVz aW5nIHRoZSBhbnljYXN0IG1lY2hhbmlzbSwNCiB3b3VsZCBiZSBhZGRpbmcgYSByb3V0ZSBpbiBh IGRlZmF1bHQgZ2F0ZXdheSwgYWRkaW5nIGEgZmlyZXdhbGwgcnVsZSB0byBlYXQgU1RVTiBwYWNr ZXRzIHdvdWxkIGFzc3VyZSB0aGF0IHRoZSBwcm92aXNpb25lZCBUVVJOIHNlcnZlciBhY3R1YWxs eSBiZWNvbWVzIHVzZWQgKGFuZCBub3QgYnlwYXNzZWQgJnF1b3Q7YnkgYWNjaWRlbnQmcXVvdDsp LiAoVGhhdCB3YXMgdGhlIHRob3VnaHQgYmVoaW5kIHRoZSDigJxhdXRvbWF0aWNhbGx54oCdIHdp dGhpbiBxdW90ZXMuKTxicj4NCjxicj4NCkJVVCwgc2luY2UgeW91IGJyb3VnaHQgdXAgdGhlIHF1 ZXN0aW9uLCBhc3N1bWluZyB0aGF0IHdlIGhhdmUgdGhlIHBvd2VyIHRvIGVuZm9yY2UgV2ViUlRD IHVzYWdlIG9mIElDRSwgSSBiZWxpZXZlIGEgTVVTVCByZXF1aXJlbWVudCB0byB1c2UgYW4gYXV0 by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVyIGluc3RlYWQgb2YgU1RVTiwgd291bGQgc29sdmUgdGhl IHNhbWUgcHJvYmxlbS4gSG93ZXZlciwgdGhpbmtpbmcgZnVydGhlciAoaW4gcmVsYXRpb24NCiB0 byB5b3VyIG5leHQgcXVlc3Rpb24gLSAmcXVvdDthbnlvbmUgY291bGQgc2V0IHVwIGEgYmFkbHkt bWFpbnRhaW5lZCZxdW90OyAtIGVuZm9yY2luZyBzdWNoIElDRSB1c2FnZSBtYXkgbm90IGJlIGdv b2QuKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQomZ3Q7IC0gM15y ZCBUaGUgQW55Y2FzdCBtZXRob2QgYmVsb3cg4oCTIEkgc2VlIG5vIHByb2JsZW08YnI+DQomZ3Q7 PGJyPg0KJmd0OyBJdCBhbHNvIGhhcyB0aGUgYWR2YW50YWdlIG9mIGVuY291cmFnaW5nIChidXQg bm90IHJlcXVpcmluZykgdGhlPGJyPg0KJmd0OyBTVFVOL1RVUk4gdG8gYmUgYnVpbHQgaW4gdGhl IGRlZmF1bHQgZ2F0ZXdheSBvciBOQVQvZmlyZXdhbGwvYWNjZXNzPGJyPg0KJmd0OyByb3V0ZXIg aXRzZWxmLCB3aXRoIGEgc2Vjb25kIGludGVyZmFjZSB0byBhIHB1YmxpYyBJUCBhZGRyZXNzIG9u IHRoZTxicj4NCiZndDsgV0FOIHNpZGUuIChDdXJyZW50IHZvbHVtZSBkZXBsb3llZCwgbG93IGNv c3QgTlNQIHRyaXBsZSBwbGF5IG1vZGVtczxicj4NCiZndDsgdXN1YWxseSBoYXZlIGEgcXVhbGl0 eSBhc3N1cmVkIGxldmVsIDIgb3IgbGV2ZWwgMyBXQU4gcGlwZSBmb3IganVzdDxicj4NCiZndDsg dm9pY2UgKGFuZCBhbm90aGVyIGZvciBJUFRWKSDigJMgVGhlIGFueWNhc3QgZGlzY292ZXJlZCBU VVJOLXNlcnZlciBjYW48YnI+DQomZ3Q7IGJlIHRoZSBhY2Nlc3MgZ2F0ZXdheSB0byBzdWNoIHF1 YWxpdHkgcGlwZSBmb3IgV2ViUlRDIG1lZGlhLCBpbiBhPGJyPg0KJmd0OyBzaW5nbGUgTlNQIHBy b3ZpZGVkIENQRSwgc2NhbGluZyBmcm9tIHJlc2lkZW50aWFsIGFuZCB1cC4pPGJyPg0KPGJyPg0K U3VwcG9zZSB3ZSBkZWZpbmUgd2VsbC1rbm93biBhbnljYXN0IFRVUk4gc2VydmVyIGFkZHJlc3Nl cy4gSG93IHdvdWxkIHRoaXMgbm90IGJlIHN1YmplY3QgdG8gdGhlIHNhbWUgc2VydmljZSBxdWFs aXR5IGlzc3VlcyB0aGF0IHBsYWd1ZWQgNnRvND8gVGhhdCBpcywgYW55b25lIGNvdWxkIHNldCB1 cCBhIGJhZGx5LW1haW50YWluZWQsIHVuZGVyLXByb3Zpc2lvbmVkIFRVUk4gc2VydmVyIGFuZCBh bm5vdW5jZSBpdCBvdmVyIEJHUCB0byB0aGUgd29ybGQsDQogYXMgaXQgd2FzIGRvbmUgZm9yPGJy Pg0KNnRvNCByZWxheXMuIE9yIGp1c3QgYmFkIEJHUCBvdXRib3VuZCBmaWx0ZXIgY29uZmlndXJh dGlvbi4gQW5kIGhvdyBjYW4gd2UgcHJldmVudCB0cmlhbmdsZSByb3V0aW5nPyBUaGVyZSBpcyBu b3RoaW5nIGd1YXJhbnRlZWluZyB0aGF0IHRoZSBhbnljYXN0IHNlcnZlciB5b3Ugc2VlIGlzIGJl aW5nIHByb3ZpZGVkIHRvIHlvdSBieSB5b3VyIElTUCwgcmF0aGVyIHRoYW4gYSBzZXJ2ZXIgc2l0 dGluZyBvbiB0aGUgb3RoZXIgc2lkZSBvZiB0aGUgcGxhbmV0Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+LS0tIEdvb2QgcG9pbnQgLSBuZWVkcyB0byBiZSByZXNvbHZlZC4g Rm9yIHRoaXMgSSBkb24ndCBoYXZlIGEgcmVhZHkgYW5zd2VyLi4uPGJyPg0KQW4gYXV0by1kaXNj b3ZlcmVkIFRVUk4gc2VydmVyIG11c3QgYmUgdHJ1c3RlZCAod2hhdGV2ZXIgbWV0aG9kIGl0IGlz IGRpc2NvdmVyZWQgYnkpLiBXZSBhcmUgdHJ1c3RpbmcgdGhlIG9uZSBwcm92aWRpbmcgdXMgd2l0 aCBhbiBJUCBhZGRyZXNzIGFuZCBkZWZhdWx0IGdhdGV3YXkgYW55d2F5LiBJdCB3b3VsZCBiZSBl YXN5IGlmIHdlIGNvdWxkIHJldXNlIHRoYXQgdHJ1c3QsIGluc3RlYWQgb2YgYW5vdGhlciBtZWNo YW5pc21zLjxicj4NCjxicj4NCklzIHRoZXJlIGEgZ29vZCB3YXkgZm9yIHRoZSBicm93c2VyIHRv IGNoZWNrIHRoYXQgdGhlIGFueWNhc3QgYWRkcmVzcyBpcyBub3QgaGFuZGxlZCBiZXlvbmQgdGhl IG5ldHdvcmsgc2VydmljZSBwcm92aWRlcidzIGRlZmF1bHQgZ2F0ZXdheT8gSWRlYXM/PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8YnI+DQpU aGFua3MsPGJyPg0KU2ltb248YnI+DQotLTxicj4NCkRUTiBtYWRlIGVhc3ksIGxlYW4sIGFuZCBz bWFydCAtLSZndDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Bvc3RlbGxhdGlvbi52aWFn ZW5pZS5jYS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+aHR0cDovL3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5jYTwvc3Bhbj48L2E+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCk5BVDY0L0ROUzY0IG9wZW4t c291cmNlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tJmd0OyZuYnNwOzwvc3Bhbj48YSBo cmVmPSJodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cDovL2VjZHlzaXMudmlhZ2VuaWUu Y2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+ DQpTVFVOL1RVUk4gc2VydmVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAtLSZndDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL251bWIudmlhZ2Vu aWUuY2EvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPmh0dHA6Ly9udW1iLnZpYWdlbmllLmNhPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48 YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPC9z cGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvc3Bhbj48L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90cmFtPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJh bUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RyYW08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A242AD903xmbrcdx10ciscoc_-- From tireddy@cisco.com Thu Feb 13 08:47:30 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876381A02CD for ; Thu, 13 Feb 2014 08:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Rbh22wU1bIHj for ; Thu, 13 Feb 2014 08:47:22 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id F366F1A0281 for ; Thu, 13 Feb 2014 08:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=155926; q=dns/txt; s=iport; t=1392310040; x=1393519640; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yf9P8qEoV7ne0ZkZgxHHZgdP2cjCTGM/SIZs1HJCOjY=; b=EkyOx6FOxRX0WUjLdjiJxW2Tq9AgB5yHRXeMCgCxFRZUgh2+tsh5w/hg Nt1Cbp5/51fKRilu89qEUazt7JS0HLVfz7RVUcKXaa+iB32EQijR4dYF/ /J2sC4a61sXd02B9EjXdNqGj/10J6Fx7amDP9WSaIIiorFwNRxQLUEDoO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4IAA72/FKtJV2Y/2dsb2JhbABPCoJCRDhXgwCndYwDiFQYgQAWdIIlAQEBAwEBAQEXAQgEBjoFAgQEAwULAgEIEQQBAQsWAQIEAwICAh8GCxQJCAEBBA4FCBOHVgMJCA2lapleDYg8F4xfgS4QDh0WFwQGAQmCZjWBFASFWI5rgX2DHosshUWBb4E+gXE5 X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="scan'208,217";a="303832571" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 13 Feb 2014 16:47:18 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1DGlIRe028555 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 16:47:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 10:47:17 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Karl Stahl Thread-Topic: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: Ac8obNsCBHZfUz6PQqmEmyo5gqkf2AAIL2iQABMqz8A= Date: Thu, 13 Feb 2014 16:47:16 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242AD996@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> <006701cf28af$9c2a27f0$d47e77d0$@stahl@intertex.se> In-Reply-To: <006701cf28af$9c2a27f0$d47e77d0$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.62.22] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242AD996xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "tram@ietf.org" Subject: Re: [tram] IMPORTANT CLARIFICATIONS: Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:47:30 -0000 --_000_913383AAA69FF945B8F946018B75898A242AD996xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2FybCwNCg0KSSBkaWQgbm90IHVuZGVyc3RhbmQgaG93IFRVUk4gc2VydmVyIHdpbGwgaWRl bnRpZnkgaWYgaXTigJlzIFdlYlJUQyBtZWRpYSBzdHJlYW1zIG9yIGdhbWluZyB0cmFmZmljIG9y IHNvbWUgb3RoZXIgZGF0YSB0cmFmZmljIHJlbGF5ZWQgdGhyb3VnaCBpdCB0byBzZXQgdGhlIGRp ZmZzZXJ2IGJpdHMgY29ycmVjdGx5ICENCg0KLVRpcnUuDQpGcm9tOiBLYXJsIFN0YWhsIFttYWls dG86a2FybC5zdGFobEBpbnRlcnRleC5zZV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMywg MjAxNCA1OjA1IFBNDQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgJ0h1dHRvbiwg QW5kcmV3JzsgJ0p1c3RpbiBVYmVydGknOyBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1 bWFsKQ0KQ2M6IHRpcmVkZHlAaWNpc2NvLmNvbTsgJ1NpbW9uIFBlcnJlYXVsdCc7ICdPbGVnIE1v c2thbGVua28nOyB0cmFtQGlldGYub3JnOyAnTWFyYyBCbGFuY2hldCc7IERhbiBXaW5nIChkd2lu ZykNClN1YmplY3Q6IElNUE9SVEFOVCBDTEFSSUZJQ0FUSU9OUzogW3RyYW1dIE1pbGVzdG9uZSAz OiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5k IElTUHMNCg0KT24gdGhlIHNpZGUgb2YgdGhpcyBUUkFNLWxpc3QsIEkgYWxzbyBnb3QgdGhpcyBx dWVzdGlvbjoNCj4gUmVnYXJkaW5nIHRoZSBlbnRlcnByaXNlIGNhc2UsIEkgYW0gbm90IHN1cmUg SSBmb2xsb3cgeW91ciBhcmd1bWVudC4NCj4gRG8geW91IG1lYW4gdGhhdCBieSBzZXR0aW5nIHVw IGFuIGVudGVycHJpc2UgVFVSTiBzZXJ2ZXIsIGFuZCBvcGVuIHRoZSBmaXJld2FsbCBmb3IgbWVk aWEgb3ZlciBVRFAgZnJvbS90byBUVVJOIHNlcnZlciBiZSB0aGUgc29sdXRpb24/DQotLS0tIEFz IHdlIGFsbCByZWFsaXplLCB0aGF0IHdvdWxkIG9mIGNvdXJzZSBub3QgaGVscCBvciBpbXByb3Zl IHRoaW5ncw0KDQpUaGUgaW50ZW5kZWQgc29sdXRpb24gaW4gdGhlIGVudGVycHJpc2UgY2FzZSBo YXMgbm90IHlldCBiZWVuIHNwZWxsZWQgb3V0IGluIHRoaXMgVFJBTS1saXN0IGRpc2N1c3Npb24s IHNvIGZvciBiZXR0ZXIgdW5kZXJzdGFuZGluZywgbGV0IG1lIGNvcHkgYSBmZXcgdGhpbmdzIGZy b20gdGhlIGRpc2N1c3Npb24gaW4gU2VwdGVtYmVyL09jdG9iZXIgb24gdGhlIFJUQ1dFQi1saXN0 IGFuZCB3aGF0IGlzIChzaW5jZSBsb25nKSBzcGVsbGVkIG91dCBpbiB0aGUgZHJhZnQtaWV0Zi1y dGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMuDQoNCkZvciBiZXR0ZXIgdW5kZXJzdGFu ZGluZywgSSBhbHNvIHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgYSBUVVJOIGNhbiBoYXZlIHR3byBp bnRlcmZhY2VzIChhY3RpbmcgbGlrZSBhIHJvdXRlciBmb3IgbWVkaWEgYmV0d2VlbiBkaWZmZXJl bnQgbmV0d29ya3MpLiBUaGlzIGFsbG93cyB0byBlYXNpZXIgdW5kZXJzdGFuZCB0aGF0IGNhbiBU VVJOIHNlcnZlcnMgY2FuIGRpcmVjdCBhIGJlc3QgbWVkaWEgcGF0aCAocmF0aGVyIHRoYW4ganVz dCB0aGlua2luZyB0aGF0IGEgVFVSTiBzZXJ2aWNlIGlzIGEgZGV2aWNlIHdoaWNoIG1lZGlhIGp1 c3QgYm91bmNlcyBhZ2FpbnN0IGF0IG9uZSBpbnRlcmZhY2UpLg0KDQpBbmQsIHdlIGNhbiBhbHNv IGhvcGUgZm9yIHRoYXQgYSBUVVJOIHNlcnZlciBiZWNvbWVzIGEgKGNvbW1vbikgY29tcG9uZW50 IG9mIGEgZmlyZXdhbGwsIHdoaWNoIHdvdWxkIGFsbG93IHRoZSBmaXJld2FsbCB0byB1bmRlcnN0 YW5kIHRoYXQgdGhlIG1lZGlhIGRpcmVjdGVkIHRvIGl0IGlzIFJUQyBhbmQgc2hvdWxkIGJlIHBy aW9yaXRpemVkIHdoZXJlYnkgdGhlIGZpcmV3YWxsIGNhbiB0cmFmZmljIHNoYXBlZCAoYmFjay1v ZmYgZGF0YSB0cmFmZmljIHRoYXQgbWF5IGJlIGZpbGxpbmcgaXRzIEludGVybmV0IHBpcGUpIGFz IHdlbGwgYXMgZS5nLiBzZXQgZGlmZnNlcnZlIGJpdHMgb3IgdGFrZSBvdGhlciBtZWFzdXJlcyB0 byBhc3Npc3QgcHJvcGVyIHF1YWxpdHkgaGFuZGxpbmcgdGhvdWdodCB0aGUgbmV0d29yay4gKFRo ZXNlIGFyZSBjb21tb24gbWVjaGFuaXNtcyBhdmFpbGFibGUgYW5kIHVzZWQgaW4gZmlyZXdhbGxz L05BVHMvYWNjZXNzIHJvdXRlcnMsIGJ1dCBUVVJOIHNlcnZlcnMgYXJlIG5vdCB5ZXQgaW5jbHVk ZWQgc3VjaCBkZXZpY2VzLikgVGhlIHNhbWUgZ29lcyBmb3IgYWNjZXNzIHJvdXRlcnMvZGVmYXVs dCBnYXRld2F5cywgRFBJcyBpbiB0aGUgdHJhbnNwb3J0IG5ldHdvcmsgaXRzZWxmIOKAkyBUVVJO IHNlcnZlcnMgaW5jbHVkZWQgaW4gc3VjaCBwb2ludHMgd2VyZSBtZWRpYSBjYW4gcGFzcyBhbmQg cXVhbGl0eSBtZWFzdXJlcyBhcHBsaWVkIG1heS93aWxsIGJlIHZlcnkgdXNlZnVsIHRvIGdldCB1 cyBXZWJSVEMgbWVkaWEgd2l0aCB0aHJvdWdoIG5ldHdvcmtzIHdpdGhvdXQgcXVhbGl0eSBkZXN0 cnVjdGlvbi4NCg0KRnJvbSB0aGUgUlRDV0VCIG1haWxpbmcgbGlzdCBTZXB0ZW1iZXIgMjB0aCAo YnkgbWUpOg0KDQpBbiBlbnRlcnByaXNlIG5ldHdvcmsgdGhhdCB3YW50IHRvIGtlZXAgYSByZXN0 cmljdGl2ZSBmaXJld2FsbCBub3QgYWxsb3dpbmcgVURQIHRyYWZmaWMsIGNvdWxkIHByb3ZpZGUg YSByZWFsLXRpbWUgcGF0aCB1c2luZyBhIFRVUk4gc2VydmVyIHBhcmFsbGVsaW5nIHRoZSBmaXJl d2FsbCwgaW5zdGVhZCBvZiB0dW5uZWxpbmcgUlRQIHRocm91Z2ggYWx3YXlzIG9wZW4gaHR0cCBv ciBodHRwcyBwb3J0cyByZXN1bHRpbmcgaW4gUlRQIG1lZGlhIG92ZXIgVENQIOKAkyB3aXRoIHNl dmVyZSBxdWFsaXR5IHByb2JsZW1zIGZyb20gVENQIHJldHJhbnNtaXNzaW9ucyBvZiBkcm9wcGVk IHBhY2tldHMuIFRoZSBUVVJOIHNlcnZlciBhZGRyZXNzIGlzIG1vc3QgZWFzaWx5IHByb3ZpZGVk IGluIHRoZSBzYW1lIHdheSBhcyB0aGUgSVAgYWRkcmVzcyBhbmQgRE5TIGFkZHJlc3MuIChUaGF0 IHdvdWxkIGFsc28gcHV0IHRoZSByaWdodCBwYXJ0eSBpbiBjb250cm9sIOKAkyBUaGUgbmV0d29y ayBwcm92aWRlciAoaGVyZSB0aGUgZW50ZXJwcmlzZSkgZGVjaWRlcyB3aGF0IGlzIGFsbG93ZWQg b24gaGlzIG5ldHdvcmsuKQ0KDQoNCg0KVGhlIGJyb3dzZXIgc2hvdWxkIHNlbGVjdCB3aGljaCBh dmFpbGFibGUgVFVSTiBzZXJ2ZXIgYWRkcmVzcyB0byB1c2UgaW4gdGhlIGZvbGxvd2luZyBwcmlv cml0eSBvcmRlciwgd2hlcmUgSUNFIGNvdWxkIGJlIHVzZWQgdG8gdHJ5IHNldmVyYWw6DQoNCg0K DQoxKSBUVVJOIHNlcnZlciBhZGRyZXNzIGNvbmZpZ3VyZWQgaW4gdGhlIGJyb3dzZXIgYnkgdGhl IHVzZXIgKHNwZWNpYWwgY2FzZXMsIG5vcm1hbGx5IG5vdCB1c2VkKQ0KDQoyKSBUVVJOIHNlcnZl ciBhZGRyZXNzIGNvbmZpZ3VyZWQgYnkgdGhlIG5ldHdvcmsgYWRtaW5pc3RyYXRvciB2aWEgYW4g 4oCcYWRtaW4gcG9saWN5IHRlbXBsYXRl4oCdDQoNCjMpIFRVUk4gc2VydmVyIGFkZHJlc3Mgc3Vw cGxpZWQgYnkgREhDUCBvciBzaW1pbGFyIGF1dG9tYXRpYyBuZXR3b3JrIG1ldGhvZA0KDQo0KSBU VVJOIHNlcnZlciBhZGRyZXNzIGJlaW5nIHN1cHBsaWVkIGJ5IHRoZSB3ZWIgYXBwbGljYXRpb24i DQoNCg0KQW5kIGZyb20geWVzdGVyZGF5cyghKSBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xNCB0aGVzZSBlbnRl cnByaXNlIHRoaW5ncyBhbmQgbmVjZXNzaXR5IGFyZSBzcGVsbGVkIG91dCBpbjoNCg0KRjE5ICAg ICBUaGUgYnJvd3NlciBtdXN0IGJlIGFibGUgdG8gdXNlIHNldmVyYWwgU1RVTiBhbmQgVFVSTiBz ZXJ2ZXJzDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQoNCkEyMg0KMy4zLjU8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlv bi0zLjMuNT4uICBTaW1wbGUgVmlkZW8gQ29tbXVuaWNhdGlvbiBTZXJ2aWNlLCBlbnRlcnByaXNl IGFzcGVjdHMNCjMuMy41LjE8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1y dGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNS4xPi4gIERl c2NyaXB0aW9uDQogICBUaGlzIHVzZS1jYXNlIGlzIHNpbWlsYXIgdG8gdGhlIFNpbXBsZSBWaWRl byBDb21tdW5pY2F0aW9uIFNlcnZpY2UNCiAgIHVzZS1jYXNlIChTZWN0aW9uIDMuMy4xPGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVx dWlyZW1lbnRzLTE0I3NlY3Rpb24tMy4zLjE+KS4NCg0KICAgV2hhdCBpcyBhZGRlZCBpcyBhc3Bl Y3RzIHdoZW4gdXNpbmcgdGhlIHNlcnZpY2UgaW4gZW50ZXJwcmlzZXMuICBJQ0UNCiAgIGlzIGFz c3VtZWQgaW4gdGhlIGZ1cnRoZXIgZGVzY3JpcHRpb24gb2YgdGhpcyB1c2UtY2FzZS4NCg0KICAg QW4gZW50ZXJwcmlzZSB0aGF0IHVzZXMgYSBSVENXRUIgYmFzZWQgd2ViIGFwcGxpY2F0aW9uIGZv cg0KICAgY29tbXVuaWNhdGlvbiBkZXNpcmVzIHRvIGF1ZGl0IGFsbCBSVENXRUIgYmFzZWQgYXBw bGljYXRpb24gc2Vzc2lvbnMNCiAgIHVzZWQgZnJvbSBpbnNpZGUgdGhlIGNvbXBhbnkgdG93YXJk cyBhbnkgZXh0ZXJuYWwgcGVlci4gIFRvIGJlIGFibGUNCiAgIHRvIGRvIHRoaXMgdGhleSBkZXBs b3kgYSBUVVJOIHNlcnZlciB0aGF0IHN0cmFkZGxlcyB0aGUgYm91bmRhcnkNCiAgIGJldHdlZW4g dGhlIGludGVybmFsIGFuZCB0aGUgZXh0ZXJuYWwgbmV0d29yay4NCg0KICAgVGhlIGZpcmV3YWxs IHdpbGwgYmxvY2sgYWxsIGF0dGVtcHRzIHRvIHVzZSBTVFVOIHdpdGggYW4gZXh0ZXJuYWwNCiAg IGRlc3RpbmF0aW9uIHVubGVzcyB0aGV5IGdvIHRvIHRoZSBlbnRlcnByaXNlIGF1ZGl0aW5nIFRV Uk4gc2VydmVyLg0KICAgSW4gY2FzZXMgd2hlcmUgZW1wbG95ZWVzIGFyZSB1c2luZyBSVENXRUIg YXBwbGljYXRpb25zIHByb3ZpZGVkIGJ5IGFuDQogICBleHRlcm5hbCBzZXJ2aWNlIHByb3ZpZGVy IHRoZXkgc3RpbGwgd2FudCB0aGUgdHJhZmZpYyB0byBzdGF5IGluc2lkZQ0KICAgdGhlaXIgaW50 ZXJuYWwgbmV0d29yayBhbmQgaW4gYWRkaXRpb24gbm90IGxvYWQgdGhlIHN0cmFkZGxpbmcgVFVS Tg0KICAgc2VydmVyLCB0aHVzIHRoZXkgZGVwbG95IGEgU1RVTiBzZXJ2ZXIgYWxsb3dpbmcgdGhl IFJUQ1dFQiBjbGllbnQgdG8NCiAgIGRldGVybWluZSBpdHMgc2VydmVyIHJlZmxleGl2ZSBhZGRy ZXNzIG9uIHRoZSBpbnRlcm5hbCBzaWRlLiAgVGh1cw0KICAgZW5hYmxpbmcgY2FzZXMgd2hlcmUg cGVlcnMgYXJlIGJvdGggb24gdGhlIGludGVybmFsIHNpZGUgdG8gY29ubmVjdA0KICAgd2l0aG91 dCB0aGUgdHJhZmZpYyBsZWF2aW5nIHRoZSBpbnRlcm5hbCBuZXR3b3JrLiAgSXQgbXVzdCBiZQ0K ICAgcG9zc2libGUgdG8gY29uZmlndXJlIHRoZSBicm93c2VycyB1c2VkIGluIHRoZSBlbnRlcnBy aXNlIHdpdGgNCiAgIG5ldHdvcmsgc3BlY2lmaWMgU1RVTiBhbmQgVFVSTiBzZXJ2ZXJzLiAgVGhp cyBzaG91bGQgYmUgcG9zc2libGUgdG8NCiAgYWNoaWV2ZSBieSBhdXRvLWNvbmZpZ3VyYXRpb24g bWV0aG9kcy4gIFRoZSBSVENXRUIgZnVuY3Rpb25hbGl0eSB3aWxsDQogICBuZWVkIHRvIHV0aWxp emUgYm90aCBuZXR3b3JrIHNwZWNpZmljIFNUVU4gYW5kIFRVUk4gcmVzb3VyY2VzIGFuZA0KICAg U1RVTiBhbmQgVFVSTiBzZXJ2ZXJzIHByb3Zpc2lvbmVkIGJ5IHRoZSB3ZWIgYXBwbGljYXRpb24u DQozLjMuNS4yPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVz ZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0I3NlY3Rpb24tMy4zLjUuMj4uICBBZGRpdGlvbmFs IFJlcXVpcmVtZW50cw0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgUkVRLUlEICAgICAgREVTQ1JJUFRJT04NCiAg IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCiAgIEYyMCAgICAgVGhlIGJyb3dzZXIgbXVzdCBzdXBwb3J0IHRoZSB1c2Ugb2Yg U1RVTiBhbmQgVFVSTg0KICAgICAgICAgICBzZXJ2ZXJzIHRoYXQgYXJlIHN1cHBsaWVkIGJ5IGVu dGl0aWVzIG90aGVyIHRoYW4NCiAgICAgICAgICAgdGhlIHdlYiBhcHBsaWNhdGlvbiAoaS5lLiB0 aGUgbmV0d29yayBwcm92aWRlcikuDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoZXJlIGFyZSBmdXJ0aGVyIHJl cXVpcmVtZW50IGxpc3RlZCwgaGVscGluZyB1cyB0byB1bmRlcnN0YW5kIHRoZSBuZWVkIGZvciBh dXRvIGRpc2NvdmVyeSBhbmQgYSBuZXR3b3JrIHByb3ZpZGVkIFRVUk4tc2VydmVyIHNob3VsZCBi ZSB1c2VkIHRvIEVORk9SQ0UgdGhhdCBtZWRpYSB0YWtlcyB0aGF0IHBhdGggKGFuZCB0aHVzLCBv dGhlciBwYXRocyBlLmcuIHN1Z2dlc3RlZCBieSB0aGUgcmVtb3RlIE1VU1Qgbm90IGhhcHBlbiB0 byBiZSB1c2VkKS4gVGhpcyBpcyByZWxhdGVkIHRvIHRoZSBtb2JpbGl0eSBhc3BlY3QgKHZhbGlk IGV2ZW4gd2l0aG91dCB0aGUgcm9hbWluZyBpZGVhKToNCjMuMy42PGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0 I3NlY3Rpb24tMy4zLjY+LiAgU2ltcGxlIFZpZGVvIENvbW11bmljYXRpb24gU2VydmljZSwgYWNj ZXNzIGNoYW5nZQ0KMy4zLjYuMTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xNCNzZWN0aW9uLTMuMy42LjE+LiAg RGVzY3JpcHRpb24NCg0KICAgVGhpcyB1c2UtY2FzZSBpcyBhbG1vc3QgaWRlbnRpY2FsIHRvIHRo ZQ0KDQogICBTaW1wbGUgVmlkZW8gQ29tbXVuaWNhdGlvbiBTZXJ2aWNlIHVzZS1jYXNlIChTZWN0 aW9uIDMuMy4xPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVz ZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0I3NlY3Rpb24tMy4zLjE+KS4gIFRoZQ0KDQogICBk aWZmZXJlbmNlIGlzIHRoYXQgdGhlIHVzZXIgY2hhbmdlcyBuZXR3b3JrIGFjY2VzcyBkdXJpbmcg dGhlDQoNCiAgIHNlc3Npb24uDQoNCg0KDQogICBUaGUgY29tbXVuaWNhdGlvbiBkZXZpY2UgdXNl ZCBieSBvbmUgb2YgdGhlIHVzZXJzIGhhcyBzZXZlcmFsIG5ldHdvcmsNCg0KICAgYWRhcHRlcnMg KEV0aGVybmV0LCBXaUZpLCBDZWxsdWxhcikuICBUaGUgY29tbXVuaWNhdGlvbiBkZXZpY2UgaXMN Cg0KICAgYWNjZXNzaW5nIHRoZSBJbnRlcm5ldCB1c2luZyBFdGhlcm5ldCwgYnV0IHRoZSB1c2Vy IGhhcyB0byBzdGFydCBhDQoNCiAgIHRyaXAgZHVyaW5nIHRoZSBzZXNzaW9uLiAgVGhlIGNvbW11 bmljYXRpb24gZGV2aWNlIGF1dG9tYXRpY2FsbHkNCg0KICAgY2hhbmdlcyB0byB1c2UgV2lGaSB3 aGVuIHRoZSBFdGhlcm5ldCBjYWJsZSBpcyByZW1vdmVkIGFuZCB0aGVuIG1vdmVzDQoNCiAgIHRv IGNlbGx1bGFyIGFjY2VzcyB0byB0aGUgSW50ZXJuZXQgd2hlbiBtb3Zpbmcgb3V0IG9mIFdpRmkg Y292ZXJhZ2UuDQoNCiAgIFRoZSBzZXNzaW9uIGNvbnRpbnVlcyBldmVuIHRob3VnaCB0aGUgYWNj ZXNzIG1ldGhvZCBjaGFuZ2VzLg0KDQozLjMuNi4yPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0I3NlY3Rpb24t My4zLjYuMj4uICBBZGRpdGlvbmFsIFJlcXVpcmVtZW50cw0KDQogICAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCiAgIFJF US1JRCAgICAgIERFU0NSSVBUSU9ODQoNCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgRjE3ICAgICBUaGUgY29t bXVuaWNhdGlvbiBzZXNzaW9uIG11c3Qgc3Vydml2ZSBhY3Jvc3MgYQ0KDQogICAgICAgICAgIGNo YW5nZSBvZiB0aGUgbmV0d29yayBpbnRlcmZhY2UgdXNlZCBieSB0aGUNCg0KICAgICAgICAgICBz ZXNzaW9uDQoNCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KMy4zLjc8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0z LjMuNz4uICBTaW1wbGUgVmlkZW8gQ29tbXVuaWNhdGlvbiBTZXJ2aWNlLCBRb1MNCjMuMy43LjE8 aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFu ZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNy4xPi4gIERlc2NyaXB0aW9uDQoNCiAgIFRo aXMgdXNlLWNhc2UgaXMgYWxtb3N0IGlkZW50aWNhbCB0byB0aGUNCg0KICAgU2ltcGxlIFZpZGVv IENvbW11bmljYXRpb24gU2VydmljZSwgYWNjZXNzIGNoYW5nZSB1c2UtY2FzZQ0KDQogICAoU2Vj dGlvbiAzLjMuNjxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi11 c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xNCNzZWN0aW9uLTMuMy42PikuICBUaGUgdXNlIG9m IFF1YWxpdHkgb2YgU2VydmljZSAoUW9TKSBjYXBhYmlsaXRpZXMgaXMNCg0KICAgYWRkZWQ6DQoN Cg0KDQogICBUaGUgdXNlciBpbiB0aGUgcHJldmlvdXMgdXNlIGNhc2UgdGhhdCBzdGFydHMgYSB0 cmlwIGlzIGJlaGluZCBhDQoNCiAgIGNvbW1vbiByZXNpZGVudGlhbCByb3V0ZXIgdGhhdCBzdXBw b3J0cyBwcmlvcml0aXphdGlvbiBvZiB0cmFmZmljLg0KDQogICBJbiBhZGRpdGlvbiwgdGhlIHVz ZXIncyBwcm92aWRlciBvZiBjZWxsdWxhciBhY2Nlc3MgaGFzIFFvUyBzdXBwb3J0DQoNCiAgIGVu YWJsZWQuICBUaGUgdXNlciBpcyBhYmxlIHRvIHRha2UgYWR2YW50YWdlIG9mIHRoZSBRb1Mgc3Vw cG9ydCBib3RoDQoNCiAgIHdoZW4gYWNjZXNzaW5nIHZpYSB0aGUgcmVzaWRlbnRpYWwgcm91dGVy IGFuZCB3aGVuIHVzaW5nIGNlbGx1bGFyLg0KDQozLjMuNy4yPGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0I3Nl Y3Rpb24tMy4zLjcuMj4uICBBZGRpdGlvbmFsIFJlcXVpcmVtZW50cw0KDQogICAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN CiAgIFJFUS1JRCAgICAgIERFU0NSSVBUSU9ODQoNCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgRjE3ICAgICBU aGUgY29tbXVuaWNhdGlvbiBzZXNzaW9uIG11c3Qgc3Vydml2ZSBhY3Jvc3MgYQ0KDQogICAgICAg ICAgIGNoYW5nZSBvZiB0aGUgbmV0d29yayBpbnRlcmZhY2UgdXNlZCBieSB0aGUNCg0KICAgICAg ICAgICBzZXNzaW9uDQoNCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgRjIyICAgICBUaGUgYnJvd3NlciBtdXN0 IGJlIGFibGUgdG8gcmVjZWl2ZSBzdHJlYW1zIGFuZA0KDQogICAgICAgICAgIGRhdGEgZnJvbSBt dWx0aXBsZSBwZWVycyBjb25jdXJyZW50bHkuDQoNCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KRnVydGhlciBmcm9t IHRoZSBSVENXRUIgbWFpbGluZyBsaXN0IFNlcHRlbWJlciAyMHRoIChieSBtZSk6DQoNCg0KVGhl cmUgYXJlIHNldmVyYWwgcmVhc29ucyBmb3IgYSBuZXR3b3JrIHNlcnZpY2UgcHJvdmlkZXIgdG8g c3VwcGx5IGEgVFVSTiBzZXJ2ZXIgYXMgcGFydCBvZiBoaXMgb2ZmZXJlZCBhY2Nlc3M6DQoNCi0g dG8ga2VlcCBtZWRpYSBwYXRocyBzaG9ydCwgc3BlY2lmaWNhbGx5IG5vdCBzZW5kaW5nIG1lZGlh IG91dHNpZGUgaXRzIG93biBuZXR3b3JrIHRvIHNvbWUgZGlzdGFudCBhcHBsaWNhdGlvbiBwcm92 aWRlZCBUVVJOIHNlcnZlcg0KDQotIHRvIHN1cHBvcnQgbW9iaWxpdHksIGkuZS4geW91IG1heSB3 YW50IHRvIG1vdmUgZnJvbSBhIExBTiB3aXRoIGEgY29uZmlndXJlZCBUVVJOIHNlcnZlciB0byBh Y2Nlc3NpbmcgdmlhIFdpRmkgb3IgM0cvNEcgT1RUIGNoYW5uZWxzDQoNCi0gdG8gb2ZmZXIgYSBt ZWRpYSBwYXRoIHdpdGggYmV0dGVyIHF1YWxpdHkgKHRoYW4gYmVzdCBlZmZvcnQgZGF0YSB0cmFm ZmljKS4NCg0KR2V0dGluZyDigJxXZWJSVEMtcmVhZHnigJ0gYWNjZXNzIGFuZCB3ZSBsb29rIGZv cndhcmQgdG8gdGVsZXByZXNlbmNlIGZvciBldmVyeW9uZS4NCg0KDQpJIGhvcGUgdGhpcyAoYSBi aXQgbGVuZ3RoeSkgc3VtbWFyeSBvZiBhbHJlYWR5IHRob3VnaHQtb3V0IGFuZCBkaXNjdXNzZWQg YXNwZWN0cy9yZXF1aXJlbWVudHMgd2lsbCBoZWxwIHVzIHVuZGVyc3RhbmQgdGhhdCB0aGUgYXV0 by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVyIGlzIGFuIE9SREVSIGZyb20gdGhlIGVudGVycHJpc2Ug YW5kL29yIHRoZSBOU1AvSVNQICB0byBzZW5kIHRoZSBtZWRpYSB0aHJvdWdoIHRoaXMgVFVSTiBw YXRoLCBhbmQgdGhhdCBvdGhlciBtZWRpYSBwYXRocyB0aGF0IG1heSBleGlzdCBNVVNUIE5PVCBC RSBVU0VELiAoVGhhdCBpcyB3aHkgd2UgZXNwZWNpYWxseSBoYXZlIHRvIHdhdGNoL2FkdmljZSB0 aGF0IHdvcmthYmxlIG1lZGlhIHBhdGhzIHByb3Bvc2VkIGJ5IHRoZSByZW1vdGUgcGFydHkgbm90 IGJlY29tZXMgdXNlZCDigJxieSBhY2NpZGVudOKAnS4NCg0KL0thcmwNCg0KDQpGcsOlbjogVGly dW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSBbbWFpbHRvOnRpcmVkZHlAY2lzY28uY29tXQ0KU2tp Y2thdDogZGVuIDEzIGZlYnJ1YXJpIDIwMTQgMDQ6MzcNClRpbGw6IEh1dHRvbiwgQW5kcmV3OyBK dXN0aW4gVWJlcnRpOyBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KS29waWE6 IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tPjsgU2ltb24gUGVy cmVhdWx0OyBPbGVnIE1vc2thbGVua287IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5v cmc+OyBNYXJjIEJsYW5jaGV0OyBEYW4gV2luZyAoZHdpbmcpOyBLYXJsIFN0YWhsDQrDhG1uZTog UkU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFu aXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNCkhpIEFuZHksDQoNClRoZXJlIGFyZSBvdGhl ciB3YXlzIHRvIHNvbHZlIHRoZSBwcm9ibGVtIGZvciBleGFtcGxlIHVzaW5nIFBDUC4gQ2FuIHlv dSBjbGFyaWZ5IGhvdyBkZXBsb3lpbmcgYSBUVVJOIHNlcnZlciBpbiB0aGUgRW50ZXJwcmlzZSBw cm90ZWN0cyB0aGUgdXNlcnMgYW5kIHRoZSBuZXR3b3JrID8NCg0KLVRpcnUuDQpGcm9tOiB0cmFt IFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSHV0dG9uLCBBbmRy ZXcNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCAxOjAwIEFNDQpUbzogSnVzdGlu IFViZXJ0aTsgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkNCkNjOiB0aXJlZGR5 QGljaXNjby5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT47IFNpbW9uIFBlcnJlYXVsdDsg T2xlZyBNb3NrYWxlbmtvOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPjsgTWFy YyBCbGFuY2hldDsgRGFuIFdpbmcgKGR3aW5nKTsgS2FybCBTdGFobA0KU3ViamVjdDogUmU6IFt0 cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZv ciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNClRoZSBjYXNlIHdoZXJlIHRoZSBUVVJOIHNlcnZlciBp cyB0aGUgb25seSBvcHRpb24gbWF5IGJlY29tZSBjb21tb24gd2l0aGluIGVudGVycHJpc2UgbmV0 d29ya3MgYW5kIHRoYXQgbWlnaHQgYmUgZGVsaWJlcmF0ZSBlbnRlcnByaXNlIHBvbGljeSBiZWNh dXNlIGl0IHByb3ZpZGVzIHRoZSBiZXR0ZXIgcGF0aCAoVURQIHRocm91Z2ggdGhlIEYvVykgYW5k IHByb3RlY3RzIHRoZSB1c2VycyBhbmQgdGhlIG5ldHdvcmsuDQoNCkFuZHkNCg0KDQpGcm9tOiB0 cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSnVzdGluIFVi ZXJ0aQ0KU2VudDogMTIgRmVicnVhcnkgMjAxNCAxNzo0Ng0KVG86IE11dGh1IEFydWwgTW96aGkg UGVydW1hbCAobXBlcnVtYWwpDQpDYzogdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5 QGljaXNjby5jb20+OyBTaW1vbiBQZXJyZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsgdHJhbUBpZXRm Lm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IE1hcmMgQmxhbmNoZXQ7IERhbiBXaW5nIChkd2lu Zyk7IEthcmwgU3RhaGwNClN1YmplY3Q6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2Vy dmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpB Z3JlZS4gSWYgVFVSTiBpcyBpbmRlZWQgYmVpbmcgcHJvdmlkZWQgZm9yIHRoZSB1c2VyJ3MgYmVu ZWZpdCwgdGhlIGNsaWVudCdzIElDRSBsb2dpYyAoYmFzZWQgb24gUlRUIG9yIHNpbWlsYXIpIHNo b3VsZCByZXN1bHQgaW4gaXQgcHJlZmVycmluZyB0aGUgVFVSTiBwYXRoLg0KDQpPbiBXZWQsIEZl YiAxMiwgMjAxNCBhdCAxOjI3IEFNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFs KSA8bXBlcnVtYWxAY2lzY28uY29tPG1haWx0bzptcGVydW1hbEBjaXNjby5jb20+PiB3cm90ZToN ClllcywgSSBiZWxpZXZlIHRoZSBzZWNvbmQgY2FzZSBpcyByYXJlLCBidXQgd291bGQgYmUgYmV0 dGVyIHRoYW4gYSByYXQgcmFjZSBiL3cgYWRtaW5pc3RyYXRvcnMgdHJ5aW5nIHRvIGJsb2NrIHAy cCB0cmFmZmljIGFuZCBmb3JjZSBpdCB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgYW5kIGFwcHMvZW5k cG9pbnRzIGZpbmRpbmcgc21hcnRlciB3YXlzIHRvIGJ5cGFzcyB0aGVtLg0KDQpNdXRodQ0KDQpG cm9tOiBPbGVnIE1vc2thbGVua28gW21haWx0bzptb20wNDAyNjdAZ21haWwuY29tPG1haWx0bzpt b20wNDAyNjdAZ21haWwuY29tPl0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQg MTowNyBQTQ0KVG86IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpDQpDYzogSnVz dGluIFViZXJ0aTsgS2FybCBTdGFobDsgdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5 QGljaXNjby5jb20+OyBNYXJjIEJsYW5jaGV0OyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGll dGYub3JnPjsgRGFuIFdpbmcgKGR3aW5nKTsgU2ltb24gUGVycmVhdWx0DQoNClN1YmplY3Q6IFJl OiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlz bSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpUaGUgVFVSTiBzZXJ2ZXIgaGFzIHRvIGJlIHVz ZWQgd2hlbiBpdCBpcyBlaXRoZXIgdGhlIG9ubHkgb3B0aW9uLCBvciBpZiBpdCBwcm92aWRlcyBh IGJldHRlciBwYXRoIChJIGd1ZXNzIHRoZSBzZWNvbmQgY2FzZSBpcyByYXRoZXIgcmFyZSkuDQoN Ck9uIFR1ZSwgRmViIDExLCAyMDE0IGF0IDExOjMyIFBNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVt YWwgKG1wZXJ1bWFsKSA8bXBlcnVtYWxAY2lzY28uY29tPG1haWx0bzptcGVydW1hbEBjaXNjby5j b20+PiB3cm90ZToNCisxDQoNCkZvcmNpbmcgYWxsIHRyYWZmaWMgdGhyb3VnaCBhIFRVUk4gc2Vy dmVyIGFuZCBleHBlY3RpbmcgaXQgd291bGQgcHJvdmlkZSB0aGUgYmVzdCB1c2VyIGV4cGVyaWVu Y2UgZG9lc24ndCBsb29rIHRoZSByaWdodCBhcHByb2FjaC4gSW5zdGVhZCwgaWYgYSBwYXRoIHRo cm91Z2ggYSBUVVJOIHNlcnZlciBleGlzdHMgYW5kIGRvZXMgcHJvdmlkZSBsb3dlciBSVFQsIGpp dHRlciBldGMsIGJlaW5nIGFibGUgdG8gZGV0ZWN0IGFuZCB1c2UgKG9yIHN3aXRjaCB0bykgdGhh dCBwYXRoIG1pZ2h0IGJlIGRlc2lyYWJsZS4uDQoNCk11dGh1DQoNCkZyb206IHRyYW0gW21haWx0 bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZz5dIE9u IEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAy MDE0IDExOjQzIEFNDQpUbzogS2FybCBTdGFobA0KQ2M6IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWls dG86dGlyZWRkeUBpY2lzY28uY29tPjsgTWFyYyBCbGFuY2hldDsgdHJhbUBpZXRmLm9yZzxtYWls dG86dHJhbUBpZXRmLm9yZz47IERhbiBXaW5nIChkd2luZyk7IFNpbW9uIFBlcnJlYXVsdA0KU3Vi amVjdDogUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3Zlcnkg bWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNCklubGluZS4NCg0KT24gVHVlLCBG ZWIgMTEsIDIwMTQgYXQgMjozNyBQTSwgS2FybCBTdGFobCA8a2FybC5zdGFobEBpbnRlcnRleC5z ZTxtYWlsdG86a2FybC5zdGFobEBpbnRlcnRleC5zZT4+IHdyb3RlOg0KTGlzdGVuaW5nIHRvIHRo aXMgdGhyZWFkLCBJIGFtIGFmcmFpZCB3ZSBhcmUgbWlzc2luZyB0aGUgdmVyeSBwb2ludCBhbmQg bmVjZXNzaXR5IGZvciB0aGlzIG1pbGVzdG9uZSENCi0gVGhlcmUgYXJlIHNldmVyZSBOQVQgdHJh dmVyc2FsIGFuZCBxdWFsaXR5IGlzc3VlcyB0aGF0IHNob3VsZCBhbmQgY2FuIGJlIGRlYWx0IHdp dGggYnkgYSBnb29kIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBhbmQgdGhlIHJpZ2h0IHVzYWdl IGJ5IHRoZSB0dXJuIGNsaWVudCAodGhlIFdlYlJUQyBicm93c2VyKQ0KDQpUaGVyZSBhcmUgd2F5 cywgbm90IG9ubHk6IEVudGVycHJpc2VzIG9yIElTUHMgd2lzaGluZyB0byBwcm92aWRlIHRoZWly IG93biBUVVJOIHNlcnZlciwgaW4gYW4gYXR0ZW1wdCB0byByZWR1Y2Ugc28tY2FsbGVkICJ0cmlh bmdsZSByb3V0aW5nIixuZWVkIGEgbmV3IGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbQ0KQnV0IGFs c286IC0gTlNQcyAoTmV0d29yayBTZXJ2aWNlIFByb3ZpZGVycykgd2FudCB0byBwcm92aWRlIGEg cGF0aCB3aGVyZSB0aGUgYmFuZHdpZHRoIG9mIFdlYlJUQyBpcyBiZXR0ZXIgY29wZWQgd2l0aC4N Ci0gTlNQcyBvciBFbnRlcnByaXNlcyB3YW50IHRvIG9mZmVyIGFuIEludGVybmV0IGFjY2VzcyBx dWFsaXR5IHBpcGUgZm9yIHByaW9yaXRpemVkIFJUQyAoUmVhbCBUaW1lIENvbW11bmljYXRpb24p IHRyYWZmaWMuDQotIEVudGVycHJpc2VzIGhhdmluZyByZXN0cmljdGl2ZSBmaXJld2FsbHMsIHdh bnQgdG8gcHJvdmlkZSBhIFVEUC1wYXRoIGZvciBXZWJSVEMgYW5kIHBvc3NpYmx5IGFsc28gZm9y IGJldHRlciBxdWFsaXR5IHdoZXJlIFJUQyBkbyBub3QgY29tcGV0ZSB3aXRoIGRhdGEgdHJhZmZp Yy4NCkFsc28gY29uc2lkZXJpbmcNCi0gTW9iaWxpdHk7IEl0IGlzIGNvbW1vbiB0byBtb3ZlIGZy b20gYSBMQU4gdG8gYWNjZXNzaW5nIHZpYSBXaUZpIG9yIDNHLzRHIE9UVCBjaGFubmVscywgYWxs IHNob3VsZCBiZSBhYmxlIHRvIGF1dG9tYXRpY2FsbHkgb2ZmZXIgdGhlaXIgb3duIG9wdGltYWwg VFVSTiBzZXJ2ZXINCg0KVGhpcyBsZWFkcyB1cyBpbnRvICDigJxUVVJO4oCmdG8gaWRlbnRpZnkg V2ViUlRDIGZsb3dz4oCdIGV0YyEgSXQgaXMgbm90IGEgbWlzdGFrZSwgYnV0IHRoZSB2ZXJ5IG5l ZWQgZm9yIHRoaXMgbWlsZXN0b25lIQ0KDQpBZ2FpbiwgaXQgaGFzIG5vdCBiZWVuIGRlbW9uc3Ry YXRlZCB3aHkgVFVSTiBpcyB0aGUgcmlnaHQgdGVjaG5vbG9neSBoZXJlLCBjb21wYXJlZCB0byBh IG1vcmUgdHJhbnNwYXJlbnQgZmxvdyBpZGVudGlmaWNhdGlvbiB0b29sIGxpa2UgTUFMSUNFLiBX ZSBkb24ndCBmb3JjZSBhbGwgSFRUUCByZXF1ZXN0cyB0byBsb2NhdGUgYSBIVFRQIHByb3h5IHZp YSBhbnljYXN0LCBJIGRvbid0IHNlZSB3aHkgd2UgbmVlZCB0byBkbyB0aGUgc2FtZSBmb3IgV2Vi UlRDLg0KDQpXaGF0IGFyZSB0aGUgaGVzaXRhdGlvbnMgcmFpc2VkIGhlcmU/DQo+IFRVUk4gcHJp bWFyaWx5IHRvIGlkZW50aWZ5IFdlYlJUQyBmbG93cywgYXMgb3Bwb3NlZCB0byB1c2luZyBpdCBh cyBhIE5BVCB0cmF2ZXJzYWwgdG9vbC4gVGhpcyBtYWtlcyBtZSBjb25jZXJuZWQgdGhhdCB3ZSBt YXkgYmUgdXNpbmcgdGhlIHdyb25nIHRlY2hub2xvZ3kgdG8gc29sdmUgdGhlIHByb2JsZW0NCkl0 IGlzIGNvcnJlY3QgdGhhdCBJQ0UvU1RVTi9UVVJOIHdhcyBkZXNpZ25lZCB0byBhZGRyZXNzIHRo ZSBOQVQvRmlyZXdhbGwgdHJhdmVyc2FsIHByb2JsZW0gYXNzb2NpYXRlZCB3aXRoIHJlYWwtdGlt ZSBjb21tdW5pY2F0aW9uIChTSVAgYXQgdGhhdCB0aW1lKS4gSG93ZXZlciwgaXRzIGxhcmdlc3Qg Zmxhdy9wcm9ibGVtIGlzIHRoYXQgcXVhbGl0eSB0aGluZ3Mgd2VyZSBub3QgKGNvdWxkIG5vdCBi ZT8pIGNvbnNpZGVyZWQuIFRoZSBtZXRob2TigJlzIHZlcnkgaWRlYSAobGlrZSBhbGwgc2ltaWxh ciBtZXRob2RzIGZvciBnZXR0aW5nIFJUQyB0aHJvdWdoIG9yZGluYXJ5IE5BVC9GaXJld2FsbHMp IGlzIHRvIGZvb2wgdGhlIG1lZGlhIHRocm91Z2ggYSBOQVQvRmlyZXdhbGwgdGhhdCBpcyB1bmF3 YXJlIG9mIHdoYXQgaXMgaGFwcGVuaW5nLiBUaHVzLCB0aGlzIGlzIHJvb3Qgb2YgcXVhbGl0eSBp c3N1ZXMgKGFuZCBiYW5kd2lkdGggYWxsb2NhdGlvbiBvcHRpbWl6YXRpb24pIHRoYXQgbmVlZHMg dG8gYmUgZGVhbHQgd2l0aDogUmVhbC10aW1lIHRyYWZmaWMgZmlnaHRpbmcgd2l0aCBhIGRhdGEg dHJhZmZpYyBjcm93ZGVkIGNvbmdlc3Rpb24gcG9pbnQuDQoNCkkgdGhpbmsgdGhhdCAiZm9vbGlu ZyIgaXMgYW4gaW5jb3JyZWN0IGRlc2NyaXB0aW9uLiBUaGUgTkFUIGlzIHN1cHBvc2VkIHRvIGJl IHRyYW5zcGFyZW50IHRvIHRoZSBjbGllbnQuDQoNCkJ1dCwgYSBCTEVTU0lORyBvZiBJQ0UvU1RV Ti9UVVJOIGlzIHRoYXQgaXQgY2FuIGJlIHNlZW4gYXMgYSBsZWdpdGltYXRlIHJlcXVlc3QgZm9y IGEgc3VpdGFibGUgcGlwZSBmb3IgcXVhbGl0eSBkZW1hbmRpbmcgcmVhbCB0aW1lIHRyYWZmaWMu IOKYug0KSUNFIGlzIGEgcHJlLXByb3RvY29sIHlvdSB1c2UgYmVjYXVzZSB5b3Ugd2FudCBhIHBh dGggZm9yIHJlYWwtdGltZSBtZWRpYSBiZXR3ZWVuIHBhcnRpZXMuIEhlcmU6IFRoZSBicm93c2Vy IHNheXMga25vY2sga25vY2ssIEkgd2FudCB0byBnZXQgbWVkaWEgdGhyb3VnaCAoYW5kIG9mIGNv dXJzZSB3aXRoIGFzIGdvb2QgcXVhbGl0eSBhcyByZXF1aXJlZCBhbmQgcG9zc2libGUpLg0KDQpJ ZiB0aGUgTkFUL0ZpcmV3YWxsIG93bmVyIGFuZCBuZXR3b3JrIG93bmVyIGFyZSBhbGxvd2VkIHRv IHNlZSB0aGVzZSByZXF1ZXN0cywgdGhleSBjYW4gaGVscC9hc3Npc3QgaW4gYWNoaWV2aW5nIHRo ZSBnb29kIG1lZGlhIHBhdGguIElmIHRoZXkgYXJlIG5vdCBhd2FyZSwgdGhleSBjYW5ub3QgaGVs cCENCg0KSG9wZSB0aGlzIG1hZGUgaXQgdW5kZXJzdGFuZGFibGUgb24gYW4gb3ZlcnZpZXcgbGV2 ZWwgaG93IHRoaXMgY2FuIGJlY29tZSDigJxUVVJO4oCmdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dz 4oCdDQpJdCBpcyBhbHNvIHRoZSBPTkxZIHdheSBJIGNhbiBzZWUgdG8gYWNoaWV2ZSB3aGF0IHdl IHdhbnQgdG8gYWNoaWV2ZSBhbmQgc2hvdWxkIGJlIHRoZSBhaW0gYW5kIHJlcXVpcmVtZW50IG9m IHRoaXMgbWlsZXN0b25lLg0KDQpJIGFtIHRhbGtpbmcgYWJvdXQgZ2VuZXJhbCB1c2FnZSBvZiBX ZWJSVEMgb3ZlciBJbnRlcm5ldC9tb2JpbGUgT1RUIChub3QgZmVlZGluZyBXZWJSVEMgaW50byBh cHBsaWNhdGlvbiBzcGVjaWZpYyBuZXR3b3JrcyBsaWtlIElNUyB3aGVyZSBvdGhlciBtZXRob2Rz IG1heSBleGlzdCkuDQoNClRoaXMgaXMgZ29vZCwgbm90IGV2aWwhDQoNCklmIHRoZSBoZXNpdGF0 aW9ucyBhcmUgcmFpc2VkIGJlY2F1c2Ugb2YgYSBiZWxpZWYvaG9wZS93aXNoIHRoYXQgdGhlcmUg YXJlIG5vIG9yIHdpbGwgbm90IGJlIHNldmVyZSBxdWFsaXR5IGlzc3VlcyDigJxiZWNhdXNlIGl0 IGlzIGFsbCBhYm91dCBiYW5kd2lkdGjigJ0sIOKAnGl0IHdpbGwgcmVzb2x2ZSBpdHNlbGYgd2l0 aCB0aW1l4oCdIGV0Yy4sIEkgc3Ryb25nbHkgb2JqZWN0ISBUaGF0IGlzIHdyb25nIGFuZCB3aWxs IGJlIHZlcnkgZGV0cmltZW50YWwgZm9yIFdlYlJUQyB1c2FnZS4gV2UgYWxyZWFkeSBzZWUgaXQg YW5kIEkgY2FuIGdpdmUgbnVtZXJvdXMgZXhhbXBsZXMgb2YgaG93IG11Y2ggbGVzcyBxdWFsaXR5 IGRlbWFuZGluZyBWb0lQIGlzL2lzIG5vdCBoYW5kbGVkIHF1YWxpdHkgd2lzZSBhbmQgdGhhdCBp dCBtYXR0ZXJzLiBBbmQsIHdoYXQgd291bGQgYmUgYmFkIGNvbnNpZGVyaW5nIHF1YWxpdHkgaXNz dWVzIGFuZCBhbGxvd2luZy9lbmNvdXJhZ2luZyBtZXRob2RzIHRvIGRlYWwgd2l0aCB0aGVtPw0K DQpJZiB0aGUgaGVzaXRhdGlvbnMgYXJlIHJhaXNlZCwgYmVjYXVzZSBvZiBzdXNwaWNpb24gdGhh dCB0aGUgbWV0aG9kcyB3ZSBtYXkgcmVjb21tZW5kIG1heSBiZSBtaXN1c2VkIHRvIHN0b3AvYmxv Y2svZGVzdHJveSBXZWJSVEMgdXNhZ2UgKGUuZy4gdG8gcHJvdGVjdCBpbmNvbWUgZnJvbSBjYXJy aWVyIHRlbGVwaG9ueSB0cmFmZmljKSwgSSBjb3VsZCB1bmRlcnN0YW5kIGFuZCB3b3VsZCBmaWdo dCB0aGUgc2FtZSBiYXR0bGUuIEJ1dCBob3BlZnVsbHksIHRob3NlIGRheXMgYXJlIChzb29uKSBv dmVyIOKAkyBBdCBsZWFzdCBmb3J3YXJkIHRoaW5raW5nIGNhcnJpZXLigJlzIHJlYWxpemUgdGhh dCBhbHJlYWR5LiBXZWIgUlRDIHdpbGwgaGFwcGVuLiBXaGljaCBjdXN0b21lcnMgd2FudCB0byBw YXkgZm9yIGFuIGFjY2VzcyB3aXRoIGJsb2NrZWQgV2ViUlRDPyBUaGUgY2FycmllcuKAmXMgb2Zm ZXJpbmcvYXNzdXJpbmcgZ29vZCBXZWJSVEMgd2lsbCByYXRoZXIgZ2V0IHRoZSBjdXN0b21lcnMg YW5kIGluY29tZSDimLouIChNYXliZSB0aGUgV2ViIGJyb3dzZXIgY2FuIGRldGVjdCBhbmQgZW5j b3VyYWdlIHRoaXPigKYpDQoNCklmIHRoZXJlIGFyZSB0ZWNobmljYWwgY29uY2VybnMgb2YgYmFk IHJlc3VsdCwgb3IgYmV0dGVyIG1ldGhvZHMgYWxsb3dpbmcgbmV0d29yayBwcm92aWRlcnMgYW5k IExBTiBtYW5hZ2VycyB0byBvZmZlciBhbmQgaW5mb3JtIHRoZSBicm93c2VyIHRoYXQgdGhlcmUg YXJlIGdvb2QgbWVkaWEgcGF0aHMgdG8gYmUgdXNlZCwgYW5kIHRoYXQgdGhlIHdlYiBicm93c2Vy IGF1dG9tYXRpY2FsbHkgY2FuIGNob3NlIHRob3NlLCB0aGVuIGxldCB1cyBhbGwgdW5kZXJzdGFu ZCB0aG9zZSwgc28gd2UgY2FuIGFjaGlldmUgd2hhdCBzaG91bGQgYmUgYWNoaWV2ZWQgYnkgdGhp cyBtaWxlc3RvbmUuDQoNClNreXBlLCBIYW5nb3V0cywgRmFjZXRpbWUgYXJlIGRvaW5nIGJpbGxp b25zIG9mIG1pbnV0ZXMgcGVyIHdlZWsgYW5kIHRoZSBJbnRlcm5ldCBoYXMgbm90IG1lbHRlZCB5 ZXQuIElmIHdlIG5lZWQgdG8gZG8gZmxvdyBpZGVudGlmaWNhdGlvbiB0byBhbGxvdyB0cmFmZmlj IHRvIGJlIHByaW9yaXRpemVkLCBmaW5lIChzZWUgYWJvdmUgcmVnYXJkaW5nIG15IHByZWZlcnJl ZCBhcHByb2FjaCksIGJ1dCBmb3JjaW5nIGFsbCBXZWJSVEMgdHJhZmZpYyB0aHJvdWdoIGEgTUlU TSAoVFVSTiBzZXJ2ZXIpIGlzIGEgbXVjaCBiaWdnZXIganVtcCB0aGF0IEkgZG9uJ3QgeWV0IHNl ZSB0aGUganVzdGlmaWNhdGlvbiBmb3IuDQoNCkluIHNob3J0OiBUVVJOIGlzIGEgdGVjaG5vbG9n eSB0aGF0IGlzIHN1cHBvc2VkIHRvIGZhZGUgYXdheSB3aXRoIHRoZSBtb3ZlIHRvIElQdjYuIEkg ZG9uJ3QgdGhpbmsgd2Ugd2FudCB0byBtYWtlIGl0IGEgY3JpdGljYWwgZWxlbWVudCBvZiBXZWJS VEMuDQoNCi9LYXJsDQoNCg0KRnLDpW46IERhbiBXaW5nIFttYWlsdG86ZHdpbmdAY2lzY28uY29t PG1haWx0bzpkd2luZ0BjaXNjby5jb20+XQ0KU2tpY2thdDogZGVuIDExIGZlYnJ1YXJpIDIwMTQg MTg6MjUNClRpbGw6IE1hcmMgQmxhbmNoZXQNCktvcGlhOiBKdXN0aW4gVWJlcnRpOyB0aXJlZGR5 QGljaXNjby5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT47IEthcmwgU3RhaGw7IHRyYW1A aWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+OyBTaW1vbiBQZXJyZWF1bHQNCg0Kw4RtbmU6 IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hh bmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQoNCk9uIEZlYiAxMSwgMjAxNCwgYXQgOTow OCBBTSwgTWFyYyBCbGFuY2hldCA8bWFyYy5ibGFuY2hldEB2aWFnZW5pZS5jYTxtYWlsdG86bWFy Yy5ibGFuY2hldEB2aWFnZW5pZS5jYT4+IHdyb3RlOg0KDQpMZSAyMDE0LTAyLTExIMOgIDAwOjM5 LCBEYW4gV2luZyA8ZHdpbmdAY2lzY28uY29tPG1haWx0bzpkd2luZ0BjaXNjby5jb20+PiBhIMOp Y3JpdCA6DQoNCg0KT24gRmViIDEwLCAyMDE0LCBhdCA1OjMwIFBNLCBKdXN0aW4gVWJlcnRpIDxq dWJlcnRpQGdvb2dsZS5jb208bWFpbHRvOmp1YmVydGlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpH b29kIHRvIHNlZSB0aGVyZSBpcyBhIGxvdCBvZiBpbnRlcmVzdCBmb3IgdGhpcyBtaWxlc3RvbmUu IEJ1dCBiYXNlZCBvbiB0aGUgZGVzY3JpcHRpb24gaGVyZSwgaXQgc2VlbXMgbGlrZSB3ZSB3YW50 IHRvIHVzZSBUVVJOIHByaW1hcmlseSB0byBpZGVudGlmeSBXZWJSVEMgZmxvd3MsIGFzIG9wcG9z ZWQgdG8gdXNpbmcgaXQgYXMgYSBOQVQgdHJhdmVyc2FsIHRvb2wuIFRoaXMgbWFrZXMgbWUgY29u Y2VybmVkIHRoYXQgd2UgbWF5IGJlIHVzaW5nIHRoZSB3cm9uZyB0ZWNobm9sb2d5IHRvIHNvbHZl IHRoZSBwcm9ibGVtLg0KDQorMS4NCg0KSSB3b3VsZCBwcmVmZXIgYWxsb3dpbmcgZmxvd3MgdG8g ZXN0YWJsaXNoIHRoZW1zZWx2ZXMgdXNpbmcgdGhlaXIgJ2Jlc3QnIHBhdGgsIGFuZCB0aGUgYmVz dCBwYXRoIGlzIHNlbGRvbSB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIuICBXaGVuIHdlIGltYWdpbmUg SVB2NiBpbiBvdXIgZnV0dXJlLCB3ZSBkb24ndCB3YW50IHRvIGZvcmNlIGFuIGFwcGxpY2F0aW9u LWxldmVsIHByb3h5IChUVVJOKSBzZXJ2ZXIgb24gdGhlIHBhdGggc29sZWx5IGZvciB0cmF2ZXJz aW5nIGFuIElQdjYgZmlyZXdhbGwuDQoNCg0KSXQgc2VlbXMgdGhpcyB0aHJlYWQgaXMgY29uZmxh dGluZyBhbGwgdGhlIHBvc3NpYmxlIHJlYXNvbnMgLyBqdXN0aWZpY2F0aW9ucyBmb3IgVFVSTjoN CiAgKiBtb2JpbGl0eQ0KICAqIE5BVCB0cmF2ZXJzYWwgKGJvdGggZW5kcG9pbnRzIGFyZSBiZWhp bmQgZW5kcG9pbnQtZGVwZW5kZW50IG1hcHBpbmcgTkFUcykNCiAgKiBmaXJld2FsbCB0cmF2ZXJz YWwgKGZpcmV3YWxsIGJsb2NrcyBVRFApDQogICogZW5oYW5jaW5nIHByaXZhY3kNCg0KVW5mb3J0 dW5hdGVseSB0aGUgVFVSTiBzZXJ2ZXIgbm9yIHRoZSBlbmRwb2ludCByZWFsbHkga25vdyB3aGlj aCBvZiB0aG9zZSB1c2UtY2FzZXMgaXMgZGVzaXJlZCAoYnkgdGhlIHVzZXIgb3IgYnkgdGhlIElU IG5ldHdvcmsgYWRtaW5pc3RyYXRvcikgb3IgbmVjZXNzYXJ5IChmb3IgdGhlIGNhbGwgdG8gd29y ayBhdCBhbGwpLg0KDQpEYW4sIHdoaWxlIEkgYWdyZWUgaW4gcHJpbmNpcGxlLCBJIGRvdWJ0IHRo YXQgYSB1c2VyIGNvdWxkIGV2ZXIgc2F5ICJJIHdhbnQgbW9iaWxpdHkgb3IgSSB3YW50IE5BVCB0 cmF2ZXJzYWwiLiBJIHRoaW5rIHRoZSB1c2VyIG9ubHkgd2FudCB0aGUgY2FsbCB0byBzdWNjZWVk LCB3aGF0ZXZlciB0aGUgcHJvcGVydGllcyBvZiBpdHMgbmV0d29yayBwb2ludCBvZiBhdHRhY2ht ZW50IGFyZS4NCg0KU28gd2hhdCBjYW4gd2UgZG8/ICBTaG91bGQgdGhlIFRVUk4gc2VydmVyIHBy b3ZpZGUgYW55IGFuZCBhbGwgc2VydmljZXMgdGhlIFRVUk4gY2xpZW50IG1pZ2h0IHBvc3NpYmx5 IHdhbnQsIGFzIHRoYXQgaXMgd2hhdCBhIHJvYnVzdCBUVVJOIHNlcnZlciB3aWxsIGRvLCBhbmQg dGhlIGVuZHBvaW50IHNob3VsZCBwcmVmZXIgVFVSTiBjYW5kaWRhdGVzIG92ZXIgYWxsIG90aGVy cyBiZWNhdXNlIHRoZXJlIG1pZ2h0IGJlIHNvbWUgZnVuY3Rpb25hbGl0eSAvIHVzZWZ1bG5lc3Mg b2YgVFVSTiB0aGF0IHRoZSB1c2VyIG1pZ2h0IGdhaW4gdGhyb3VnaCBUVVJOIChlLmcuLCBlbmhh bmNlZCBwcml2YWN5KT8NCg0KLWQNCg0KDQoNCiBUaGlzIHNlZW1zIHByb2JsZW1hdGljLiAgUGVy aGFwcyB3ZSBuZWVkIGEgd2F5IHRvIHNpZ25hbCB0aGUgZGVzaXJlZCB1c2UtY2FzZSAoInRyYWl0 IiksIG9yIGFzIEp1c3RpbiBzdWdnZXN0cywgdXNpbmcgYSBkaWZmZXJlbnQgdGVjaG5vbG9neSBm b3Igc29tZSBvZiB0aGVzZSB1c2UtY2FzZXMuDQoNCi1kDQoNCg0KDQoNCk9uIE1vbiwgRmViIDEw LCAyMDE0IGF0IDM6MTggUE0sIEthcmwgU3RhaGwgPGthcmwuc3RhaGxAaW50ZXJ0ZXguc2U8bWFp bHRvOmthcmwuc3RhaGxAaW50ZXJ0ZXguc2U+PiB3cm90ZToNClNpbW9uLA0KDQpHb29kIHF1ZXN0 aW9ucyAtIHNlZSBpbmxpbmUgYmVsb3cgLS0+IC4NClNvbWUgbW9yZSB0aG91Z2h0IGlzIHJlcXVp cmVkIQ0KDQovS2FybA0KDQotLS0tLVVyc3BydW5nbGlndCBtZWRkZWxhbmRlLS0tLS0NCkZyw6Vu OiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0cmFtLWJvdW5jZXNA aWV0Zi5vcmc+XSBGw7ZyIFNpbW9uIFBlcnJlYXVsdA0KU2tpY2thdDogZGVuIDEwIGZlYnJ1YXJp IDIwMTQgMTU6MTYNClRpbGw6IEthcmwgU3RhaGw7IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1A aWV0Zi5vcmc+OyB0aXJlZGR5QGljaXNjby5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT4N CsOEbW5lOiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVy eSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KS2FybCwNCg0KSXQgaXMgZ3Jl YXQgdG8gc2VlIHN1Y2ggZW50aHVzaWFzbSEgVGhhbmtzIQ0KDQpJIGhhdmUgYSBjb3VwbGUgdGVj aG5pY2FsIHF1ZXN0aW9ucy4uLg0KDQpMZSAyMDE0LTAyLTA4IDA4OjExLCBLYXJsIFN0YWhsIGEg w6ljcml0IDoNCj4gLSBOb3RlIHRoYXQgdG8gYWNoaWV2ZSBzb21lIG9mIHRoZSBhYm92ZSBwb2lu dHMsIFRVUk4gbXVzdCBiZSBmYXZvcmVkDQo+IG92ZXIgU1RVTiB0byBlbmZvcmNlIHRoYXQgdGhl IFRVUk4tcGF0aCBhY3R1YWxseSBpcyB1c2VkLiAoVGhlIEFueWNhc3QNCj4gbWV0aG9kIHN1Z2dl c3RlZCBiZWxvdywg4oCcYXV0b21hdGljYWxseeKAnSBkb2VzIHRoaXMuKQ0KDQpJIHVuZGVyc3Rh bmQgdGhlIFNUVU4gdnMgVFVSTiBwcmlvcml0eSBpc3N1ZS4gQnV0IEkgZG9uJ3Qgc2VlIGhvdyBh bnljYXN0IGFmZmVjdHMgaXQgaW4gYW55IHdheS4gQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbj8NCi0t LSBHb29kIHBvaW50IC0gSSB3YXMgYSBiaXQgcXVpY2sgaGVyZSAobWF5YmUgdG9vIHF1aWNrKQ0K V2UgaGF2ZSBnaXZlbiB0aGlzIHF1aXRlIGJpdCBvZiB0aG91Z2h0LCBzaW5jZSBldmVuIGlmIGEg VFVSTiBzZXJ2ZXIgaXMgcHJvdmlkZWQgYW5kIGRpc2NvdmVyZWQsIENVUlJFTlQgdXNhZ2Ugb2Yg SUNFIG1heSBzdWdnZXN0IGEgY2FuZGlkYXRlIGZyb20gdGhlIHJlbW90ZSBwYXJ0eSB0aGF0IHdp bGwgbWFrZSBhIGNvbm5lY3Rpb24gd2l0aG91dCB0aGUgbmVlZC91c2FnZSBvZiB0aGUgVFVSTiBz ZXJ2ZXIgKHRoYXQgd2Ugd2FudGVkIHRvIGJlIHVzZWQgZm9yIHRoZSBnb29kIHB1cnBvc2VzIGxp c3RlZCkuDQoNClRoZSBvbmx5IHdheSB3ZSBmb3VuZCBhcm91bmQgdGhpcywgd2FzIHRvIHN0b3Ag U1RVTiB0aHJvdWdoIHRoZSBJUCBkZWZhdWx0IGdhdGV3YXkgKGxpa2UgYSByZXN0cmljdGl2ZSBF bnRlcnByaXNlIGZpcmV3YWxsIGRvZXMgaW5oaWJpdGluZyBJQ0UgY29ubmVjdGl2aXR5LCB3aGlj aCBvdGhlcnMgYXJlIGNvbmNlcm5lZCBhYm91dC4uLikuIFNpbmNlIHRoZSBwcm92aXNpb25pbmcg b2YgYXV0by1kaXNjb3ZlcnkgdXNpbmcgdGhlIGFueWNhc3QgbWVjaGFuaXNtLCB3b3VsZCBiZSBh ZGRpbmcgYSByb3V0ZSBpbiBhIGRlZmF1bHQgZ2F0ZXdheSwgYWRkaW5nIGEgZmlyZXdhbGwgcnVs ZSB0byBlYXQgU1RVTiBwYWNrZXRzIHdvdWxkIGFzc3VyZSB0aGF0IHRoZSBwcm92aXNpb25lZCBU VVJOIHNlcnZlciBhY3R1YWxseSBiZWNvbWVzIHVzZWQgKGFuZCBub3QgYnlwYXNzZWQgImJ5IGFj Y2lkZW50IikuIChUaGF0IHdhcyB0aGUgdGhvdWdodCBiZWhpbmQgdGhlIOKAnGF1dG9tYXRpY2Fs bHnigJ0gd2l0aGluIHF1b3Rlcy4pDQoNCkJVVCwgc2luY2UgeW91IGJyb3VnaHQgdXAgdGhlIHF1 ZXN0aW9uLCBhc3N1bWluZyB0aGF0IHdlIGhhdmUgdGhlIHBvd2VyIHRvIGVuZm9yY2UgV2ViUlRD IHVzYWdlIG9mIElDRSwgSSBiZWxpZXZlIGEgTVVTVCByZXF1aXJlbWVudCB0byB1c2UgYW4gYXV0 by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVyIGluc3RlYWQgb2YgU1RVTiwgd291bGQgc29sdmUgdGhl IHNhbWUgcHJvYmxlbS4gSG93ZXZlciwgdGhpbmtpbmcgZnVydGhlciAoaW4gcmVsYXRpb24gdG8g eW91ciBuZXh0IHF1ZXN0aW9uIC0gImFueW9uZSBjb3VsZCBzZXQgdXAgYSBiYWRseS1tYWludGFp bmVkIiAtIGVuZm9yY2luZyBzdWNoIElDRSB1c2FnZSBtYXkgbm90IGJlIGdvb2QuKQ0KDQoNCj4g LSAzXnJkIFRoZSBBbnljYXN0IG1ldGhvZCBiZWxvdyDigJMgSSBzZWUgbm8gcHJvYmxlbQ0KPg0K PiBJdCBhbHNvIGhhcyB0aGUgYWR2YW50YWdlIG9mIGVuY291cmFnaW5nIChidXQgbm90IHJlcXVp cmluZykgdGhlDQo+IFNUVU4vVFVSTiB0byBiZSBidWlsdCBpbiB0aGUgZGVmYXVsdCBnYXRld2F5 IG9yIE5BVC9maXJld2FsbC9hY2Nlc3MNCj4gcm91dGVyIGl0c2VsZiwgd2l0aCBhIHNlY29uZCBp bnRlcmZhY2UgdG8gYSBwdWJsaWMgSVAgYWRkcmVzcyBvbiB0aGUNCj4gV0FOIHNpZGUuIChDdXJy ZW50IHZvbHVtZSBkZXBsb3llZCwgbG93IGNvc3QgTlNQIHRyaXBsZSBwbGF5IG1vZGVtcw0KPiB1 c3VhbGx5IGhhdmUgYSBxdWFsaXR5IGFzc3VyZWQgbGV2ZWwgMiBvciBsZXZlbCAzIFdBTiBwaXBl IGZvciBqdXN0DQo+IHZvaWNlIChhbmQgYW5vdGhlciBmb3IgSVBUVikg4oCTIFRoZSBhbnljYXN0 IGRpc2NvdmVyZWQgVFVSTi1zZXJ2ZXIgY2FuDQo+IGJlIHRoZSBhY2Nlc3MgZ2F0ZXdheSB0byBz dWNoIHF1YWxpdHkgcGlwZSBmb3IgV2ViUlRDIG1lZGlhLCBpbiBhDQo+IHNpbmdsZSBOU1AgcHJv dmlkZWQgQ1BFLCBzY2FsaW5nIGZyb20gcmVzaWRlbnRpYWwgYW5kIHVwLikNCg0KU3VwcG9zZSB3 ZSBkZWZpbmUgd2VsbC1rbm93biBhbnljYXN0IFRVUk4gc2VydmVyIGFkZHJlc3Nlcy4gSG93IHdv dWxkIHRoaXMgbm90IGJlIHN1YmplY3QgdG8gdGhlIHNhbWUgc2VydmljZSBxdWFsaXR5IGlzc3Vl cyB0aGF0IHBsYWd1ZWQgNnRvND8gVGhhdCBpcywgYW55b25lIGNvdWxkIHNldCB1cCBhIGJhZGx5 LW1haW50YWluZWQsIHVuZGVyLXByb3Zpc2lvbmVkIFRVUk4gc2VydmVyIGFuZCBhbm5vdW5jZSBp dCBvdmVyIEJHUCB0byB0aGUgd29ybGQsIGFzIGl0IHdhcyBkb25lIGZvcg0KNnRvNCByZWxheXMu IE9yIGp1c3QgYmFkIEJHUCBvdXRib3VuZCBmaWx0ZXIgY29uZmlndXJhdGlvbi4gQW5kIGhvdyBj YW4gd2UgcHJldmVudCB0cmlhbmdsZSByb3V0aW5nPyBUaGVyZSBpcyBub3RoaW5nIGd1YXJhbnRl ZWluZyB0aGF0IHRoZSBhbnljYXN0IHNlcnZlciB5b3Ugc2VlIGlzIGJlaW5nIHByb3ZpZGVkIHRv IHlvdSBieSB5b3VyIElTUCwgcmF0aGVyIHRoYW4gYSBzZXJ2ZXIgc2l0dGluZyBvbiB0aGUgb3Ro ZXIgc2lkZSBvZiB0aGUgcGxhbmV0Lg0KLS0tIEdvb2QgcG9pbnQgLSBuZWVkcyB0byBiZSByZXNv bHZlZC4gRm9yIHRoaXMgSSBkb24ndCBoYXZlIGEgcmVhZHkgYW5zd2VyLi4uDQpBbiBhdXRvLWRp c2NvdmVyZWQgVFVSTiBzZXJ2ZXIgbXVzdCBiZSB0cnVzdGVkICh3aGF0ZXZlciBtZXRob2QgaXQg aXMgZGlzY292ZXJlZCBieSkuIFdlIGFyZSB0cnVzdGluZyB0aGUgb25lIHByb3ZpZGluZyB1cyB3 aXRoIGFuIElQIGFkZHJlc3MgYW5kIGRlZmF1bHQgZ2F0ZXdheSBhbnl3YXkuIEl0IHdvdWxkIGJl IGVhc3kgaWYgd2UgY291bGQgcmV1c2UgdGhhdCB0cnVzdCwgaW5zdGVhZCBvZiBhbm90aGVyIG1l Y2hhbmlzbXMuDQoNCklzIHRoZXJlIGEgZ29vZCB3YXkgZm9yIHRoZSBicm93c2VyIHRvIGNoZWNr IHRoYXQgdGhlIGFueWNhc3QgYWRkcmVzcyBpcyBub3QgaGFuZGxlZCBiZXlvbmQgdGhlIG5ldHdv cmsgc2VydmljZSBwcm92aWRlcidzIGRlZmF1bHQgZ2F0ZXdheT8gSWRlYXM/DQoNCg0KDQpUaGFu a3MsDQpTaW1vbg0KLS0NCkRUTiBtYWRlIGVhc3ksIGxlYW4sIGFuZCBzbWFydCAtLT4gaHR0cDov L3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5jYTxodHRwOi8vcG9zdGVsbGF0aW9uLnZpYWdlbmllLmNh Lz4NCk5BVDY0L0ROUzY0IG9wZW4tc291cmNlICAgICAgICAtLT4gaHR0cDovL2VjZHlzaXMudmlh Z2VuaWUuY2E8aHR0cDovL2VjZHlzaXMudmlhZ2VuaWUuY2EvPg0KU1RVTi9UVVJOIHNlcnZlciAg ICAgICAgICAgICAgIC0tPiBodHRwOi8vbnVtYi52aWFnZW5pZS5jYTxodHRwOi8vbnVtYi52aWFn ZW5pZS5jYS8+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0 DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWls dG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHJhbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K dHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBs aXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCg0K --_000_913383AAA69FF945B8F946018B75898A242AD996xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KaDQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNCBDaGFy IjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCgltc28tbGluZS1oZWln aHQtYWx0OjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpoNQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCglt c28tc3R5bGUtbGluazoiSGVhZGluZyA1IENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCW1zby1saW5lLWhlaWdodC1hbHQ6MHB0Ow0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglmb250LXdlaWdodDpib2xkO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29Q bGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7 fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhl YWRpbmc0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyA0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDQiOw0KCWZvbnQtZmFtaWx5 OiJDYW1icmlhIiwic2VyaWYiOw0KCWNvbG9yOiM0RjgxQkQ7DQoJZm9udC13ZWlnaHQ6Ym9sZDsN Cglmb250LXN0eWxlOml0YWxpYzt9DQpzcGFuLkhlYWRpbmc1Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSGVhZGluZyA1IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1s aW5rOiJIZWFkaW5nIDUiOw0KCWZvbnQtZmFtaWx5OiJDYW1icmlhIiwic2VyaWYiOw0KCWNvbG9y OiMyNDNGNjA7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0K c3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJ Zm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnAuQmFsbG9uZ3RleHQsIGxpLkJhbGxvbmd0ZXh0LCBkaXYuQmFsbG9uZ3RleHQN Cgl7bXNvLXN0eWxlLW5hbWU6QmFsbG9uZ3RleHQ7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvbmd0 ZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpz cGFuLkJhbGxvbmd0ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9uZ3RleHQgQ2hhciI7 DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOkJhbGxvbmd0ZXh0Ow0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsdWU7fQ0K cC5PZm9ybWF0ZXJhZHRleHQsIGxpLk9mb3JtYXRlcmFkdGV4dCwgZGl2Lk9mb3JtYXRlcmFkdGV4 dA0KCXttc28tc3R5bGUtbmFtZToiT2Zvcm1hdGVyYWQgdGV4dCI7DQoJbXNvLXN0eWxlLWxpbms6 Ik9mb3JtYXRlcmFkIHRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCnNwYW4uT2Zvcm1hdGVyYWR0ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi T2Zvcm1hdGVyYWQgdGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6Ik9mb3JtYXRlcmFkIHRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNw YW4uRW1haWxTdHlsZTMzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsdWU7fQ0KcC5SdWJyaWs0LCBsaS5SdWJy aWs0LCBkaXYuUnVicmlrNA0KCXttc28tc3R5bGUtbmFtZToiUnVicmlrIDQiOw0KCW1zby1zdHls ZS1saW5rOiJSdWJyaWsgNCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0Kc3Bhbi5SdWJyaWs0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUnVicmlrIDQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IlJ1YnJpayA0 IjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KcC5S dWJyaWs1LCBsaS5SdWJyaWs1LCBkaXYuUnVicmlrNQ0KCXttc28tc3R5bGUtbmFtZToiUnVicmlr IDUiOw0KCW1zby1zdHlsZS1saW5rOiJSdWJyaWsgNSBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5SdWJyaWs1Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiUnVicmlrIDUgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxl LWxpbms6IlJ1YnJpayA1IjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWZvbnQtd2Vp Z2h0OmJvbGQ7fQ0KcC5IVE1MLWZyZm9ybWF0ZXJhZCwgbGkuSFRNTC1mcmZvcm1hdGVyYWQsIGRp di5IVE1MLWZyZm9ybWF0ZXJhZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCAtIGbDtnJmb3JtYXRl cmFkIjsNCgltc28tc3R5bGUtbGluazoiSFRNTCAtIGbDtnJmb3JtYXRlcmFkIENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUwtZnJmb3Jt YXRlcmFkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCAtIGbDtnJmb3JtYXRlcmFkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCAtIGbDtnJm b3JtYXRlcmFkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uZ3JleQ0KCXtt c28tc3R5bGUtbmFtZTpncmV5O30NCnNwYW4uRW1haWxTdHlsZTQxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkhpIEthcmwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRpZCBub3QgdW5kZXJzdGFuZCBob3cg VFVSTiBzZXJ2ZXIgd2lsbCBpZGVudGlmeSBpZiBpdOKAmXMgV2ViUlRDIG1lZGlhIHN0cmVhbXMg b3IgZ2FtaW5nIHRyYWZmaWMgb3Igc29tZSBvdGhlciBkYXRhIHRyYWZmaWMgcmVsYXllZCB0aHJv dWdoIGl0IHRvIHNldCB0aGUgZGlmZnNlcnYNCiBiaXRzIGNvcnJlY3RseSAhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4t VGlydS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBLYXJsIFN0YWhsIFttYWlsdG86a2FybC5zdGFobEBpbnRlcnRleC5zZV0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgNTowNSBQTTxi cj4NCjxiPlRvOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgJ0h1dHRvbiwgQW5k cmV3JzsgJ0p1c3RpbiBVYmVydGknOyBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFs KTxicj4NCjxiPkNjOjwvYj4gdGlyZWRkeUBpY2lzY28uY29tOyAnU2ltb24gUGVycmVhdWx0Jzsg J09sZWcgTW9za2FsZW5rbyc7IHRyYW1AaWV0Zi5vcmc7ICdNYXJjIEJsYW5jaGV0JzsgRGFuIFdp bmcgKGR3aW5nKTxicj4NCjxiPlN1YmplY3Q6PC9iPiBJTVBPUlRBTlQgQ0xBUklGSUNBVElPTlM6 IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNt IGZvciBlbnRlcnByaXNlIGFuZCBJU1BzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5PbiB0 aGUgc2lkZSBvZiB0aGlzIFRSQU0tbGlzdCwgSSBhbHNvIGdvdCB0aGlzIHF1ZXN0aW9uOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mZ3Q7IFJlZ2FyZGluZyB0aGUgZW50ZXJwcmlzZSBjYXNlLCBJIGFtIG5vdCBz dXJlIEkgZm9sbG93IHlvdXIgYXJndW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDsgRG8geW91IG1l YW4gdGhhdCBieSBzZXR0aW5nIHVwIGFuIGVudGVycHJpc2UgVFVSTiBzZXJ2ZXIsIGFuZCBvcGVu IHRoZSBmaXJld2FsbCBmb3IgbWVkaWEgb3ZlciBVRFAgZnJvbS90byBUVVJOIHNlcnZlciBiZSB0 aGUgc29sdXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tLS0tIEFzIHdlIGFsbCByZWFs aXplLCB0aGF0IHdvdWxkIG9mIGNvdXJzZSBub3QgaGVscCBvciBpbXByb3ZlIHRoaW5nczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5UaGUg aW50ZW5kZWQgc29sdXRpb24gaW4gdGhlIGVudGVycHJpc2UgY2FzZSBoYXMgbm90IHlldCBiZWVu IHNwZWxsZWQgb3V0IGluIHRoaXMgVFJBTS1saXN0IGRpc2N1c3Npb24sIHNvIGZvciBiZXR0ZXIg dW5kZXJzdGFuZGluZywgbGV0IG1lIGNvcHkgYSBmZXcgdGhpbmdzIGZyb20NCiB0aGUgZGlzY3Vz c2lvbiBpbiBTZXB0ZW1iZXIvT2N0b2JlciBvbiB0aGUgUlRDV0VCLWxpc3QgYW5kIHdoYXQgaXMg KHNpbmNlIGxvbmcpIHNwZWxsZWQgb3V0IGluIHRoZSBkcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2Fz ZXMtYW5kLXJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Rm9yIGJldHRlciB1bmRlcnN0YW5kaW5nLCBJIGFsc28gd2Fu dCB0byBwb2ludCBvdXQgdGhhdCBhIFRVUk4gY2FuIGhhdmUgdHdvIGludGVyZmFjZXMgKGFjdGlu ZyBsaWtlIGEgcm91dGVyIGZvciBtZWRpYSBiZXR3ZWVuIGRpZmZlcmVudCBuZXR3b3JrcykuIFRo aXMgYWxsb3dzIHRvDQogZWFzaWVyIHVuZGVyc3RhbmQgdGhhdCBjYW4gVFVSTiBzZXJ2ZXJzIGNh biBkaXJlY3QgYSBiZXN0IG1lZGlhIHBhdGggKHJhdGhlciB0aGFuIGp1c3QgdGhpbmtpbmcgdGhh dCBhIFRVUk4gc2VydmljZSBpcyBhIGRldmljZSB3aGljaCBtZWRpYSBqdXN0IGJvdW5jZXMgYWdh aW5zdCBhdCBvbmUgaW50ZXJmYWNlKS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5BbmQsIHdlIGNhbiBhbHNvIGhvcGUgZm9yIHRoYXQg YSBUVVJOIHNlcnZlciBiZWNvbWVzIGEgKGNvbW1vbikgY29tcG9uZW50IG9mIGEgZmlyZXdhbGws IHdoaWNoIHdvdWxkIGFsbG93IHRoZSBmaXJld2FsbCB0byB1bmRlcnN0YW5kIHRoYXQgdGhlIG1l ZGlhIGRpcmVjdGVkIHRvDQogaXQgaXMgUlRDIGFuZCBzaG91bGQgYmUgcHJpb3JpdGl6ZWQgd2hl cmVieSB0aGUgZmlyZXdhbGwgY2FuIHRyYWZmaWMgc2hhcGVkIChiYWNrLW9mZiBkYXRhIHRyYWZm aWMgdGhhdCBtYXkgYmUgZmlsbGluZyBpdHMgSW50ZXJuZXQgcGlwZSkgYXMgd2VsbCBhcyBlLmcu IHNldCBkaWZmc2VydmUgYml0cyBvciB0YWtlIG90aGVyIG1lYXN1cmVzIHRvIGFzc2lzdCBwcm9w ZXIgcXVhbGl0eSBoYW5kbGluZyB0aG91Z2h0IHRoZSBuZXR3b3JrLiAoVGhlc2UNCiBhcmUgY29t bW9uIG1lY2hhbmlzbXMgYXZhaWxhYmxlIGFuZCB1c2VkIGluIGZpcmV3YWxscy9OQVRzL2FjY2Vz cyByb3V0ZXJzLCBidXQgVFVSTiBzZXJ2ZXJzIGFyZSBub3QgeWV0IGluY2x1ZGVkIHN1Y2ggZGV2 aWNlcy4pIFRoZSBzYW1lIGdvZXMgZm9yIGFjY2VzcyByb3V0ZXJzL2RlZmF1bHQgZ2F0ZXdheXMs IERQSXMgaW4gdGhlIHRyYW5zcG9ydCBuZXR3b3JrIGl0c2VsZiDigJMgVFVSTiBzZXJ2ZXJzIGlu Y2x1ZGVkIGluIHN1Y2ggcG9pbnRzIHdlcmUNCiBtZWRpYSBjYW4gcGFzcyBhbmQgcXVhbGl0eSBt ZWFzdXJlcyBhcHBsaWVkIG1heS93aWxsIGJlIHZlcnkgdXNlZnVsIHRvIGdldCB1cyBXZWJSVEMg bWVkaWEgd2l0aCB0aHJvdWdoIG5ldHdvcmtzIHdpdGhvdXQgcXVhbGl0eSBkZXN0cnVjdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ RnJvbSB0aGUgUlRDV0VCIG1haWxpbmcgbGlzdCBTZXB0ZW1iZXIgMjA8c3VwPnRoPC9zdXA+IChi eSBtZSk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QW4g ZW50ZXJwcmlzZSBuZXR3b3JrIHRoYXQgd2FudCB0byBrZWVwIGEgcmVzdHJpY3RpdmUgZmlyZXdh bGwgbm90IGFsbG93aW5nIFVEUCB0cmFmZmljLCBjb3VsZCBwcm92aWRlIGEgcmVhbC10aW1lIHBh dGggdXNpbmcgYSBUVVJOIHNlcnZlciBwYXJhbGxlbGluZyB0aGUgZmlyZXdhbGwsIGluc3RlYWQg b2YgdHVubmVsaW5nIFJUUCB0aHJvdWdoIGFsd2F5cyBvcGVuIGh0dHAgb3IgaHR0cHMgcG9ydHMg cmVzdWx0aW5nDQogaW4gUlRQIG1lZGlhIG92ZXIgVENQIOKAkyB3aXRoIHNldmVyZSBxdWFsaXR5 IHByb2JsZW1zIGZyb20gVENQIHJldHJhbnNtaXNzaW9ucyBvZiBkcm9wcGVkIHBhY2tldHMuIFRo ZSBUVVJOIHNlcnZlciBhZGRyZXNzIGlzIG1vc3QgZWFzaWx5IHByb3ZpZGVkIGluIHRoZSBzYW1l IHdheSBhcyB0aGUgSVAgYWRkcmVzcyBhbmQgRE5TIGFkZHJlc3MuIChUaGF0IHdvdWxkIGFsc28g cHV0IHRoZSByaWdodCBwYXJ0eSBpbiBjb250cm9sIOKAkyBUaGUgbmV0d29yaw0KIHByb3ZpZGVy IChoZXJlIHRoZSBlbnRlcnByaXNlKSBkZWNpZGVzIHdoYXQgaXMgYWxsb3dlZCBvbiBoaXMgbmV0 d29yay4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoZSBicm93c2VyIHNob3VsZCBz ZWxlY3Qgd2hpY2ggYXZhaWxhYmxlIFRVUk4gc2VydmVyIGFkZHJlc3MgdG8gdXNlIGluIHRoZSBm b2xsb3dpbmcgcHJpb3JpdHkgb3JkZXIsIHdoZXJlIElDRSBjb3VsZCBiZSB1c2VkIHRvIHRyeSBz ZXZlcmFsOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xKSBUVVJOIHNlcnZlciBhZGRy ZXNzIGNvbmZpZ3VyZWQgaW4gdGhlIGJyb3dzZXIgYnkgdGhlIHVzZXIgKHNwZWNpYWwgY2FzZXMs IG5vcm1hbGx5IG5vdCB1c2VkKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+MikgVFVSTiBzZXJ2ZXIgYWRkcmVzcyBjb25maWd1cmVkIGJ5IHRoZSBuZXR3b3JrIGFkbWlu aXN0cmF0b3IgdmlhIGFuIOKAnGFkbWluIHBvbGljeSB0ZW1wbGF0ZeKAnTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MykgVFVSTiBzZXJ2ZXIgYWRkcmVzcyBzdXBwbGll ZCBieSBESENQIG9yIHNpbWlsYXIgYXV0b21hdGljIG5ldHdvcmsgbWV0aG9kPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij40KSBUVVJOIHNlcnZlciBhZGRyZXNzIGJlaW5n IHN1cHBsaWVkIGJ5IHRoZSB3ZWIgYXBwbGljYXRpb24mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPkFuZCBmcm9tIHllc3RlcmRheXMoISkNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0 Ij4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNl cy1hbmQtcmVxdWlyZW1lbnRzLTE0PC9hPiB0aGVzZSBlbnRlcnByaXNlIHRoaW5ncyBhbmQgbmVj ZXNzaXR5IGFyZSBzcGVsbGVkIG91dCBpbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkYxOSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUg YnJvd3NlciBtdXN0IGJlIGFibGUgdG8gdXNlIHNldmVyYWwgU1RVTiBhbmQgVFVSTiBzZXJ2ZXJz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5BMjI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpbmUtaGVpZ2h0LWFsdDowcHQ7 cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjxhIG5hbWU9InNlY3Rpb24tMy4zLjUiPjwvYT48 c3BhbiBsYW5nPSJTViI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNSI+ PGI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+My4zLjU8L3NwYW4+PC9iPjwvYT48L3NwYW4+PGI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LiZuYnNw Ow0KIFNpbXBsZSBWaWRlbyBDb21tdW5pY2F0aW9uIFNlcnZpY2UsIGVudGVycHJpc2UgYXNwZWN0 czxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp bmUtaGVpZ2h0LWFsdDowcHQ7cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjxhIG5hbWU9InNl Y3Rpb24tMy4zLjUuMSI+PC9hPjxzcGFuIGxhbmc9IlNWIj48YSBocmVmPSJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50 cy0xNCNzZWN0aW9uLTMuMy41LjEiPjxiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjMuMy41LjE8L3NwYW4+PC9i PjwvYT48L3NwYW4+PGI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+LiZuYnNwOw0KIERlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGlzIHVzZS1jYXNlIGlzIHNpbWlsYXIgdG8gdGhlIFNp bXBsZSBWaWRlbyBDb21tdW5pY2F0aW9uIFNlcnZpY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgdXNlLWNhc2UgKDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0I3NlY3Rpb24t My4zLjEiPlNlY3Rpb24gMy4zLjE8L2E+KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgV2hhdCBpcyBhZGRlZCBpcyBhc3Bl Y3RzIHdoZW4gdXNpbmcgdGhlIHNlcnZpY2UgaW4gZW50ZXJwcmlzZXMuJm5ic3A7IElDRTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBpcyBhc3N1bWVkIGluIHRoZSBmdXJ0aGVy IGRlc2NyaXB0aW9uIG9mIHRoaXMgdXNlLWNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEFuIGVudGVycHJpc2UgdGhh dCB1c2VzIGEgUlRDV0VCIGJhc2VkIHdlYiBhcHBsaWNhdGlvbiBmb3I8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgY29tbXVuaWNhdGlvbiBkZXNpcmVzIHRvIGF1ZGl0IGFsbCBS VENXRUIgYmFzZWQgYXBwbGljYXRpb24gc2Vzc2lvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgdXNlZCBmcm9tIGluc2lkZSB0aGUgY29tcGFueSB0b3dhcmRzIGFueSBleHRl cm5hbCBwZWVyLiZuYnNwOyBUbyBiZSBhYmxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IHRvIGRvIHRoaXMgdGhleSBkZXBsb3kgYSBUVVJOIHNlcnZlciB0aGF0IHN0cmFkZGxl cyB0aGUgYm91bmRhcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYmV0d2Vl biB0aGUgaW50ZXJuYWwgYW5kIHRoZSBleHRlcm5hbCBuZXR3b3JrLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGUgZmly ZXdhbGwgd2lsbCBibG9jayBhbGwgYXR0ZW1wdHMgdG8gdXNlIFNUVU4gd2l0aCBhbiBleHRlcm5h bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBkZXN0aW5hdGlvbiB1bmxlc3Mg dGhleSBnbyB0byB0aGUgZW50ZXJwcmlzZSBhdWRpdGluZyBUVVJOIHNlcnZlci48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgSW4gY2FzZXMgd2hlcmUgZW1wbG95ZWVzIGFyZSB1 c2luZyBSVENXRUIgYXBwbGljYXRpb25zIHByb3ZpZGVkIGJ5IGFuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IGV4dGVybmFsIHNlcnZpY2UgcHJvdmlkZXIgdGhleSBzdGlsbCB3 YW50IHRoZSB0cmFmZmljIHRvIHN0YXkgaW5zaWRlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IHRoZWlyIGludGVybmFsIG5ldHdvcmsgYW5kIGluIGFkZGl0aW9uIG5vdCBsb2Fk IHRoZSBzdHJhZGRsaW5nIFRVUk48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg c2VydmVyLCB0aHVzIHRoZXkgZGVwbG95IGEgU1RVTiBzZXJ2ZXIgYWxsb3dpbmcgdGhlIFJUQ1dF QiBjbGllbnQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZGV0ZXJtaW5l IGl0cyBzZXJ2ZXIgcmVmbGV4aXZlIGFkZHJlc3Mgb24gdGhlIGludGVybmFsIHNpZGUuJm5ic3A7 IFRodXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZW5hYmxpbmcgY2FzZXMg d2hlcmUgcGVlcnMgYXJlIGJvdGggb24gdGhlIGludGVybmFsIHNpZGUgdG8gY29ubmVjdDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB3aXRob3V0IHRoZSB0cmFmZmljIGxlYXZp bmcgdGhlIGludGVybmFsIG5ldHdvcmsuJm5ic3A7IEl0IG11c3QgYmU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgcG9zc2libGUgdG8gY29uZmlndXJlIHRoZSBicm93c2VycyB1 c2VkIGluIHRoZSBlbnRlcnByaXNlIHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgbmV0d29yayBzcGVjaWZpYyBTVFVOIGFuZCBUVVJOIHNlcnZlcnMuJm5ic3A7IFRoaXMg c2hvdWxkIGJlIHBvc3NpYmxlIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 YWNoaWV2ZSBieSBhdXRvLWNvbmZpZ3VyYXRpb24gbWV0aG9kcy4mbmJzcDsgVGhlIFJUQ1dFQiBm dW5jdGlvbmFsaXR5IHdpbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgbmVl ZCB0byB1dGlsaXplIGJvdGggbmV0d29yayBzcGVjaWZpYyBTVFVOIGFuZCBUVVJOIHJlc291cmNl cyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgU1RVTiBhbmQgVFVSTiBz ZXJ2ZXJzIHByb3Zpc2lvbmVkIGJ5IHRoZSB3ZWIgYXBwbGljYXRpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saW5lLWhlaWdodC1hbHQ6MHB0O3Bh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8YSBuYW1lPSJzZWN0aW9uLTMuMy41LjIiPjwvYT48 c3BhbiBsYW5nPSJTViI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNS4y Ij48Yj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4zLjMuNS4yPC9zcGFuPjwvYj48L2E+PC9zcGFuPjxiPjxzcGFu IGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPi4m bmJzcDsNCiBBZGRpdGlvbmFsIFJlcXVpcmVtZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNw OyBSRVEtSUQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgREVTQ1JJUFRJT048bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBGMjAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGJyb3dzZXIg bXVzdCBzdXBwb3J0IHRoZSB1c2Ugb2YgU1RVTiBhbmQgVFVSTjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBzZXJ2ZXJzIHRoYXQgYXJlIHN1cHBsaWVkIGJ5IGVudGl0aWVzIG90aGVyIHRoYW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHdlYiBhcHBsaWNhdGlvbiAoaS5lLiB0aGUg bmV0d29yayBwcm92aWRlcikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+VGhlcmUgYXJlIGZ1cnRoZXIgcmVxdWlyZW1lbnQgbGlzdGVkLCBoZWxwaW5nIHVzIHRv IHVuZGVyc3RhbmQgdGhlIG5lZWQgZm9yIGF1dG8gZGlzY292ZXJ5IGFuZCBhIG5ldHdvcmsgcHJv dmlkZWQgVFVSTi1zZXJ2ZXIgc2hvdWxkIGJlIHVzZWQgdG8gRU5GT1JDRSB0aGF0IG1lZGlhDQog dGFrZXMgdGhhdCBwYXRoIChhbmQgdGh1cywgb3RoZXIgcGF0aHMgZS5nLiBzdWdnZXN0ZWQgYnkg dGhlIHJlbW90ZSBNVVNUIG5vdCBoYXBwZW4gdG8gYmUgdXNlZCkuIFRoaXMgaXMgcmVsYXRlZCB0 byB0aGUgbW9iaWxpdHkgYXNwZWN0ICh2YWxpZCBldmVuIHdpdGhvdXQgdGhlIHJvYW1pbmcgaWRl YSk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGg0IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxhIG5hbWU9InNlY3Rpb24tMy4zLjYiPjwvYT48c3BhbiBsYW5nPSJTViI+PGEgaHJl Zj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2Vz LWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNiI+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+My4zLjY8L3NwYW4+PC9hPjwvc3Bh bj48c3BhbiBsYW5nPSJFTiI+LiZuYnNwOw0KIFNpbXBsZSBWaWRlbyBDb21tdW5pY2F0aW9uIFNl cnZpY2UsIGFjY2VzcyBjaGFuZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L2g0Pg0KPGg1IHN0eWxlPSJw YWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxhIG5hbWU9InNlY3Rpb24tMy4zLjYuMSI+PC9hPjxz cGFuIGxhbmc9IlNWIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xNCNzZWN0aW9uLTMuMy42LjEi PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUi PjMuMy42LjE8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+LiZuYnNwOw0KIERlc2Ny aXB0aW9uPG86cD48L286cD48L3NwYW4+PC9oNT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyBUaGlzIHVzZS1jYXNlIGlz IGFsbW9zdCBpZGVudGljYWwgdG8gdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJz cDsgU2ltcGxlIFZpZGVvIENvbW11bmljYXRpb24gU2VydmljZSB1c2UtY2FzZSAoPGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFu ZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuMSI+U2VjdGlvbiAzLjMuMTwvYT4pLiZuYnNw OyBUaGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyBkaWZmZXJlbmNlIGlzIHRo YXQgdGhlIHVzZXIgY2hhbmdlcyBuZXR3b3JrIGFjY2VzcyBkdXJpbmcgdGhlPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsgc2Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IFRoZSBjb21tdW5pY2F0aW9u IGRldmljZSB1c2VkIGJ5IG9uZSBvZiB0aGUgdXNlcnMgaGFzIHNldmVyYWwgbmV0d29yazxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IGFkYXB0ZXJzIChFdGhlcm5ldCwgV2lGaSwg Q2VsbHVsYXIpLiZuYnNwOyBUaGUgY29tbXVuaWNhdGlvbiBkZXZpY2UgaXM8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g bGFuZz0iRU4iPiZuYnNwOyZuYnNwOyBhY2Nlc3NpbmcgdGhlIEludGVybmV0IHVzaW5nIEV0aGVy bmV0LCBidXQgdGhlIHVzZXIgaGFzIHRvIHN0YXJ0IGE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZu YnNwOyZuYnNwOyB0cmlwIGR1cmluZyB0aGUgc2Vzc2lvbi4mbmJzcDsgVGhlIGNvbW11bmljYXRp b24gZGV2aWNlIGF1dG9tYXRpY2FsbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNw OyBjaGFuZ2VzIHRvIHVzZSBXaUZpIHdoZW4gdGhlIEV0aGVybmV0IGNhYmxlIGlzIHJlbW92ZWQg YW5kIHRoZW4gbW92ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyB0byBjZWxs dWxhciBhY2Nlc3MgdG8gdGhlIEludGVybmV0IHdoZW4gbW92aW5nIG91dCBvZiBXaUZpIGNvdmVy YWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IFRoZSBzZXNzaW9uIGNvbnRp bnVlcyBldmVuIHRob3VnaCB0aGUgYWNjZXNzIG1ldGhvZCBjaGFuZ2VzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPGg1IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxhIG5hbWU9 InNlY3Rpb24tMy4zLjYuMiI+PC9hPjxzcGFuIGxhbmc9IlNWIj48YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVt ZW50cy0xNCNzZWN0aW9uLTMuMy42LjIiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iY29sb3I6Ymxh Y2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjMuMy42LjI8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJFTiI+LiZuYnNwOw0KIEFkZGl0aW9uYWwgUmVxdWlyZW1lbnRzPG86cD48L286cD48L3Nw YW4+PC9oNT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFu Zz0iRU4iPiZuYnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsm bmJzcDsgUkVRLUlEJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERFU0NSSVBUSU9OPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5n PSJFTiI+Jm5ic3A7Jm5ic3A7IEYxNyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgY29tbXVu aWNhdGlvbiBzZXNzaW9uIG11c3Qgc3Vydml2ZSBhY3Jvc3MgYTxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJF TiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGNoYW5nZSBvZiB0aGUgbmV0d29yayBpbnRlcmZhY2UgdXNlZCBieSB0aGU8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBzZXNzaW9uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsm bmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGg0IHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxhIG5hbWU9InNlY3Rpb24tMy4zLjciPjwvYT48c3BhbiBsYW5n PSJTViI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3 ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNyI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+My4zLjc8L3Nw YW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTiI+LiZuYnNwOw0KIFNpbXBsZSBWaWRlbyBDb21t dW5pY2F0aW9uIFNlcnZpY2UsIFFvUzxvOnA+PC9vOnA+PC9zcGFuPjwvaDQ+DQo8aDUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PGEgbmFtZT0ic2VjdGlvbi0zLjMuNy4xIj48L2E+ PHNwYW4gbGFuZz0iU1YiPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0I3NlY3Rpb24tMy4zLjcu MSI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9u ZSI+My4zLjcuMTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOIj4uJm5ic3A7DQogRGVz Y3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L2g1Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IFRoaXMgdXNlLWNhc2Ug aXMgYWxtb3N0IGlkZW50aWNhbCB0byB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZu YnNwOyBTaW1wbGUgVmlkZW8gQ29tbXVuaWNhdGlvbiBTZXJ2aWNlLCBhY2Nlc3MgY2hhbmdlIHVz ZS1jYXNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsgKDxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVx dWlyZW1lbnRzLTE0I3NlY3Rpb24tMy4zLjYiPlNlY3Rpb24gMy4zLjY8L2E+KS4mbmJzcDsgVGhl IHVzZSBvZiBRdWFsaXR5IG9mIFNlcnZpY2UgKFFvUykgY2FwYWJpbGl0aWVzIGlzPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsgYWRkZWQ6PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyBUaGUgdXNlciBpbiB0aGUg cHJldmlvdXMgdXNlIGNhc2UgdGhhdCBzdGFydHMgYSB0cmlwIGlzIGJlaGluZCBhPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsgY29tbW9uIHJlc2lkZW50aWFsIHJvdXRlciB0aGF0 IHN1cHBvcnRzIHByaW9yaXRpemF0aW9uIG9mIHRyYWZmaWMuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVO Ij4mbmJzcDsmbmJzcDsgSW4gYWRkaXRpb24sIHRoZSB1c2VyJ3MgcHJvdmlkZXIgb2YgY2VsbHVs YXIgYWNjZXNzIGhhcyBRb1Mgc3VwcG9ydDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5i c3A7IGVuYWJsZWQuJm5ic3A7IFRoZSB1c2VyIGlzIGFibGUgdG8gdGFrZSBhZHZhbnRhZ2Ugb2Yg dGhlIFFvUyBzdXBwb3J0IGJvdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyB3 aGVuIGFjY2Vzc2luZyB2aWEgdGhlIHJlc2lkZW50aWFsIHJvdXRlciBhbmQgd2hlbiB1c2luZyBj ZWxsdWxhci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxoNSBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48YSBuYW1lPSJzZWN0aW9uLTMuMy43LjIiPjwvYT48c3BhbiBsYW5nPSJT ViI+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWIt dXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNy4yIj48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj4zLjMuNy4yPC9z cGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4iPi4mbmJzcDsNCiBBZGRpdGlvbmFsIFJlcXVp cmVtZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvaDU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IFJFUS1JRCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBERVNDUklQVElPTjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyBGMTcmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVGhlIGNvbW11bmljYXRpb24gc2Vzc2lvbiBtdXN0IHN1cnZpdmUgYWNyb3Nz IGE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjaGFuZ2Ugb2YgdGhlIG5ldHdvcmsgaW50ZXJm YWNlIHVzZWQgYnkgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2Vzc2lvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4i PiZuYnNwOyZuYnNwOyBGMjImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGJyb3dzZXIgbXVz dCBiZSBhYmxlIHRvIHJlY2VpdmUgc3RyZWFtcyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBkYXRhIGZyb20gbXVsdGlwbGUgcGVlcnMgY29uY3VycmVudGx5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5n PSJFTiI+Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5GdXJ0aGVyIGZyb20gdGhlIFJUQ1dFQiBtYWls aW5nIGxpc3QgU2VwdGVtYmVyIDIwPHN1cD50aDwvc3VwPiAoYnkgbWUpOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+VGhlcmUgYXJlIHNldmVyYWwgcmVhc29ucyBmb3IgYSBuZXR3b3JrIHNlcnZpY2Ug cHJvdmlkZXIgdG8gc3VwcGx5IGEgVFVSTiBzZXJ2ZXIgYXMgcGFydCBvZiBoaXMgb2ZmZXJlZCBh Y2Nlc3M6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4tIHRvIGtlZXAg bWVkaWEgcGF0aHMgc2hvcnQsIHNwZWNpZmljYWxseSBub3Qgc2VuZGluZyBtZWRpYSBvdXRzaWRl IGl0cyBvd24gbmV0d29yayB0byBzb21lIGRpc3RhbnQgYXBwbGljYXRpb24gcHJvdmlkZWQgVFVS TiBzZXJ2ZXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0gdG8gc3Vw cG9ydCBtb2JpbGl0eSwgaS5lLiB5b3UgbWF5IHdhbnQgdG8gbW92ZSBmcm9tIGEgTEFOIHdpdGgg YSBjb25maWd1cmVkIFRVUk4gc2VydmVyIHRvIGFjY2Vzc2luZyB2aWEgV2lGaSBvciAzRy80RyBP VFQgY2hhbm5lbHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0gdG8g b2ZmZXIgYSBtZWRpYSBwYXRoIHdpdGggYmV0dGVyIHF1YWxpdHkgKHRoYW4gYmVzdCBlZmZvcnQg ZGF0YSB0cmFmZmljKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkdl dHRpbmcg4oCcV2ViUlRDLXJlYWR54oCdIGFjY2VzcyBhbmQgd2UgbG9vayBmb3J3YXJkIHRvIHRl bGVwcmVzZW5jZSBmb3IgZXZlcnlvbmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JIGhvcGUg dGhpcyAoYSBiaXQgbGVuZ3RoeSkgc3VtbWFyeSBvZiBhbHJlYWR5IHRob3VnaHQtb3V0IGFuZCBk aXNjdXNzZWQgYXNwZWN0cy9yZXF1aXJlbWVudHMgd2lsbCBoZWxwIHVzIHVuZGVyc3RhbmQgdGhh dCB0aGUgYXV0by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVyIGlzIGFuDQogT1JERVIgZnJvbSB0aGUg ZW50ZXJwcmlzZSBhbmQvb3IgdGhlIE5TUC9JU1AgJm5ic3A7dG8gc2VuZCB0aGUgbWVkaWEgdGhy b3VnaCB0aGlzIFRVUk4gcGF0aCwgYW5kIHRoYXQgb3RoZXIgbWVkaWEgcGF0aHMgdGhhdCBtYXkg ZXhpc3QgTVVTVCBOT1QgQkUgVVNFRC4gKFRoYXQgaXMgd2h5IHdlIGVzcGVjaWFsbHkgaGF2ZSB0 byB3YXRjaC9hZHZpY2UgdGhhdCB3b3JrYWJsZSBtZWRpYSBwYXRocyBwcm9wb3NlZCBieSB0aGUg cmVtb3RlIHBhcnR5IG5vdCBiZWNvbWVzDQogdXNlZCDigJxieSBhY2NpZGVudOKAnS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+L0thcmw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5GcsOlbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGlydW1hbGVz d2FyIFJlZGR5ICh0aXJlZGR5KSBbPGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28uY29tIj5t YWlsdG86dGlyZWRkeUBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2tpY2thdDo8L2I+IGRlbiAx MyBmZWJydWFyaSAyMDE0IDA0OjM3PGJyPg0KPGI+VGlsbDo8L2I+IEh1dHRvbiwgQW5kcmV3OyBK dXN0aW4gVWJlcnRpOyBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKTxicj4NCjxi PktvcGlhOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbSI+dGlyZWRkeUBp Y2lzY28uY29tPC9hPjsgU2ltb24gUGVycmVhdWx0OyBPbGVnIE1vc2thbGVua287DQo8YSBocmVm PSJtYWlsdG86dHJhbUBpZXRmLm9yZyI+dHJhbUBpZXRmLm9yZzwvYT47IE1hcmMgQmxhbmNoZXQ7 IERhbiBXaW5nIChkd2luZyk7IEthcmwgU3RhaGw8YnI+DQo8Yj7DhG1uZTo8L2I+IFJFOiBbdHJh bV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3Ig ZW50ZXJwcmlzZSBhbmQgSVNQczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBB bmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIG90aGVyIHdheXMgdG8gc29sdmUgdGhlIHByb2JsZW0g Zm9yIGV4YW1wbGUgdXNpbmcgUENQLiBDYW4geW91IGNsYXJpZnkgaG93IGRlcGxveWluZyBhIFRV Uk4gc2VydmVyIGluIHRoZSBFbnRlcnByaXNlIHByb3RlY3RzIHRoZSB1c2VycyBhbmQgdGhlIG5l dHdvcmsNCiA/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBbPGEgaHJlZj0ibWFpbHRv OnRyYW0tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZzwvYT5d DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkh1dHRvbiwgQW5kcmV3PGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCAxOjAwIEFNPGJyPg0KPGI+VG86PC9iPiBKdXN0aW4g VWJlcnRpOyBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKTxicj4NCjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbSI+dGlyZWRkeUBpY2lzY28uY29t PC9hPjsgU2ltb24gUGVycmVhdWx0OyBPbGVnIE1vc2thbGVua287DQo8YSBocmVmPSJtYWlsdG86 dHJhbUBpZXRmLm9yZyI+dHJhbUBpZXRmLm9yZzwvYT47IE1hcmMgQmxhbmNoZXQ7IERhbiBXaW5n IChkd2luZyk7IEthcmwgU3RhaGw8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBNaWxl c3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnBy aXNlIGFuZCBJU1BzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBjYXNlIHdo ZXJlIHRoZSBUVVJOIHNlcnZlciBpcyB0aGUgb25seSBvcHRpb24gbWF5IGJlY29tZSBjb21tb24g d2l0aGluIGVudGVycHJpc2UgbmV0d29ya3MgYW5kIHRoYXQgbWlnaHQgYmUgZGVsaWJlcmF0ZSBl bnRlcnByaXNlIHBvbGljeSBiZWNhdXNlIGl0IHByb3ZpZGVzDQogdGhlIGJldHRlciBwYXRoIChV RFAgdGhyb3VnaCB0aGUgRi9XKSBhbmQgcHJvdGVjdHMgdGhlIHVzZXJzIGFuZCB0aGUgbmV0d29y ay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRyYW0gWzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxi cj4NCjxiPlNlbnQ6PC9iPiAxMiBGZWJydWFyeSAyMDE0IDE3OjQ2PGJyPg0KPGI+VG86PC9iPiBN dXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKTxicj4NCjxiPkNjOjwvYj4gPC9zcGFu PjxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij50aXJlZGR5QGljaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij47IFNpbW9uIFBlcnJlYXVsdDsgT2xlZyBNb3NrYWxlbmtvOw0KPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJh bUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgTWFyYyBC bGFuY2hldDsgRGFuIFdpbmcgKGR3aW5nKTsgS2FybCBTdGFobDxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNo YW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWUuIElmIFRVUk4gaXMgaW5kZWVkIGJlaW5n IHByb3ZpZGVkIGZvciB0aGUgdXNlcidzIGJlbmVmaXQsIHRoZSBjbGllbnQncyBJQ0UgbG9naWMg KGJhc2VkIG9uIFJUVCBvciBzaW1pbGFyKSBzaG91bGQgcmVzdWx0IGluIGl0IHByZWZlcnJpbmcg dGhlIFRVUk4gcGF0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgMTIsIDIwMTQgYXQg MToyNyBBTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgJmx0OzxhIGhyZWY9 Im1haWx0bzptcGVydW1hbEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tcGVydW1hbEBjaXNj by5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+WWVzLCBJIGJlbGlldmUgdGhlIHNlY29uZCBjYXNl IGlzIHJhcmUsIGJ1dCB3b3VsZCBiZSBiZXR0ZXIgdGhhbiBhIHJhdCByYWNlIGIvdyBhZG1pbmlz dHJhdG9ycyB0cnlpbmcgdG8gYmxvY2sgcDJwIHRyYWZmaWMNCiBhbmQgZm9yY2UgaXQgdGhyb3Vn aCBhIFRVUk4gc2VydmVyIGFuZCBhcHBzL2VuZHBvaW50cyBmaW5kaW5nIHNtYXJ0ZXIgd2F5cyB0 byBieXBhc3MgdGhlbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NdXRodTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT2xlZyBNb3NrYWxlbmtv IFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptb20wNDAyNjdAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1vbTA0MDI2N0BnbWFpbC5j b208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAxNCAxOjA3IFBNPGJyPg0KPGI+VG86PC9i PiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKTxicj4NCjxiPkNjOjwvYj4gSnVz dGluIFViZXJ0aTsgS2FybCBTdGFobDsgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGlj aXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dGly ZWRkeUBpY2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ow0K IE1hcmMgQmxhbmNoZXQ7IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBEYW4gV2luZyAoZHdpbmcpOyBT aW1vbiBQZXJyZWF1bHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1dIE1pbGVzdG9u ZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2Ug YW5kIElTUHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIFRVUk4gc2VydmVyIGhhcyB0byBi ZSB1c2VkIHdoZW4gaXQgaXMgZWl0aGVyIHRoZSBvbmx5IG9wdGlvbiwgb3IgaWYgaXQgcHJvdmlk ZXMgYSBiZXR0ZXIgcGF0aCAoSSBndWVzcyB0aGUgc2Vjb25kIGNhc2UgaXMgcmF0aGVyIHJhcmUp LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZlYiAxMSwgMjAx NCBhdCAxMTozMiBQTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgJmx0Ozxh IGhyZWY9Im1haWx0bzptcGVydW1hbEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tcGVydW1h bEBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0MzsxPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Rm9yY2luZyBhbGwg dHJhZmZpYyB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgYW5kIGV4cGVjdGluZyBpdCB3b3VsZCBwcm92 aWRlIHRoZSBiZXN0IHVzZXIgZXhwZXJpZW5jZSBkb2Vzbid0IGxvb2sgdGhlIHJpZ2h0DQogYXBw cm9hY2guIEluc3RlYWQsIGlmIGEgcGF0aCB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgZXhpc3RzIGFu ZCBkb2VzIHByb3ZpZGUgbG93ZXIgUlRULCBqaXR0ZXIgZXRjLCBiZWluZyBhYmxlIHRvIGRldGVj dCBhbmQgdXNlIChvciBzd2l0Y2ggdG8pIHRoYXQgcGF0aCBtaWdodCBiZSBkZXNpcmFibGUuLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPk11dGh1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0cmFtIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+dHJhbS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQgMTE6NDMgQU08YnI+ DQo8Yj5Ubzo8L2I+IEthcmwgU3RhaGw8YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48YSBocmVmPSJt YWlsdG86dGlyZWRkeUBpY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPnRpcmVkZHlAaWNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjsgTWFyYyBCbGFuY2hldDsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJh bUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50 cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBEYW4g V2luZyAoZHdpbmcpOyBTaW1vbiBQZXJyZWF1bHQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0 cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZv ciBlbnRlcnByaXNlIGFuZCBJU1BzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklubGluZS48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBGZWIgMTEsIDIwMTQgYXQgMjoz NyBQTSwgS2FybCBTdGFobCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthcmwuc3RhaGxAaW50ZXJ0ZXgu c2UiIHRhcmdldD0iX2JsYW5rIj5rYXJsLnN0YWhsQGludGVydGV4LnNlPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5MaXN0ZW5pbmcgdG8gdGhpcyB0aHJl YWQsIEkgYW0gYWZyYWlkIHdlIGFyZSBtaXNzaW5nIHRoZSB2ZXJ5IHBvaW50IGFuZCBuZWNlc3Np dHkgZm9yIHRoaXMgbWlsZXN0b25lITwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIFRoZXJl IGFyZSBzZXZlcmUgTkFUIHRyYXZlcnNhbCBhbmQgcXVhbGl0eSBpc3N1ZXMgdGhhdCBzaG91bGQg YW5kIGNhbiBiZSBkZWFsdCB3aXRoIGJ5IGEgZ29vZCBhdXRvLWRpc2NvdmVyeQ0KIG1lY2hhbmlz bSBhbmQgdGhlIHJpZ2h0IHVzYWdlIGJ5IHRoZSB0dXJuIGNsaWVudCAodGhlIFdlYlJUQyBicm93 c2VyKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6Ymx1ZSI+VGhlcmUgYXJlIHdheXMsIG5vdCBvbmx5Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5FbnRl cnByaXNlcyBvciBJU1BzIHdpc2hpbmcgdG8gcHJvdmlkZSB0aGVpciBvd24gVFVSTiBzZXJ2ZXIs IGluIGFuIGF0dGVtcHQgdG8gcmVkdWNlIHNvLWNhbGxlZCAmcXVvdDt0cmlhbmdsZSByb3V0aW5n JnF1b3Q7LG5lZWQgYSBuZXcgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPkJ1dCBhbHNvOiAtIE5TUHMgKE5ldHdvcmsgU2VydmljZSBQcm92aWRlcnMp IHdhbnQgdG8gcHJvdmlkZSBhIHBhdGggd2hlcmUgdGhlIGJhbmR3aWR0aCBvZiBXZWJSVEMgaXMg YmV0dGVyDQogY29wZWQgd2l0aC48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0g TlNQcyBvciBFbnRlcnByaXNlcyB3YW50IHRvIG9mZmVyIGFuIEludGVybmV0IGFjY2VzcyBxdWFs aXR5IHBpcGUgZm9yIHByaW9yaXRpemVkIFJUQyAoUmVhbCBUaW1lIENvbW11bmljYXRpb24pDQog dHJhZmZpYy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0gRW50ZXJwcmlzZXMgaGF2aW5n IHJlc3RyaWN0aXZlIGZpcmV3YWxscywgd2FudCB0byBwcm92aWRlIGEgVURQLXBhdGggZm9yIFdl YlJUQyBhbmQgcG9zc2libHkgYWxzbyBmb3INCiBiZXR0ZXIgcXVhbGl0eSB3aGVyZSBSVEMgZG8g bm90IGNvbXBldGUgd2l0aCBkYXRhIHRyYWZmaWMuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPkFsc28gY29uc2lkZXJpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPi0gTW9iaWxpdHk7IEl0IGlzIGNvbW1vbiB0byBtb3ZlIGZyb20gYSBMQU4gdG8gYWNjZXNz aW5nIHZpYSBXaUZpIG9yIDNHLzRHIE9UVCBjaGFubmVscywgYWxsIHNob3VsZCBiZQ0KIGFibGUg dG8gYXV0b21hdGljYWxseSBvZmZlciB0aGVpciBvd24gb3B0aW1hbCBUVVJOIHNlcnZlcjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj5UaGlzIGxlYWRzIHVzIGludG8NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDvigJxUVVJO4oCmdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dz4oCdDQo8c3Bh biBzdHlsZT0iY29sb3I6Ymx1ZSI+ZXRjISBJdCBpcyBub3QgYSBtaXN0YWtlLCBidXQgdGhlIHZl cnkgbmVlZCBmb3IgdGhpcyBtaWxlc3RvbmUhPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWdhaW4s IGl0IGhhcyBub3QgYmVlbiBkZW1vbnN0cmF0ZWQgd2h5IFRVUk4gaXMgdGhlIHJpZ2h0IHRlY2hu b2xvZ3kgaGVyZSwgY29tcGFyZWQgdG8gYSBtb3JlIHRyYW5zcGFyZW50IGZsb3cgaWRlbnRpZmlj YXRpb24gdG9vbCBsaWtlIE1BTElDRS4gV2UgZG9uJ3QgZm9yY2UgYWxsIEhUVFAgcmVxdWVzdHMN CiB0byBsb2NhdGUgYSBIVFRQIHByb3h5IHZpYSBhbnljYXN0LCBJIGRvbid0IHNlZSB3aHkgd2Ug bmVlZCB0byBkbyB0aGUgc2FtZSBmb3IgV2ViUlRDLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5XaGF0IGFy ZSB0aGUgaGVzaXRhdGlvbnMgcmFpc2VkIGhlcmU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jmd0OyBUVVJOIHByaW1hcmlseSB0byBpZGVudGlmeSBXZWJSVEMgZmxvd3MsIGFzIG9wcG9zZWQg dG8gdXNpbmcgaXQgYXMgYSBOQVQgdHJhdmVyc2FsIHRvb2wuIFRoaXMgbWFrZXMgbWUgY29uY2Vy bmVkDQogdGhhdCB3ZSBtYXkgYmUgdXNpbmcgdGhlIHdyb25nIHRlY2hub2xvZ3kgdG8gc29sdmUg dGhlIHByb2JsZW08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JdCBpcyBjb3Jy ZWN0IHRoYXQgSUNFL1NUVU4vVFVSTiB3YXMgZGVzaWduZWQgdG8gYWRkcmVzcyB0aGUgTkFUL0Zp cmV3YWxsIHRyYXZlcnNhbCBwcm9ibGVtIGFzc29jaWF0ZWQNCiB3aXRoIHJlYWwtdGltZSBjb21t dW5pY2F0aW9uIChTSVAgYXQgdGhhdCB0aW1lKS4gSG93ZXZlciwgaXRzIGxhcmdlc3QgZmxhdy9w cm9ibGVtIGlzIHRoYXQgcXVhbGl0eSB0aGluZ3Mgd2VyZSBub3QgKGNvdWxkIG5vdCBiZT8pIGNv bnNpZGVyZWQuIFRoZSBtZXRob2TigJlzIHZlcnkgaWRlYSAobGlrZSBhbGwgc2ltaWxhciBtZXRo b2RzIGZvciBnZXR0aW5nIFJUQyB0aHJvdWdoIG9yZGluYXJ5IE5BVC9GaXJld2FsbHMpIGlzIHRv IGZvb2wgdGhlIG1lZGlhDQogdGhyb3VnaCBhIE5BVC9GaXJld2FsbCB0aGF0IGlzIHVuYXdhcmUg b2Ygd2hhdCBpcyBoYXBwZW5pbmcuIFRodXMsIHRoaXMgaXMgcm9vdCBvZiBxdWFsaXR5IGlzc3Vl cyAoYW5kIGJhbmR3aWR0aCBhbGxvY2F0aW9uIG9wdGltaXphdGlvbikgdGhhdCBuZWVkcyB0byBi ZSBkZWFsdCB3aXRoOiBSZWFsLXRpbWUgdHJhZmZpYyBmaWdodGluZyB3aXRoIGEgZGF0YSB0cmFm ZmljIGNyb3dkZWQgY29uZ2VzdGlvbiBwb2ludC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkkgdGhpbmsgdGhhdCAmcXVvdDtmb29saW5nJnF1b3Q7IGlzIGFuIGluY29ycmVjdCBkZXNj cmlwdGlvbi4gVGhlIE5BVCBpcyBzdXBwb3NlZCB0byBiZSB0cmFuc3BhcmVudCB0byB0aGUgY2xp ZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibHVlIj5CdXQsIGEgQkxFU1NJTkcgb2YgSUNFL1NUVU4vVFVSTiBpcyB0aGF0 IGl0IGNhbiBiZSBzZWVuIGFzIGEgbGVnaXRpbWF0ZSByZXF1ZXN0IGZvciBhIHN1aXRhYmxlIHBp cGUgZm9yDQogcXVhbGl0eSBkZW1hbmRpbmcgcmVhbCB0aW1lIHRyYWZmaWMuIDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6Ymx1 ZSI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPklDRSBpcyBhIHByZS1wcm90b2NvbCB5b3UgdXNlIGJlY2F1 c2UgeW91IHdhbnQgYSBwYXRoIGZvciByZWFsLXRpbWUgbWVkaWEgYmV0d2VlbiBwYXJ0aWVzLiBI ZXJlOiBUaGUgYnJvd3Nlcg0KIHNheXMga25vY2sga25vY2ssIEkgd2FudCB0byBnZXQgbWVkaWEg dGhyb3VnaCAoYW5kIG9mIGNvdXJzZSB3aXRoIGFzIGdvb2QgcXVhbGl0eSBhcyByZXF1aXJlZCBh bmQgcG9zc2libGUpLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibHVlIj5JZiB0aGUgTkFUL0ZpcmV3YWxsIG93bmVyIGFuZCBuZXR3b3Jr IG93bmVyIGFyZSBhbGxvd2VkIHRvIHNlZSB0aGVzZSByZXF1ZXN0cywgdGhleSBjYW4gaGVscC9h c3Npc3QgaW4NCiBhY2hpZXZpbmcgdGhlIGdvb2QgbWVkaWEgcGF0aC4gSWYgdGhleSBhcmUgbm90 IGF3YXJlLCB0aGV5IGNhbm5vdCBoZWxwITwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj5Ib3BlIHRoaXMgbWFkZSBpdCB1bmRlcnN0YW5kYWJsZSBvbiBhbiBvdmVydmll dyBsZXZlbCBob3cgdGhpcyBjYW4gYmVjb21lPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPg0KIOKAnFRVUk7igKZ0byBpZGVudGlmeSBXZWJSVEMgZmxvd3PigJ08L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+SXQgaXMgYWxzbyB0aGUgT05MWSB3YXkgSSBjYW4gc2VlIHRvIGFj aGlldmUgd2hhdCB3ZSB3YW50IHRvIGFjaGlldmUgYW5kIHNob3VsZCBiZSB0aGUgYWltIGFuZCBy ZXF1aXJlbWVudA0KIG9mIHRoaXMgbWlsZXN0b25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVl Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SSBhbSB0YWxraW5nIGFib3V0IGdl bmVyYWwgdXNhZ2Ugb2YgV2ViUlRDIG92ZXIgSW50ZXJuZXQvbW9iaWxlIE9UVCAobm90IGZlZWRp bmcgV2ViUlRDIGludG8gYXBwbGljYXRpb24NCiBzcGVjaWZpYyBuZXR3b3JrcyBsaWtlIElNUyB3 aGVyZSBvdGhlciBtZXRob2RzIG1heSBleGlzdCkuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVl Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhpcyBpcyBnb29kLCBub3QgZXZp bCE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPklmIHRoZSBoZXNpdGF0aW9ucyBhcmUgcmFpc2VkIGJlY2F1c2Ugb2YgYSBiZWxpZWYv aG9wZS93aXNoIHRoYXQgdGhlcmUgYXJlIG5vIG9yIHdpbGwgbm90IGJlIHNldmVyZSBxdWFsaXR5 DQogaXNzdWVzIOKAnGJlY2F1c2UgaXQgaXMgYWxsIGFib3V0IGJhbmR3aWR0aOKAnSwg4oCcaXQg d2lsbCByZXNvbHZlIGl0c2VsZiB3aXRoIHRpbWXigJ0gZXRjLiwgSSBzdHJvbmdseSBvYmplY3Qh IFRoYXQgaXMgd3JvbmcgYW5kIHdpbGwgYmUgdmVyeSBkZXRyaW1lbnRhbCBmb3IgV2ViUlRDIHVz YWdlLiBXZSBhbHJlYWR5IHNlZSBpdCBhbmQgSSBjYW4gZ2l2ZSBudW1lcm91cyBleGFtcGxlcyBv ZiBob3cgbXVjaCBsZXNzIHF1YWxpdHkgZGVtYW5kaW5nIFZvSVANCiBpcy9pcyBub3QgaGFuZGxl ZCBxdWFsaXR5IHdpc2UgYW5kIHRoYXQgaXQgbWF0dGVycy4gQW5kLCB3aGF0IHdvdWxkIGJlIGJh ZCBjb25zaWRlcmluZyBxdWFsaXR5IGlzc3VlcyBhbmQgYWxsb3dpbmcvZW5jb3VyYWdpbmcgbWV0 aG9kcyB0byBkZWFsIHdpdGggdGhlbT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6Ymx1ZSI+SWYgdGhlIGhlc2l0YXRpb25zIGFyZSByYWlzZWQsIGJlY2F1c2Ugb2Ygc3VzcGlj aW9uIHRoYXQgdGhlIG1ldGhvZHMgd2UgbWF5IHJlY29tbWVuZCBtYXkgYmUgbWlzdXNlZCB0bw0K IHN0b3AvYmxvY2svZGVzdHJveSBXZWJSVEMgdXNhZ2UgKGUuZy4gdG8gcHJvdGVjdCBpbmNvbWUg ZnJvbSBjYXJyaWVyIHRlbGVwaG9ueSB0cmFmZmljKSwgSSBjb3VsZCB1bmRlcnN0YW5kIGFuZCB3 b3VsZCBmaWdodCB0aGUgc2FtZSBiYXR0bGUuIEJ1dCBob3BlZnVsbHksIHRob3NlIGRheXMgYXJl IChzb29uKSBvdmVyIOKAkyBBdCBsZWFzdCBmb3J3YXJkIHRoaW5raW5nIGNhcnJpZXLigJlzIHJl YWxpemUgdGhhdCBhbHJlYWR5LiBXZWIgUlRDIHdpbGwNCiBoYXBwZW4uIFdoaWNoIGN1c3RvbWVy cyB3YW50IHRvIHBheSBmb3IgYW4gYWNjZXNzIHdpdGggYmxvY2tlZCBXZWJSVEM/IFRoZSBjYXJy aWVy4oCZcyBvZmZlcmluZy9hc3N1cmluZyBnb29kIFdlYlJUQyB3aWxsIHJhdGhlciBnZXQgdGhl IGN1c3RvbWVycyBhbmQgaW5jb21lDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOmJsdWUiPko8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4uIChNYXliZSB0aGUgV2ViIGJyb3dzZXIgY2FuIGRl dGVjdCBhbmQgZW5jb3VyYWdlIHRoaXPigKYpPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SWYgdGhlcmUgYXJlIHRl Y2huaWNhbCBjb25jZXJucyBvZiBiYWQgcmVzdWx0LCBvciBiZXR0ZXIgbWV0aG9kcyBhbGxvd2lu ZyBuZXR3b3JrIHByb3ZpZGVycyBhbmQgTEFOIG1hbmFnZXJzDQogdG8gb2ZmZXIgYW5kIGluZm9y bSB0aGUgYnJvd3NlciB0aGF0IHRoZXJlIGFyZSBnb29kIG1lZGlhIHBhdGhzIHRvIGJlIHVzZWQs IGFuZCB0aGF0IHRoZSB3ZWIgYnJvd3NlciBhdXRvbWF0aWNhbGx5IGNhbiBjaG9zZSB0aG9zZSwg dGhlbiBsZXQgdXMgYWxsIHVuZGVyc3RhbmQgdGhvc2UsIHNvIHdlIGNhbiBhY2hpZXZlIHdoYXQg c2hvdWxkIGJlIGFjaGlldmVkIGJ5IHRoaXMgbWlsZXN0b25lLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+U2t5cGUsIEhhbmdvdXRzLCBGYWNldGltZSBhcmUgZG9pbmcgYmlsbGlvbnMg b2YgbWludXRlcyBwZXIgd2VlayBhbmQgdGhlIEludGVybmV0IGhhcyBub3QgbWVsdGVkIHlldC4g SWYgd2UgbmVlZCB0byBkbyBmbG93IGlkZW50aWZpY2F0aW9uIHRvIGFsbG93IHRyYWZmaWMgdG8g YmUgcHJpb3JpdGl6ZWQsIGZpbmUNCiAoc2VlIGFib3ZlIHJlZ2FyZGluZyBteSBwcmVmZXJyZWQg YXBwcm9hY2gpLCBidXQgZm9yY2luZyBhbGwgV2ViUlRDIHRyYWZmaWMgdGhyb3VnaCBhIE1JVE0g KFRVUk4gc2VydmVyKSBpcyBhIG11Y2ggYmlnZ2VyIGp1bXAgdGhhdCBJIGRvbid0IHlldCBzZWUg dGhlIGp1c3RpZmljYXRpb24gZm9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gc2hvcnQ6IFRVUk4gaXMgYSB0ZWNobm9sb2d5IHRo YXQgaXMgc3VwcG9zZWQgdG8gZmFkZSBhd2F5IHdpdGggdGhlIG1vdmUgdG8gSVB2Ni4gSSBkb24n dCB0aGluayB3ZSB3YW50IHRvIG1ha2UgaXQgYSBjcml0aWNhbCBlbGVtZW50IG9mIFdlYlJUQy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Ymx1ZSI+L0thcmw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5GcsOlbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gRGFuIFdpbmcgW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmR3 aW5nQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5kd2luZ0BjaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5d DQo8YnI+DQo8Yj5Ta2lja2F0OjwvYj4gZGVuIDExIGZlYnJ1YXJpIDIwMTQgMTg6MjU8YnI+DQo8 Yj5UaWxsOjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ TWFyYyBCbGFuY2hldDxicj4NCjxiPktvcGlhOjwvYj4gSnVzdGluIFViZXJ0aTsgPC9zcGFuPjxh IGhyZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRpcmVkZHlAaWNpc2NvLmNvbTwvc3Bhbj48 L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47DQogS2FybCBTdGFobDsg PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwv YT48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgU2ltb24gUGVycmVhdWx0 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IlNWIj48YnI+DQo8Yj7DhG1uZTo8L2I+IFJlOiBbdHJhbV0gTWlsZXN0 b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlz ZSBhbmQgSVNQczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPk9uIEZlYiAxMSwgMjAx NCwgYXQgOTowOCBBTSwgTWFyYyBCbGFuY2hldCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpt YXJjLmJsYW5jaGV0QHZpYWdlbmllLmNhIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1Yi Pm1hcmMuYmxhbmNoZXRAdmlhZ2VuaWUuY2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIj4mZ3Q7 DQogd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQi PjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+TGUgMjAxNC0wMi0xMSDDoCAwMDoz OSwgRGFuIFdpbmcgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHdpbmdAY2lzY28uY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiPmR3aW5nQGNpc2NvLmNvbTwvc3Bhbj48L2E+ PHNwYW4gbGFuZz0iU1YiPiZndDsgYSDDqWNyaXQgOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCk9uIEZlYiAxMCwgMjAxNCwgYXQg NTozMCBQTSwgSnVzdGluIFViZXJ0aSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpqdWJlcnRp QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+anViZXJ0aUBnb29nbGUuY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0Ow0KIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkdvb2QgdG8gc2VlIHRoZXJlIGlzIGEgbG90 IG9mIGludGVyZXN0IGZvciB0aGlzIG1pbGVzdG9uZS4gQnV0IGJhc2VkIG9uIHRoZSBkZXNjcmlw dGlvbiBoZXJlLCBpdCBzZWVtcw0KIGxpa2Ugd2Ugd2FudCB0byB1c2UgVFVSTiBwcmltYXJpbHkg dG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dzLCBhcyBvcHBvc2VkIHRvIHVzaW5nIGl0IGFzIGEgTkFU IHRyYXZlcnNhbCB0b29sLiBUaGlzIG1ha2VzIG1lIGNvbmNlcm5lZCB0aGF0IHdlIG1heSBiZSB1 c2luZyB0aGUgd3JvbmcgdGVjaG5vbG9neSB0byBzb2x2ZSB0aGUgcHJvYmxlbS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mIzQzOzEuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+SSB3b3VsZCBwcmVmZXIgYWxsb3dpbmcgZmxvd3MgdG8gZXN0YWJs aXNoIHRoZW1zZWx2ZXMgdXNpbmcgdGhlaXIgJ2Jlc3QnIHBhdGgsIGFuZCB0aGUgYmVzdCBwYXRo IGlzDQogc2VsZG9tIHRocm91Z2ggYSBUVVJOIHNlcnZlci4gJm5ic3A7V2hlbiB3ZSBpbWFnaW5l IElQdjYgaW4gb3VyIGZ1dHVyZSwgd2UgZG9uJ3Qgd2FudCB0byBmb3JjZSBhbiBhcHBsaWNhdGlv bi1sZXZlbCBwcm94eSAoVFVSTikgc2VydmVyIG9uIHRoZSBwYXRoIHNvbGVseSBmb3IgdHJhdmVy c2luZyBhbiBJUHY2IGZpcmV3YWxsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkl0 IHNlZW1zIHRoaXMgdGhyZWFkIGlzIGNvbmZsYXRpbmcgYWxsIHRoZSBwb3NzaWJsZSByZWFzb25z IC8ganVzdGlmaWNhdGlvbnMgZm9yIFRVUk46PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7ICogbW9iaWxpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgKiBOQVQgdHJhdmVyc2FsIChib3RoIGVuZHBvaW50 cyBhcmUgYmVoaW5kIGVuZHBvaW50LWRlcGVuZGVudCBtYXBwaW5nIE5BVHMpPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICombmJzcDtmaXJld2FsbCB0 cmF2ZXJzYWwgKGZpcmV3YWxsIGJsb2NrcyBVRFApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICogZW5oYW5jaW5nIHByaXZhY3k8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5VbmZvcnR1bmF0ZWx5IHRoZSBUVVJOIHNlcnZlciBu b3IgdGhlIGVuZHBvaW50IHJlYWxseSBrbm93IHdoaWNoIG9mIHRob3NlIHVzZS1jYXNlcyBpcyBk ZXNpcmVkIChieSB0aGUNCiB1c2VyIG9yIGJ5IHRoZSBJVCBuZXR3b3JrIGFkbWluaXN0cmF0b3Ip IG9yIG5lY2Vzc2FyeSAoZm9yIHRoZSBjYWxsIHRvIHdvcmsgYXQgYWxsKS4NCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+RGFuLCB3aGlsZSBJ IGFncmVlIGluIHByaW5jaXBsZSwgSSBkb3VidCB0aGF0IGEgdXNlciBjb3VsZCBldmVyIHNheSAm cXVvdDtJIHdhbnQgbW9iaWxpdHkgb3IgSSB3YW50IE5BVCB0cmF2ZXJzYWwmcXVvdDsuIEkgdGhp bmsgdGhlIHVzZXIgb25seSB3YW50IHRoZSBjYWxsIHRvIHN1Y2NlZWQsIHdoYXRldmVyDQogdGhl IHByb3BlcnRpZXMgb2YgaXRzIG5ldHdvcmsgcG9pbnQgb2YgYXR0YWNobWVudCBhcmUuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1Yi PlNvIHdoYXQgY2FuIHdlIGRvPyAmbmJzcDtTaG91bGQgdGhlIFRVUk4gc2VydmVyIHByb3ZpZGUg YW55IGFuZCBhbGwgc2VydmljZXMgdGhlIFRVUk4gY2xpZW50IG1pZ2h0IHBvc3NpYmx5IHdhbnQs IGFzIHRoYXQgaXMgd2hhdCBhIHJvYnVzdCBUVVJOIHNlcnZlciB3aWxsIGRvLCBhbmQgdGhlDQog ZW5kcG9pbnQgc2hvdWxkIHByZWZlciBUVVJOIGNhbmRpZGF0ZXMgb3ZlciBhbGwgb3RoZXJzIGJl Y2F1c2UgdGhlcmUgbWlnaHQgYmUgc29tZSBmdW5jdGlvbmFsaXR5IC8gdXNlZnVsbmVzcyBvZiBU VVJOIHRoYXQgdGhlIHVzZXIgbWlnaHQgZ2FpbiB0aHJvdWdoIFRVUk4gKGUuZy4sIGVuaGFuY2Vk IHByaXZhY3kpPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1Yi Pi1kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDtUaGlzIHNlZW1zIHByb2JsZW1hdGljLiAmbmJzcDtQZXJo YXBzIHdlIG5lZWQgYSB3YXkgdG8gc2lnbmFsIHRoZSBkZXNpcmVkIHVzZS1jYXNlICgmcXVvdDt0 cmFpdCZxdW90OyksIG9yIGFzIEp1c3Rpbg0KIHN1Z2dlc3RzLCB1c2luZyBhIGRpZmZlcmVudCB0 ZWNobm9sb2d5IGZvciBzb21lIG9mIHRoZXNlIHVzZS1jYXNlcy48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4tZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBNb24sIEZlYiAxMCwg MjAxNCBhdCAzOjE4IFBNLCBLYXJsIFN0YWhsJm5ic3A7Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86a2FybC5zdGFobEBpbnRlcnRleC5zZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5rYXJsLnN0YWhsQGludGVydGV4LnNlPC9zcGFuPjwv YT48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyZuYnNwO3dyb3Rl Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNpbW9uLDxicj4NCjxicj4NCkdvb2QgcXVl c3Rpb25zIC0gc2VlIGlubGluZSBiZWxvdyAtLSZndDsgLjxicj4NClNvbWUgbW9yZSB0aG91Z2h0 IGlzIHJlcXVpcmVkITxicj4NCjxicj4NCi9LYXJsPGJyPg0KPGJyPg0KLS0tLS1VcnNwcnVuZ2xp Z3QgbWVkZGVsYW5kZS0tLS0tPGJyPg0KRnLDpW46IHRyYW0gW21haWx0bzo8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxh bmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtLWJvdW5jZXNAaWV0Zi5vcmc8L3Nw YW4+PC9hPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQogRsO2ciBT aW1vbiBQZXJyZWF1bHQ8YnI+DQpTa2lja2F0OiBkZW4gMTAgZmVicnVhcmkgMjAxNCAxNToxNjxi cj4NClRpbGw6IEthcmwgU3RhaGw7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij47Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGljaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+dGlyZWRkeUBpY2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0Kw4RtbmU6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRV Uk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQ czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxh bmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpLYXJsLDxicj4NCjxicj4NCkl0 IGlzIGdyZWF0IHRvIHNlZSBzdWNoIGVudGh1c2lhc20hIFRoYW5rcyE8YnI+DQo8YnI+DQpJIGhh dmUgYSBjb3VwbGUgdGVjaG5pY2FsIHF1ZXN0aW9ucy4uLjxicj4NCjxicj4NCkxlIDIwMTQtMDIt MDggMDg6MTEsIEthcmwgU3RhaGwgYSDDqWNyaXQgOjxicj4NCiZndDsgLSBOb3RlIHRoYXQgdG8g YWNoaWV2ZSBzb21lIG9mIHRoZSBhYm92ZSBwb2ludHMsIFRVUk4gbXVzdCBiZSBmYXZvcmVkPGJy Pg0KJmd0OyBvdmVyIFNUVU4gdG8gZW5mb3JjZSB0aGF0IHRoZSBUVVJOLXBhdGggYWN0dWFsbHkg aXMgdXNlZC4gKFRoZSBBbnljYXN0PGJyPg0KJmd0OyBtZXRob2Qgc3VnZ2VzdGVkIGJlbG93LCDi gJxhdXRvbWF0aWNhbGx54oCdIGRvZXMgdGhpcy4pPGJyPg0KPGJyPg0KSSB1bmRlcnN0YW5kIHRo ZSBTVFVOIHZzIFRVUk4gcHJpb3JpdHkgaXNzdWUuIEJ1dCBJIGRvbid0IHNlZSBob3cgYW55Y2Fz dCBhZmZlY3RzIGl0IGluIGFueSB3YXkuIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLS0gR29vZCBwb2ludCAtIEkgd2FzIGEgYml0 IHF1aWNrIGhlcmUgKG1heWJlIHRvbyBxdWljayk8YnI+DQpXZSBoYXZlIGdpdmVuIHRoaXMgcXVp dGUgYml0IG9mIHRob3VnaHQsIHNpbmNlIGV2ZW4gaWYgYSBUVVJOIHNlcnZlciBpcyBwcm92aWRl ZCBhbmQgZGlzY292ZXJlZCwgQ1VSUkVOVCB1c2FnZSBvZiBJQ0UgbWF5IHN1Z2dlc3QgYSBjYW5k aWRhdGUgZnJvbSB0aGUgcmVtb3RlIHBhcnR5IHRoYXQgd2lsbCBtYWtlIGEgY29ubmVjdGlvbiB3 aXRob3V0IHRoZSBuZWVkL3VzYWdlIG9mIHRoZSBUVVJOIHNlcnZlciAodGhhdCB3ZSB3YW50ZWQg dG8gYmUgdXNlZA0KIGZvciB0aGUgZ29vZCBwdXJwb3NlcyBsaXN0ZWQpLjxicj4NCjxicj4NClRo ZSBvbmx5IHdheSB3ZSBmb3VuZCBhcm91bmQgdGhpcywgd2FzIHRvIHN0b3AgU1RVTiB0aHJvdWdo IHRoZSBJUCBkZWZhdWx0IGdhdGV3YXkgKGxpa2UgYSByZXN0cmljdGl2ZSBFbnRlcnByaXNlIGZp cmV3YWxsIGRvZXMgaW5oaWJpdGluZyBJQ0UgY29ubmVjdGl2aXR5LCB3aGljaCBvdGhlcnMgYXJl IGNvbmNlcm5lZCBhYm91dC4uLikuIFNpbmNlIHRoZSBwcm92aXNpb25pbmcgb2YgYXV0by1kaXNj b3ZlcnkgdXNpbmcgdGhlIGFueWNhc3QgbWVjaGFuaXNtLA0KIHdvdWxkIGJlIGFkZGluZyBhIHJv dXRlIGluIGEgZGVmYXVsdCBnYXRld2F5LCBhZGRpbmcgYSBmaXJld2FsbCBydWxlIHRvIGVhdCBT VFVOIHBhY2tldHMgd291bGQgYXNzdXJlIHRoYXQgdGhlIHByb3Zpc2lvbmVkIFRVUk4gc2VydmVy IGFjdHVhbGx5IGJlY29tZXMgdXNlZCAoYW5kIG5vdCBieXBhc3NlZCAmcXVvdDtieSBhY2NpZGVu dCZxdW90OykuIChUaGF0IHdhcyB0aGUgdGhvdWdodCBiZWhpbmQgdGhlIOKAnGF1dG9tYXRpY2Fs bHnigJ0gd2l0aGluIHF1b3Rlcy4pPGJyPg0KPGJyPg0KQlVULCBzaW5jZSB5b3UgYnJvdWdodCB1 cCB0aGUgcXVlc3Rpb24sIGFzc3VtaW5nIHRoYXQgd2UgaGF2ZSB0aGUgcG93ZXIgdG8gZW5mb3Jj ZSBXZWJSVEMgdXNhZ2Ugb2YgSUNFLCBJIGJlbGlldmUgYSBNVVNUIHJlcXVpcmVtZW50IHRvIHVz ZSBhbiBhdXRvLWRpc2NvdmVyZWQgVFVSTiBzZXJ2ZXIgaW5zdGVhZCBvZiBTVFVOLCB3b3VsZCBz b2x2ZSB0aGUgc2FtZSBwcm9ibGVtLiBIb3dldmVyLCB0aGlua2luZyBmdXJ0aGVyIChpbiByZWxh dGlvbg0KIHRvIHlvdXIgbmV4dCBxdWVzdGlvbiAtICZxdW90O2FueW9uZSBjb3VsZCBzZXQgdXAg YSBiYWRseS1tYWludGFpbmVkJnF1b3Q7IC0gZW5mb3JjaW5nIHN1Y2ggSUNFIHVzYWdlIG1heSBu b3QgYmUgZ29vZC4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCiZn dDsgLSAzXnJkIFRoZSBBbnljYXN0IG1ldGhvZCBiZWxvdyDigJMgSSBzZWUgbm8gcHJvYmxlbTxi cj4NCiZndDs8YnI+DQomZ3Q7IEl0IGFsc28gaGFzIHRoZSBhZHZhbnRhZ2Ugb2YgZW5jb3VyYWdp bmcgKGJ1dCBub3QgcmVxdWlyaW5nKSB0aGU8YnI+DQomZ3Q7IFNUVU4vVFVSTiB0byBiZSBidWls dCBpbiB0aGUgZGVmYXVsdCBnYXRld2F5IG9yIE5BVC9maXJld2FsbC9hY2Nlc3M8YnI+DQomZ3Q7 IHJvdXRlciBpdHNlbGYsIHdpdGggYSBzZWNvbmQgaW50ZXJmYWNlIHRvIGEgcHVibGljIElQIGFk ZHJlc3Mgb24gdGhlPGJyPg0KJmd0OyBXQU4gc2lkZS4gKEN1cnJlbnQgdm9sdW1lIGRlcGxveWVk LCBsb3cgY29zdCBOU1AgdHJpcGxlIHBsYXkgbW9kZW1zPGJyPg0KJmd0OyB1c3VhbGx5IGhhdmUg YSBxdWFsaXR5IGFzc3VyZWQgbGV2ZWwgMiBvciBsZXZlbCAzIFdBTiBwaXBlIGZvciBqdXN0PGJy Pg0KJmd0OyB2b2ljZSAoYW5kIGFub3RoZXIgZm9yIElQVFYpIOKAkyBUaGUgYW55Y2FzdCBkaXNj b3ZlcmVkIFRVUk4tc2VydmVyIGNhbjxicj4NCiZndDsgYmUgdGhlIGFjY2VzcyBnYXRld2F5IHRv IHN1Y2ggcXVhbGl0eSBwaXBlIGZvciBXZWJSVEMgbWVkaWEsIGluIGE8YnI+DQomZ3Q7IHNpbmds ZSBOU1AgcHJvdmlkZWQgQ1BFLCBzY2FsaW5nIGZyb20gcmVzaWRlbnRpYWwgYW5kIHVwLik8YnI+ DQo8YnI+DQpTdXBwb3NlIHdlIGRlZmluZSB3ZWxsLWtub3duIGFueWNhc3QgVFVSTiBzZXJ2ZXIg YWRkcmVzc2VzLiBIb3cgd291bGQgdGhpcyBub3QgYmUgc3ViamVjdCB0byB0aGUgc2FtZSBzZXJ2 aWNlIHF1YWxpdHkgaXNzdWVzIHRoYXQgcGxhZ3VlZCA2dG80PyBUaGF0IGlzLCBhbnlvbmUgY291 bGQgc2V0IHVwIGEgYmFkbHktbWFpbnRhaW5lZCwgdW5kZXItcHJvdmlzaW9uZWQgVFVSTiBzZXJ2 ZXIgYW5kIGFubm91bmNlIGl0IG92ZXIgQkdQIHRvIHRoZSB3b3JsZCwNCiBhcyBpdCB3YXMgZG9u ZSBmb3I8YnI+DQo2dG80IHJlbGF5cy4gT3IganVzdCBiYWQgQkdQIG91dGJvdW5kIGZpbHRlciBj b25maWd1cmF0aW9uLiBBbmQgaG93IGNhbiB3ZSBwcmV2ZW50IHRyaWFuZ2xlIHJvdXRpbmc/IFRo ZXJlIGlzIG5vdGhpbmcgZ3VhcmFudGVlaW5nIHRoYXQgdGhlIGFueWNhc3Qgc2VydmVyIHlvdSBz ZWUgaXMgYmVpbmcgcHJvdmlkZWQgdG8geW91IGJ5IHlvdXIgSVNQLCByYXRoZXIgdGhhbiBhIHNl cnZlciBzaXR0aW5nIG9uIHRoZSBvdGhlciBzaWRlIG9mIHRoZSBwbGFuZXQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLS0gR29vZCBwb2ludCAtIG5lZWRzIHRvIGJlIHJl c29sdmVkLiBGb3IgdGhpcyBJIGRvbid0IGhhdmUgYSByZWFkeSBhbnN3ZXIuLi48YnI+DQpBbiBh dXRvLWRpc2NvdmVyZWQgVFVSTiBzZXJ2ZXIgbXVzdCBiZSB0cnVzdGVkICh3aGF0ZXZlciBtZXRo b2QgaXQgaXMgZGlzY292ZXJlZCBieSkuIFdlIGFyZSB0cnVzdGluZyB0aGUgb25lIHByb3ZpZGlu ZyB1cyB3aXRoIGFuIElQIGFkZHJlc3MgYW5kIGRlZmF1bHQgZ2F0ZXdheSBhbnl3YXkuIEl0IHdv dWxkIGJlIGVhc3kgaWYgd2UgY291bGQgcmV1c2UgdGhhdCB0cnVzdCwgaW5zdGVhZCBvZiBhbm90 aGVyIG1lY2hhbmlzbXMuPGJyPg0KPGJyPg0KSXMgdGhlcmUgYSBnb29kIHdheSBmb3IgdGhlIGJy b3dzZXIgdG8gY2hlY2sgdGhhdCB0aGUgYW55Y2FzdCBhZGRyZXNzIGlzIG5vdCBoYW5kbGVkIGJl eW9uZCB0aGUgbmV0d29yayBzZXJ2aWNlIHByb3ZpZGVyJ3MgZGVmYXVsdCBnYXRld2F5PyBJZGVh cz88L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4N Cjxicj4NClRoYW5rcyw8YnI+DQpTaW1vbjxicj4NCi0tPGJyPg0KRFROIG1hZGUgZWFzeSwgbGVh biwgYW5kIHNtYXJ0IC0tJmd0OyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vcG9zdGVsbGF0 aW9uLnZpYWdlbmllLmNhLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5odHRwOi8vcG9zdGVsbGF0aW9uLnZpYWdlbmllLmNhPC9zcGFuPjwv YT48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KTkFUNjQvRE5T NjQgb3Blbi1zb3VyY2UgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LS0mZ3Q7Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Imh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhLyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwOi8vZWNkeXNpcy52 aWFnZW5pZS5jYTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxicj4NClNUVU4vVFVSTiBzZXJ2ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IC0tJmd0OyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vbnVt Yi52aWFnZW5pZS5jYS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+aHR0cDovL251bWIudmlhZ2VuaWUuY2E8L3NwYW4+PC9hPjxzcGFuIGxh bmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0K PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+ PC9hPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvc3Bhbj48L2E+PHNwYW4gbGFu Zz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8 YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwv c3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48 YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1h aWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdHJhbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A242AD996xmbrcdx10ciscoc_-- From tireddy@cisco.com Thu Feb 13 08:57:46 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877CD1A022F for ; Thu, 13 Feb 2014 08:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 BNSckhjJx2lb for ; Thu, 13 Feb 2014 08:57:44 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id E64EF1A0290 for ; Thu, 13 Feb 2014 08:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14648; q=dns/txt; s=iport; t=1392310663; x=1393520263; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=uIgHbZoQx0QiOvTZK9Sw/y02zR5g7Ao3CDOTZIFEJ8I=; b=N+psg7rCZTb5TrNg1kTh5742VpRWAqMaqE1rplyRdT7WvUQCJyk4UjAL G8kvxMfEFWDFTGoSh7Wq1zXO0BQ8OEIXMH/8CB4ojvvVgkvLgALTzDS68 gxxU0D75QlQfbbKnf7ZwWu3M3i24HGCHZAzR6LV9xpCQneLBX4pBqB0iR o=; X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="scan'208";a="20225155" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-5.cisco.com with ESMTP; 13 Feb 2014 16:57:42 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1DGvgUq002036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 16:57:42 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 10:57:42 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Karl Stahl , "'Simon Perreault'" , "tram@ietf.org" , "tireddy@icisco.com" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPJrZnSgUY4V56JE+wy6rTjZeHIZqvVbIwgAEJXKCAANCLcIAB2bUQgABgRxA= Date: Thu, 13 Feb 2014 16:57:42 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242AD9B8@xmb-rcd-x10.cisco.com> References: <082c01cf17d4$393d7bb0$abb87310$@stahl@intertex.se> <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <02cd01cf24cf$42ff6de0$c8fe49a0$@stahl@intertex.se> <52F8DF21.2080303@viagenie.ca> <049801cf26b6$5a87db30$0f979190$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A242ABA2D@xmb-rcd-x10.cisco.com> <058f01cf275d$da1dc6a0$8e5953e0$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A242AC8C2@xmb-rcd-x10.cisco.com> <007101cf28af$d4e3cb00$7eab6100$@stahl@intertex.se> In-Reply-To: <007101cf28af$d4e3cb00$7eab6100$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.62.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:57:46 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBLYXJsIFN0YWhsIFttYWlsdG86 a2FybC5zdGFobEBpbnRlcnRleC5zZV0NCj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAy MDE0IDU6MDYgUE0NCj4gVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSk7ICdTaW1vbiBQ ZXJyZWF1bHQnOyB0cmFtQGlldGYub3JnOw0KPiB0aXJlZGR5QGljaXNjby5jb20NCj4gU3ViamVj dDogU1Y6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVj aGFuaXNtIGZvcg0KPiBlbnRlcnByaXNlIGFuZCBJU1BzDQo+IA0KPiBJIGNoZWNrZWQgTWFsaWNl PWRpc2N1c3NlZCBhbmQganVzdCBjb21tZW50ZWQgaW4gcHJldmlvdXMgcmVzcG9uc2UNCj4gDQo+ IEJ1dCB3ZSBuZWVkIHRvIEVORk9SQ0UgcGF0aHMgYWR2aWNlZC9vZmZlcmVkIGJ5IHRoZSBlbnRl cnByaXNlIGFuZC9vcg0KPiBOU1AvSVNQIHRvIGJlIHVzZWQgKHRvIGNvcGUgd2l0aCB0aGUgcHJv YmxlbXMpLg0KPiANCj4gRG8geW91IHNlZSBhbiBhbHRlcm5hdGUgd2F5L21ldGhvZCBvZiBkb2lu ZyB0aGF0LCBub3QgdXNpbmcgVFVSTj8NCg0KWWVzLCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvc2Vh cmNoL2RyYWZ0LXBlbm5vLXBjcC1tb2JpbGUtcW9zLTAwIGV4cGxhaW5zIGhvdyBQMlAgbWVkaWEg c3RyZWFtcyBjYW4gYmUgaWRlbnRpZmllZCBhbmQgZGlmZmVyZW50aWF0ZWQgUW9TIHNlcnZpY2Vz IGNhbiBiZSBwcm92aWRlZCBieSB0aGUgSVNQIHdpdGhvdXQgZm9yY2luZyBXZWJSVEMgY2xpZW50 IHRvIG9ubHkgYWR2ZXJ0aXNlIHJlbGF5ZWQgY2FuZGlkYXRlcy4NCg0KLVRpcnUuDQoNCj4gDQo+ IC9LYXJsDQo+IA0KPiAtLS0tLVVyc3BydW5nbGlndCBtZWRkZWxhbmRlLS0tLS0NCj4gRnLDpW46 IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgW21haWx0bzp0aXJlZGR5QGNpc2NvLmNvbV0N Cj4gU2tpY2thdDogZGVuIDEyIGZlYnJ1YXJpIDIwMTQgMDg6MDENCj4gVGlsbDogS2FybCBTdGFo bDsgJ1NpbW9uIFBlcnJlYXVsdCc7IHRyYW1AaWV0Zi5vcmc7IHRpcmVkZHlAaWNpc2NvLmNvbQ0K PiDDhG1uZTogUkU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3Zl cnkgbWVjaGFuaXNtIGZvcg0KPiBlbnRlcnByaXNlIGFuZCBJU1BzDQo+IA0KPiBIaSBLYXJsLA0K PiANCj4gWWVzLCB0aGVyZSBpcyBhIHByb2JsZW0gYnV0IFAyUCBXZWJSVEMgc3RyZWFtcyAoYm90 aCBtZWRpYSBhbmQgZGF0YQ0KPiBjaGFubmVscykgY2FuIGJlIGlkZW50aWZpZWQgYW5kIFFvUyBj YW4gYmUgcHJvdmlkZWQgYnkgdGhlIGFjY2VzcyBuZXR3b3JrDQo+IHdpdGhvdXQgZm9yY2luZyBU VVJOIHRvIGJlIHVzZWQuIFlvdSBtYXkgd2FudCB0byBsb29rIGludG8gUENQIEZMT1dEQVRBDQo+ IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13aW5nLXBjcC1mbG93ZGF0YS0wMCks IE1BTElDRQ0KPiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFydGluc2VuLW1t dXNpYy1tYWxpY2UtMDApLg0KPiANCj4gLVRpcnUuDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4gRnJvbTogS2FybCBTdGFobCBbbWFpbHRvOmthcmwuc3RhaGxAaW50ZXJ0 ZXguc2VdDQo+ID4gU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAxNCAxMjo0NyBBTQ0K PiA+IFRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpOyAnU2ltb24gUGVycmVhdWx0Jzsg dHJhbUBpZXRmLm9yZzsNCj4gPiB0aXJlZGR5QGljaXNjby5jb20NCj4gPiBTdWJqZWN0OiBTVjog W3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20N Cj4gPiBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KPiA+DQo+ID4gVGlyZWRkeSB3cm90ZSBiZWxv dyA+IFRoZXJlIGFyZSB2YXJpb3VzIHdheXMgdG8gcHJpb3JpdGl6ZSBXZWJSVEMNCj4gPiBtZWRp YSBzdHJlYW1zIGFuZCBJIGRvbid0IHNlZSBhIG5lZWQgdG8gYmxvY2sgUDJQIGNvbm5lY3Rpdml0 eS4NCj4gPg0KPiA+IC0tLSBXZSBuZWVkIG5vdCBvbmx5IHRvIHRoaW5rIGFib3V0IHByaW9yaXRp emluZyBXZWJSVEMsIGl0IGlzIGFib3V0DQo+ID4gInRyYWZmaWMgc2hhcGluZyBhbHNvIi4NCj4g PiAtIElmIHdlIGNvbnNpZGVyIHRoZSBjYXNlIG9mIFdlYlJUQyB0cmFmZmljIG92ZXIgSW50ZXJu ZXQvbW9iaWxlIE9UVA0KPiA+IChub3QgdGFsa2luZyBhYm91dCBmZWVkaW5nIFdlYlJUQyBpbnRv IHNvbWUgYXBwbGljYXRpb24gc3BlY2lmaWMNCj4gPiBuZXR3b3JrIGxpa2UgSU1TIHdoZXJlIHRo ZXkgbWF5IGJlIG90aGVyIHF1YWxpdHkgbWVhc3VyZXMpLCB3ZSBnZXQNCj4gPiBsb3N0IHF1YWxp dHkgd2lzZSBhbHJlYWR5IHdoZW4gKGlmKSB3ZSBhbGxvdyBwcmlvcml0aXplZCBXZWJSVEMNCj4g PiB0cmFmZmljIHRvIGdvIGludG8gYSBjb25nZXN0aW9uIHBvaW50IChsaWtlIGEgTkFUL2ZpcmV3 YWxsIG9yIGRlZmF1bHQNCj4gPiBnYXRld2F5LCB3aGVyZSB0aGVyZSBtYXkgYmUgaGVhdnkgZGF0 YSB0cmFmZmljIGFscmVhZHkgZmlsbGluZyB0aGUgcGlwZS4NCj4gPiAtIFF1YWxpdHkgbG9zcyBo ZXJlIChsb3N0IFdlYlJUQyBtZWRpYSBwYWNrZXRzKSBjYW5ub3QgYmUgcmVjb3ZlcmVkDQo+ID4g bGF0ZXINCj4gPiAtIFRoYXQgaXMgdGhlICJuZWVkIHRvIGJsb2NrIFAyUCBjb25uZWN0aXZpdHki ICh3aGljaCBtYXkgc291bmQgdWdseQ0KPiA+IGJ1dCBpcyByZWFsbHkgYWJvdXQgYXNzdXJpbmcg dGhhdCB3ZSBDQU4gZ2V0IFAyUCBjb25uZWN0aXZpdHkgd2l0aA0KPiA+IGJlc3QgcXVhbGl0eSwg d2l0aCBoZWxwIG9mIHNlcnZpY2UgcHJvdmlkZXJzIGFuZCBMQU4gYWRtaW5pc3RyYXRvcnMNCj4g PiB0aGF0IHdhbnQgV2ViUlRDIHRyYWZmaWMgdG8gYmUgZ29vZCBhbmQgYWNjZXNzaWJsZS4uLikN Cj4gPg0KPiA+IC0tLSBPciBkbyBzZWUgYW5vdGhlci9iZXR0ZXIgd2F5IGFyb3VuZCB0aGlzIHRo YXQgSSBjYW5ub3Qgc2VlPw0KPiA+DQo+ID4gLS0tLS1VcnNwcnVuZ2xpZ3QgbWVkZGVsYW5kZS0t LS0tDQo+ID4gRnLDpW46IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgW21haWx0bzp0aXJl ZGR5QGNpc2NvLmNvbV0NCj4gPiBTa2lja2F0OiBkZW4gMTEgZmVicnVhcmkgMjAxNCAwMzo0MA0K PiA+IFRpbGw6IEthcmwgU3RhaGw7ICdTaW1vbiBQZXJyZWF1bHQnOyB0cmFtQGlldGYub3JnOyB0 aXJlZGR5QGljaXNjby5jb20NCj4gPiDDhG1uZTogUkU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVS TiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvcg0KPiA+IGVudGVycHJpc2UgYW5k IElTUHMNCj4gPg0KPiA+ID4gVGhlIG9ubHkgd2F5IHdlIGZvdW5kIGFyb3VuZCB0aGlzLCB3YXMg dG8gc3RvcCBTVFVOIHRocm91Z2ggdGhlIElQDQo+ID4gPiBkZWZhdWx0IGdhdGV3YXkgKGxpa2Ug YSByZXN0cmljdGl2ZSBFbnRlcnByaXNlIGZpcmV3YWxsIGRvZXMNCj4gPiA+IGluaGliaXRpbmcg SUNFIGNvbm5lY3Rpdml0eSwgd2hpY2ggb3RoZXJzIGFyZSBjb25jZXJuZWQgYWJvdXQuLi4pLg0K PiA+ID4gU2luY2UgdGhlIHByb3Zpc2lvbmluZyBvZiBhdXRvLSBkaXNjb3ZlcnkgdXNpbmcgdGhl IGFueWNhc3QNCj4gPiA+IG1lY2hhbmlzbSwgd291bGQgYmUgYWRkaW5nIGEgcm91dGUgaW4gYSBk ZWZhdWx0IGdhdGV3YXksIGFkZGluZyBhDQo+ID4gPiBmaXJld2FsbCBydWxlIHRvIGVhdCBTVFVO IHBhY2tldHMgd291bGQgYXNzdXJlIHRoYXQgdGhlIHByb3Zpc2lvbmVkDQo+ID4gPiBUVVJOIHNl cnZlciBhY3R1YWxseSBiZWNvbWVzIHVzZWQgKGFuZCBub3QgYnlwYXNzZWQgImJ5IGFjY2lkZW50 IikuDQo+ID4gPiAoVGhhdCB3YXMgdGhlIHRob3VnaHQgYmVoaW5kIHRoZSDigJxhdXRvbWF0aWNh bGx54oCdIHdpdGhpbiBxdW90ZXMuKQ0KPiA+DQo+ID4gVGhlcmUgYXJlIHZhcmlvdXMgd2F5cyB0 byBwcmlvcml0aXplIFdlYlJUQyBtZWRpYSBzdHJlYW1zIGFuZCBJIGRvbid0DQo+ID4gc2VlIGEg bmVlZCB0byBibG9jayBQMlAgY29ubmVjdGl2aXR5Lg0KPiA+IC0tLSBXZSBuZWVkIG5vdCBvbmx5 IHRvIHRoaW5rIGFib3V0IHByaW9yaXRpemluZyBXZWJSVEMsIGl0IGlzIGFib3V0DQo+ID4gInRy YWZmaWMgc2hhcGluZyBhbHNvIi4NCj4gPiAtIElmIHdlIGNvbnNpZGVyIHRoZSBjYXNlIG9mIFdl YlJUQyB0cmFmZmljIG92ZXIgSW50ZXJuZXQvbW9iaWxlIE9UVA0KPiA+IChub3QgdGFsa2luZyBh Ym91dCBmZWVkaW5nIFdlYlJUQyBpbnRvIHNvbWUgYXBwbGljYXRpb24gc3BlY2lmaWMNCj4gPiBu ZXR3b3JrIGxpa2UgSU1TIHdoZXJlIHRoZXkgbWF5IGJlIG90aGVyIHF1YWxpdHkgbWVhc3VyZXMp LCB3ZSBnZXQNCj4gPiBsb3N0IHF1YWxpdHkgd2lzZSBhbHJlYWR5IHdoZW4gKGlmKSB3ZSBhbGxv dyBwcmlvcml0aXplZCBXZWJSVEMNCj4gPiB0cmFmZmljIHRvIGdvIGludG8gYSBjb25nZXN0aW9u IHBvaW50IChsaWtlIGEgTkFUL2ZpcmV3YWxsIG9yIGRlZmF1bHQNCj4gPiBnYXRld2F5LCB3aGVy ZSB0aGVyZSBtYXkgYmUgaGVhdnkgZGF0YSB0cmFmZmljIGFscmVhZHkgZmlsbGluZyB0aGUgcGlw ZS4NCj4gPiAtIFF1YWxpdHkgbG9zcyBoZXJlIChsb3N0IFdlYlJUQyBtZWRpYSBwYWNrZXRzKSBj YW5ub3QgYmUgcmVjb3ZlcmVkDQo+ID4gbGF0ZXINCj4gPiAtIFRoYXQgaXMgdGhlICJuZWVkIHRv IGJsb2NrIFAyUCBjb25uZWN0aXZpdHkiICh3aGljaCBtYXkgc291bmQgdWdseQ0KPiA+IGJ1dCBp cyByZWFsbHkgYWJvdXQgYXNzdXJpbmcgdGhhdCB3ZSBDQU4gZ2V0IFAyUCBjb25uZWN0aXZpdHkg d2l0aA0KPiA+IGJlc3QgcXVhbGl0eSwgd2l0aCBoZWxwIG9mIHNlcnZpY2UgcHJvdmlkZXJzIGFu ZCBMQU4gYWRtaW5pc3RyYXRvcnMNCj4gPiB0aGF0IHdhbnQgV2ViUlRDIHRyYWZmaWMgdG8gYmUg Z29vZCBhbmQgYWNjZXNzaWJsZS4uLikNCj4gPg0KPiA+IC0tLSBPciBkbyBzZWUgYW5vdGhlci9i ZXR0ZXIgd2F5IGFyb3VuZCB0aGlzIHRoYXQgSSBjYW5ub3Qgc2VlPw0KPiA+DQo+ID4gIFVzaW5n IFRVUk4gc2VydmVyIGl0c2VsZiBlbmRwb2ludCBjYW4gbGVhcm4gc2VydmVyLXJlZmxleGl2ZQ0K PiA+IGNhbmRpZGF0ZXMuIElmIHRoZXJlIGlzIGEgcmVzdHJpY3RpdmUgZmlyZXdhbGwgdGhhdCBi bG9ja3MgUDJQDQo+ID4gY29ubmVjdGl2aXR5IHRoZW4gcmVsYXllZCBjYW5kaWRhdGUgd291bGQg ZXZlbnR1YWxseSBiZSBub21pbmF0ZWQNCj4gPiBiZWNhdXNlIElDRSBjb25uZWN0aXZpdHkgY2hl Y2sgZmFpbHMgd2l0aCBvdGhlciBjYW5kaWRhdGUgdHlwZXMuDQo+ID4NCj4gPiBJIGRvbid0IHNl ZSBhbnkgbmVlZCB0byBhZHZlcnRpc2Ugb25seSByZWxheWVkIGNhbmRpZGF0ZXMgaW4gdGhlDQo+ ID4gb2ZmZXIvYW5zd2VyIG90aGVyIHRoYW4gZm9yIHByaXZhY3kgcmVhc29ucy4NCj4gPg0KPiA+ IC1UaXJ1Lg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJv bTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEthcmwg U3RhaGwNCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDExLCAyMDE0IDQ6NDggQU0NCj4g PiA+IFRvOiAnU2ltb24gUGVycmVhdWx0JzsgdHJhbUBpZXRmLm9yZzsgdGlyZWRkeUBpY2lzY28u Y29tDQo+ID4gPiBTdWJqZWN0OiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBh dXRvLWRpc2NvdmVyeQ0KPiA+ID4gbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzDQo+ ID4gPg0KPiA+ID4gU2ltb24sDQo+ID4gPg0KPiA+ID4gR29vZCBxdWVzdGlvbnMgLSBzZWUgaW5s aW5lIGJlbG93IC0tPiAuDQo+ID4gPiBTb21lIG1vcmUgdGhvdWdodCBpcyByZXF1aXJlZCENCj4g PiA+DQo+ID4gPiAvS2FybA0KPiA+ID4NCj4gPiA+IC0tLS0tVXJzcHJ1bmdsaWd0IG1lZGRlbGFu ZGUtLS0tLQ0KPiA+ID4gRnLDpW46IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmdd IEbDtnIgU2ltb24gUGVycmVhdWx0DQo+ID4gPiBTa2lja2F0OiBkZW4gMTAgZmVicnVhcmkgMjAx NCAxNToxNg0KPiA+ID4gVGlsbDogS2FybCBTdGFobDsgdHJhbUBpZXRmLm9yZzsgdGlyZWRkeUBp Y2lzY28uY29tDQo+ID4gPiDDhG1uZTogUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2 ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtDQo+ID4gPiBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQ cw0KPiA+ID4NCj4gPiA+IEthcmwsDQo+ID4gPg0KPiA+ID4gSXQgaXMgZ3JlYXQgdG8gc2VlIHN1 Y2ggZW50aHVzaWFzbSEgVGhhbmtzIQ0KPiA+ID4NCj4gPiA+IEkgaGF2ZSBhIGNvdXBsZSB0ZWNo bmljYWwgcXVlc3Rpb25zLi4uDQo+ID4gPg0KPiA+ID4gTGUgMjAxNC0wMi0wOCAwODoxMSwgS2Fy bCBTdGFobCBhIMOpY3JpdCA6DQo+ID4gPiA+IC0gTm90ZSB0aGF0IHRvIGFjaGlldmUgc29tZSBv ZiB0aGUgYWJvdmUgcG9pbnRzLCBUVVJOIG11c3QgYmUNCj4gPiA+ID4gZmF2b3JlZCBvdmVyIFNU VU4gdG8gZW5mb3JjZSB0aGF0IHRoZSBUVVJOLXBhdGggYWN0dWFsbHkgaXMgdXNlZC4NCj4gPiA+ ID4gKFRoZSBBbnljYXN0IG1ldGhvZCBzdWdnZXN0ZWQgYmVsb3csIOKAnGF1dG9tYXRpY2FsbHni gJ0gZG9lcyB0aGlzLikNCj4gPiA+DQo+ID4gPiBJIHVuZGVyc3RhbmQgdGhlIFNUVU4gdnMgVFVS TiBwcmlvcml0eSBpc3N1ZS4gQnV0IEkgZG9uJ3Qgc2VlIGhvdw0KPiA+ID4gYW55Y2FzdCBhZmZl Y3RzIGl0IGluIGFueSB3YXkuIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4/DQo+ID4gPg0KPiA+ID4g LS0tIEdvb2QgcG9pbnQgLSBJIHdhcyBhIGJpdCBxdWljayBoZXJlIChtYXliZSB0b28gcXVpY2sp IFdlIGhhdmUNCj4gPiA+IGdpdmVuIHRoaXMgcXVpdGUgYml0IG9mIHRob3VnaHQsIHNpbmNlIGV2 ZW4gaWYgYSBUVVJOIHNlcnZlciBpcw0KPiA+ID4gcHJvdmlkZWQgYW5kIGRpc2NvdmVyZWQsIENV UlJFTlQgdXNhZ2Ugb2YgSUNFIG1heSBzdWdnZXN0IGENCj4gPiA+IGNhbmRpZGF0ZSBmcm9tIHRo ZSByZW1vdGUgcGFydHkgdGhhdCB3aWxsIG1ha2UgYSBjb25uZWN0aW9uIHdpdGhvdXQNCj4gPiA+ IHRoZSBuZWVkL3VzYWdlIG9mIHRoZSBUVVJOIHNlcnZlciAodGhhdCB3ZSB3YW50ZWQgdG8gYmUg dXNlZCBmb3IgdGhlDQo+ID4gPiBnb29kDQo+ID4gcHVycG9zZXMgbGlzdGVkKS4NCj4gPiA+DQo+ ID4gPiBUaGUgb25seSB3YXkgd2UgZm91bmQgYXJvdW5kIHRoaXMsIHdhcyB0byBzdG9wIFNUVU4g dGhyb3VnaCB0aGUgSVANCj4gPiA+IGRlZmF1bHQgZ2F0ZXdheSAobGlrZSBhIHJlc3RyaWN0aXZl IEVudGVycHJpc2UgZmlyZXdhbGwgZG9lcw0KPiA+ID4gaW5oaWJpdGluZyBJQ0UgY29ubmVjdGl2 aXR5LCB3aGljaCBvdGhlcnMgYXJlIGNvbmNlcm5lZCBhYm91dC4uLikuDQo+ID4gPiBTaW5jZSB0 aGUgcHJvdmlzaW9uaW5nIG9mIGF1dG8tIGRpc2NvdmVyeSB1c2luZyB0aGUgYW55Y2FzdA0KPiA+ ID4gbWVjaGFuaXNtLCB3b3VsZCBiZSBhZGRpbmcgYSByb3V0ZSBpbiBhIGRlZmF1bHQgZ2F0ZXdh eSwgYWRkaW5nIGENCj4gPiA+IGZpcmV3YWxsIHJ1bGUgdG8gZWF0IFNUVU4gcGFja2V0cyB3b3Vs ZCBhc3N1cmUgdGhhdCB0aGUgcHJvdmlzaW9uZWQNCj4gPiA+IFRVUk4gc2VydmVyIGFjdHVhbGx5 IGJlY29tZXMgdXNlZCAoYW5kIG5vdCBieXBhc3NlZCAiYnkgYWNjaWRlbnQiKS4NCj4gPiA+IChU aGF0IHdhcyB0aGUgdGhvdWdodCBiZWhpbmQgdGhlIOKAnGF1dG9tYXRpY2FsbHnigJ0gd2l0aGlu IHF1b3Rlcy4pDQo+ID4gPg0KPiA+ID4gQlVULCBzaW5jZSB5b3UgYnJvdWdodCB1cCB0aGUgcXVl c3Rpb24sIGFzc3VtaW5nIHRoYXQgd2UgaGF2ZSB0aGUNCj4gPiA+IHBvd2VyIHRvIGVuZm9yY2Ug V2ViUlRDIHVzYWdlIG9mIElDRSwgSSBiZWxpZXZlIGEgTVVTVCByZXF1aXJlbWVudA0KPiA+ID4g dG8gdXNlIGFuIGF1dG8tIGRpc2NvdmVyZWQgVFVSTiBzZXJ2ZXIgaW5zdGVhZCBvZiBTVFVOLCB3 b3VsZCBzb2x2ZQ0KPiA+ID4gdGhlDQo+ID4gc2FtZSBwcm9ibGVtLg0KPiA+ID4gSG93ZXZlciwg dGhpbmtpbmcgZnVydGhlciAoaW4gcmVsYXRpb24gdG8geW91ciBuZXh0IHF1ZXN0aW9uIC0NCj4g PiA+ICJhbnlvbmUgY291bGQgc2V0IHVwIGEgYmFkbHktbWFpbnRhaW5lZCIgLSBlbmZvcmNpbmcg c3VjaCBJQ0UgdXNhZ2UNCj4gPiA+IG1heSBub3QgYmUNCj4gPiA+IGdvb2QuKQ0KPiA+ID4NCj4g PiA+DQo+ID4gPiA+IC0gM15yZCBUaGUgQW55Y2FzdCBtZXRob2QgYmVsb3cg4oCTIEkgc2VlIG5v IHByb2JsZW0NCj4gPiA+ID4NCj4gPiA+ID4gSXQgYWxzbyBoYXMgdGhlIGFkdmFudGFnZSBvZiBl bmNvdXJhZ2luZyAoYnV0IG5vdCByZXF1aXJpbmcpIHRoZQ0KPiA+ID4gPiBTVFVOL1RVUk4gdG8g YmUgYnVpbHQgaW4gdGhlIGRlZmF1bHQgZ2F0ZXdheSBvcg0KPiA+ID4gPiBOQVQvZmlyZXdhbGwv YWNjZXNzIHJvdXRlciBpdHNlbGYsIHdpdGggYSBzZWNvbmQgaW50ZXJmYWNlIHRvIGENCj4gPiA+ ID4gcHVibGljIElQIGFkZHJlc3Mgb24gdGhlIFdBTiBzaWRlLiAoQ3VycmVudCB2b2x1bWUgZGVw bG95ZWQsIGxvdw0KPiA+ID4gPiBjb3N0IE5TUCB0cmlwbGUgcGxheSBtb2RlbXMgdXN1YWxseSBo YXZlIGEgcXVhbGl0eSBhc3N1cmVkIGxldmVsIDINCj4gPiA+ID4gb3IgbGV2ZWwgMyBXQU4gcGlw ZSBmb3IganVzdCB2b2ljZSAoYW5kIGFub3RoZXIgZm9yIElQVFYpIOKAkyBUaGUNCj4gPiA+ID4g YW55Y2FzdCBkaXNjb3ZlcmVkIFRVUk4tc2VydmVyIGNhbiBiZSB0aGUgYWNjZXNzIGdhdGV3YXkg dG8gc3VjaA0KPiA+ID4gPiBxdWFsaXR5IHBpcGUgZm9yIFdlYlJUQyBtZWRpYSwgaW4gYSBzaW5n bGUgTlNQIHByb3ZpZGVkIENQRSwNCj4gPiA+ID4gc2NhbGluZyBmcm9tIHJlc2lkZW50aWFsIGFu ZCB1cC4pDQo+ID4gPg0KPiA+ID4gU3VwcG9zZSB3ZSBkZWZpbmUgd2VsbC1rbm93biBhbnljYXN0 IFRVUk4gc2VydmVyIGFkZHJlc3Nlcy4gSG93DQo+ID4gPiB3b3VsZCB0aGlzIG5vdCBiZSBzdWJq ZWN0IHRvIHRoZSBzYW1lIHNlcnZpY2UgcXVhbGl0eSBpc3N1ZXMgdGhhdA0KPiA+ID4gcGxhZ3Vl ZCA2dG80PyBUaGF0IGlzLCBhbnlvbmUgY291bGQgc2V0IHVwIGEgYmFkbHktbWFpbnRhaW5lZCwN Cj4gPiA+IHVuZGVyLXByb3Zpc2lvbmVkIFRVUk4gc2VydmVyIGFuZCBhbm5vdW5jZSBpdCBvdmVy IEJHUCB0byB0aGUgd29ybGQsDQo+ID4gPiBhcyBpdCB3YXMgZG9uZSBmb3INCj4gPiA+IDZ0bzQg cmVsYXlzLiBPciBqdXN0IGJhZCBCR1Agb3V0Ym91bmQgZmlsdGVyIGNvbmZpZ3VyYXRpb24uIEFu ZCBob3cNCj4gPiA+IGNhbiB3ZSBwcmV2ZW50IHRyaWFuZ2xlIHJvdXRpbmc/IFRoZXJlIGlzIG5v dGhpbmcgZ3VhcmFudGVlaW5nIHRoYXQNCj4gPiA+IHRoZSBhbnljYXN0IHNlcnZlciB5b3Ugc2Vl IGlzIGJlaW5nIHByb3ZpZGVkIHRvIHlvdSBieSB5b3VyIElTUCwNCj4gPiA+IHJhdGhlciB0aGFu IGEgc2VydmVyIHNpdHRpbmcgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIHBsYW5ldC4NCj4gPiA+ DQo+ID4gPiAtLS0gR29vZCBwb2ludCAtIG5lZWRzIHRvIGJlIHJlc29sdmVkLiBGb3IgdGhpcyBJ IGRvbid0IGhhdmUgYSByZWFkeQ0KPiA+IGFuc3dlci4uLg0KPiA+ID4gQW4gYXV0by1kaXNjb3Zl cmVkIFRVUk4gc2VydmVyIG11c3QgYmUgdHJ1c3RlZCAod2hhdGV2ZXIgbWV0aG9kIGl0DQo+ID4g PiBpcyBkaXNjb3ZlcmVkIGJ5KS4gV2UgYXJlIHRydXN0aW5nIHRoZSBvbmUgcHJvdmlkaW5nIHVz IHdpdGggYW4gSVANCj4gPiA+IGFkZHJlc3MgYW5kIGRlZmF1bHQgZ2F0ZXdheSBhbnl3YXkuIEl0 IHdvdWxkIGJlIGVhc3kgaWYgd2UgY291bGQNCj4gPiA+IHJldXNlIHRoYXQgdHJ1c3QsIGluc3Rl YWQgb2YgYW5vdGhlciBtZWNoYW5pc21zLg0KPiA+ID4NCj4gPiA+IElzIHRoZXJlIGEgZ29vZCB3 YXkgZm9yIHRoZSBicm93c2VyIHRvIGNoZWNrIHRoYXQgdGhlIGFueWNhc3QNCj4gPiA+IGFkZHJl c3MgaXMgbm90IGhhbmRsZWQgYmV5b25kIHRoZSBuZXR3b3JrIHNlcnZpY2UgcHJvdmlkZXIncyBk ZWZhdWx0DQo+IGdhdGV3YXk/DQo+ID4gSWRlYXM/DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4g PiBUaGFua3MsDQo+ID4gPiBTaW1vbg0KPiA+ID4gLS0NCj4gPiA+IERUTiBtYWRlIGVhc3ksIGxl YW4sIGFuZCBzbWFydCAtLT4gaHR0cDovL3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5jYQ0KPiA+ID4g TkFUNjQvRE5TNjQgb3Blbi1zb3VyY2UgICAgICAgIC0tPiBodHRwOi8vZWNkeXNpcy52aWFnZW5p ZS5jYQ0KPiA+ID4gU1RVTi9UVVJOIHNlcnZlciAgICAgICAgICAgICAgIC0tPiBodHRwOi8vbnVt Yi52aWFnZW5pZS5jYQ0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiA+IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4gPiB0cmFtQGlldGYub3Jn DQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCj4gPiA+ DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gPiA+IHRyYW1AaWV0Zi5vcmcNCj4gPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KPiANCg0K From nobody Thu Feb 13 10:53:53 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E226E1A03EB for ; Thu, 13 Feb 2014 10:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 FNecfdAtWAUQ for ; Thu, 13 Feb 2014 10:46:33 -0800 (PST) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 638FB1A03DF for ; Thu, 13 Feb 2014 10:46:33 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id i4so13164216oah.39 for ; Thu, 13 Feb 2014 10:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kZydE+LC9852ZVwMpTap7mjfPYGX57STS4OY9edw1pw=; b=A06aDVZ7R/9kB1U9hMK5YohVrKI9Q1umzTG/o/bOiI8VPMH/3Wp3FPjLp9vPbug9Zo dN2+bxTNg6BOCqFTwiD2SV61xmkaXKxZQ/3Cm9tuQpeltkxs223dYtj0zcKyaNHJc8kt hqOHnqZXzWlcWodPzRDR27Tw9vvXlIqgeeNmuJYOGHABP7XCq2qF6wR3U8xQdzCmk9ZM Xcn2ugO8Uun7sYKTh7S/gbwVkMuuH6olZM94IZNc/4909pnRcV0y9nRYzuwU5xvZRQgx pkFfa8iFmzTnbuobuNXfEfsNkC/3q5sarKZed+vFM7Z2ciMsAokeL1gJoIBqWEF7bu3b kuNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kZydE+LC9852ZVwMpTap7mjfPYGX57STS4OY9edw1pw=; b=alDLtGYTXfrGNPHpjXpMycnPMXQbkQy6VthwQI5DktwxaQYT0wsK6qUYNBCzelUv/z dT4sijE69aLM/Q2mVWMJQmuZpPLd5GikUcOkWMIzE3qtHOLdC5A/jbzwF41S4acgbq61 2dakdQtQ3uygcbuzV8PaCuUX4A968sIs0HFll0bzwdBoXYWo45eU70aVg08wNmhhj7Sm /8Xa7XW+uyX+3VMGlQAH4TELrwlmv88E4J4eCl9pPN44w0WSKSDSlUx4OSZtdE5OIJm+ kxcj4Ie+AHmDLhaFaPHGef1kkfZNnofh9Rpafzgg4pxVUU+nP1IVardpemvaCQMLKzum GdAw== X-Gm-Message-State: ALoCoQl1LGAlXLmpPC+BBPSzYSGOPVoMMZ33doiw0KKigqkbxASZHffgBq3lj6F9jes37bWF5qWNE5l88nUg9m88EBYgxMADV9GRJPleuZLjdKcH9ELZNSd5Q0U099XCBU4/3MxKX/Riijsugz/6CdKnPJC4tlNwYG+gsguagrN7yZ174B8ZhkhPBLd9OW8KNfSA0lX7zH1i X-Received: by 10.60.231.194 with SMTP id ti2mr2489609oec.41.1392317191756; Thu, 13 Feb 2014 10:46:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.96.230 with HTTP; Thu, 13 Feb 2014 10:45:58 -0800 (PST) In-Reply-To: <52fccc18.6501430a.3f96.ffffa2f0SMTPIN_ADDED_BROKEN@mx.google.com> References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> <52fccc18.6501430a.3f96.ffffa2f0SMTPIN_ADDED_BROKEN@mx.google.com> From: Justin Uberti Date: Thu, 13 Feb 2014 10:45:58 -0800 Message-ID: To: Karl Stahl Content-Type: multipart/alternative; boundary=001a11368658a17b7d04f24e1b0b Archived-At: http://mailarchive.ietf.org/arch/msg/tram/5kG3fsd9-sUm7nUXp-iPFDDebKY X-Mailman-Approved-At: Thu, 13 Feb 2014 10:53:49 -0800 Cc: "tireddy@icisco.com" , Simon Perreault , Oleg Moskalenko , "tram@ietf.org" , "Muthu Arul Mozhi Perumal \(mperumal\)" , "Hutton, Andrew" , "Tirumaleswar Reddy \(tireddy\)" , Marc Blanchet , "Dan Wing \(dwing\)" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:46:41 -0000 --001a11368658a17b7d04f24e1b0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Karl, You sent 23 messages to the list on this same thread in the past few hours. This is not an effective way of presenting your ideas; I myself have lost track of what you are hoping to accomplish. Right now the only currently viable mechanism for auto-discovery is WPAD. If you think the anycast mechanism is worth pursuing, I suggest writing it up as an I-D. There have also been several mechanisms proposed for doing QoS provisioning, namely http://tools.ietf.org/search/draft-penno-pcp-mobile-qos-00 and http://tools.ietf.org/html/draft-martinsen-tram-discuss-00. If you think those proposals are insufficient, I suggest pointing out your concerns in threads specific to those documents. Justin On Thu, Feb 13, 2014 at 4:04 AM, Karl Stahl wrote: > Note that some things being questioned in this discussion already are in > the draft-ietf-rtcweb-use-cases-and-requirements document (pointed out > below). I think this may clarify some things also=E2=80=A6 > > > > > > On the side of this TRAM-list, I also got this question: > > > Regarding the enterprise case, I am not sure I follow your argument. > > > Do you mean that by setting up an enterprise TURN server, and open the > firewall for media over UDP from/to TURN server be the solution? > > ---- As we all realize, that would of course not help or improve things > > > > The intended solution in the enterprise case has not yet been spelled out > in this TRAM-list discussion, so for better understanding, let me copy a > few things from the discussion in September/October on the RTCWEB-list an= d > what is (since long) spelled out in the > draft-ietf-rtcweb-use-cases-and-requirements. > > > > For better understanding, I also want to point out that a TURN can have > two interfaces (acting like a router for media between different networks= ). > This allows to easier understand that can TURN servers can direct a best > media path (rather than just thinking that a TURN service is a device whi= ch > media just bounces against at one interface). > > > > And, we can also hope for that a TURN server becomes a (common) component > of a firewall, which would allow the firewall to understand that the medi= a > directed to it is RTC and should be prioritized whereby the firewall can > traffic shaped (back-off data traffic that may be filling its Internet > pipe) as well as e.g. set diffserve bits or take other measures to assist > proper quality handling thought the network. (These are common mechanisms > available and used in firewalls/NATs/access routers, but TURN servers are > not yet included such devices.) The same goes for access routers/default > gateways, DPIs in the transport network itself =E2=80=93 TURN servers inc= luded in > such points were media can pass and quality measures applied may/will be > very useful to get us WebRTC media with through networks without quality > destruction. > > > > From the RTCWEB mailing list September 20th (by me): > > An enterprise network that want to keep a restrictive firewall not > allowing UDP traffic, could provide a real-time path using a TURN server > paralleling the firewall, instead of tunneling RTP through always open ht= tp > or https ports resulting in RTP media over TCP =E2=80=93 with severe qual= ity > problems from TCP retransmissions of dropped packets. The TURN server > address is most easily provided in the same way as the IP address and DNS > address. (That would also put the right party in control =E2=80=93 The ne= twork > provider (here the enterprise) decides what is allowed on his network.) > > > > The browser should select which available TURN server address to use in > the following priority order, where ICE could be used to try several: > > > > 1) TURN server address configured in the browser by the user (special > cases, normally not used) > > 2) TURN server address configured by the network administrator via an > =E2=80=9Cadmin policy template=E2=80=9D > > 3) TURN server address supplied by DHCP or similar automatic network meth= od > > 4) TURN server address being supplied by the web application" > > > > > > And from yesterdays(!) > http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1= 4these enterprise things and necessity are spelled out in: > > > > F19 The browser must be able to use several STUN and TURN servers > > ---------------------------------------------------------------- > > > > A22 > > *3.3.5**. > Simple Video Communication Service, enterprise aspects* > > *3.3.5.1**. > Description* > > This use-case is similar to the Simple Video Communication Service > > use-case (Section 3.3.1 > ). > > > > What is added is aspects when using the service in enterprises. ICE > > is assumed in the further description of this use-case. > > > > An enterprise that uses a RTCWEB based web application for > > communication desires to audit all RTCWEB based application sessions > > used from inside the company towards any external peer. To be able > > to do this they deploy a TURN server that straddles the boundary > > between the internal and the external network. > > > > The firewall will block all attempts to use STUN with an external > > destination unless they go to the enterprise auditing TURN server. > > In cases where employees are using RTCWEB applications provided by an > > external service provider they still want the traffic to stay inside > > their internal network and in addition not load the straddling TURN > > server, thus they deploy a STUN server allowing the RTCWEB client to > > determine its server reflexive address on the internal side. Thus > > enabling cases where peers are both on the internal side to connect > > without the traffic leaving the internal network. It must be > > possible to configure the browsers used in the enterprise with > > network specific STUN and TURN servers. This should be possible to > > achieve by auto-configuration methods. The RTCWEB functionality will > > need to utilize both network specific STUN and TURN resources and > > STUN and TURN servers provisioned by the web application. > > *3.3.5.2**. > Additional Requirements* > > ---------------------------------------------------------------- > > REQ-ID DESCRIPTION > > ---------------------------------------------------------------- > > F20 The browser must support the use of STUN and TURN > > servers that are supplied by entities other than > > the web application (i.e. the network provider). > > ---------------------------------------------------------------- > > > > There are further requirement listed, helping us to understand the need > for auto discovery and a network provided TURN-server should be used to > ENFORCE that media takes that path (and thus, other paths e.g. suggested = by > the remote MUST not happen to be used). This is related to the mobility > aspect (valid even without the roaming idea): > 3.3.6. > Simple Video Communication Service, access change 3.3.6.1. > Description > > This use-case is almost identical to the > > Simple Video Communication Service use-case (Section 3.3.1 ). The > > difference is that the user changes network access during the > > session. > > > > The communication device used by one of the users has several network > > adapters (Ethernet, WiFi, Cellular). The communication device is > > accessing the Internet using Ethernet, but the user has to start a > > trip during the session. The communication device automatically > > changes to use WiFi when the Ethernet cable is removed and then moves > > to cellular access to the Internet when moving out of WiFi coverage. > > The session continues even though the access method changes. > > 3.3.6.2. > Additional Requirements > > ---------------------------------------------------------------- > > REQ-ID DESCRIPTION > > ---------------------------------------------------------------- > > F17 The communication session must survive across a > > change of the network interface used by the > > session > > ---------------------------------------------------------------- > > 3.3.7. > Simple Video Communication Service, QoS 3.3.7.1. > Description > > This use-case is almost identical to the > > Simple Video Communication Service, access change use-case > > (Section 3.3.6 ). The use of Quality of Service (QoS) = capabilities is > > added: > > > > The user in the previous use case that starts a trip is behind a > > common residential router that supports prioritization of traffic. > > In addition, the user's provider of cellular access has QoS support > > enabled. The user is able to take advantage of the QoS support both > > when accessing via the residential router and when using cellular. > > 3.3.7.2. > Additional Requirements > > ---------------------------------------------------------------- > > REQ-ID DESCRIPTION > > ---------------------------------------------------------------- > > F17 The communication session must survive across a > > change of the network interface used by the > > session > > ---------------------------------------------------------------- > > F22 The browser must be able to receive streams and > > data from multiple peers concurrently. > > ---------------------------------------------------------------- > > > > Further from the RTCWEB mailing list September 20th (by me): > > > > There are several reasons for a network service provider to supply a TURN > server as part of his offered access: > > - to keep media paths short, specifically not sending media outside its > own network to some distant application provided TURN server > > - to support mobility, i.e. you may want to move from a LAN with a > configured TURN server to accessing via WiFi or 3G/4G OTT channels > > - to offer a media path with better quality (than best effort data > traffic). > > Getting =E2=80=9CWebRTC-ready=E2=80=9D access and we look forward to tele= presence for > everyone. > > > > > > I hope this (a bit lengthy) summary of already thought-out and discussed > aspects/requirements will help us understand that the auto-discovered TUR= N > server is an ORDER from the enterprise and/or the NSP/ISP to send the > media through this TURN path, and that other media paths that may exist > MUST NOT BE USED. (That is why we especially have to watch/advice that > workable media paths proposed by the remote party not becomes used =E2=80= =9Cby > accident=E2=80=9D. > > > > /Karl > > > > > > *Fr=C3=A5n:* Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > > *Skickat:* den 13 februari 2014 04:37 > *Till:* Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal (mperumal= ) > *Kopia:* tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; > tram@ietf.org; Marc Blanchet; Dan Wing (dwing); Karl Stahl > *=C3=84mne:* RE: [tram] Milestone 3: TURN server auto-discovery mechanism= for > enterprise and ISPs > > > > Hi Andy, > > > > There are other ways to solve the problem for example using PCP. Can you > clarify how deploying a TURN server in the Enterprise protects the users > and the network ? > > > > -Tiru. > > *From:* tram [mailto:tram-bounces@ietf.org ] *On > Behalf Of *Hutton, Andrew > *Sent:* Thursday, February 13, 2014 1:00 AM > *To:* Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) > *Cc:* tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org= ; > Marc Blanchet; Dan Wing (dwing); Karl Stahl > *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism > for enterprise and ISPs > > > > The case where the TURN server is the only option may become common withi= n > enterprise networks and that might be deliberate enterprise policy becaus= e > it provides the better path (UDP through the F/W) and protects the users > and the network. > > > > Andy > > > > > > *From:* tram [mailto:tram-bounces@ietf.org ] *On > Behalf Of *Justin Uberti > *Sent:* 12 February 2014 17:46 > *To:* Muthu Arul Mozhi Perumal (mperumal) > *Cc:* tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org= ; > Marc Blanchet; Dan Wing (dwing); Karl Stahl > *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism > for enterprise and ISPs > > > > Agree. If TURN is indeed being provided for the user's benefit, the > client's ICE logic (based on RTT or similar) should result in it preferri= ng > the TURN path. > > > > On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) < > mperumal@cisco.com> wrote: > > Yes, I believe the second case is rare, but would be better than a rat > race b/w administrators trying to block p2p traffic and force it through = a > TURN server and apps/endpoints finding smarter ways to bypass them. > > > > Muthu > > > > *From:* Oleg Moskalenko [mailto:mom040267@gmail.com] > *Sent:* Wednesday, February 12, 2014 1:07 PM > *To:* Muthu Arul Mozhi Perumal (mperumal) > *Cc:* Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; > tram@ietf.org; Dan Wing (dwing); Simon Perreault > > > *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism > for enterprise and ISPs > > > > The TURN server has to be used when it is either the only option, or if i= t > provides a better path (I guess the second case is rather rare). > > > > On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) < > mperumal@cisco.com> wrote: > > +1 > > > > Forcing all traffic through a TURN server and expecting it would provide > the best user experience doesn't look the right approach. Instead, if a > path through a TURN server exists and does provide lower RTT, jitter etc, > being able to detect and use (or switch to) that path might be desirable.= . > > > > Muthu > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti > *Sent:* Wednesday, February 12, 2014 11:43 AM > *To:* Karl Stahl > *Cc:* tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); > Simon Perreault > *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism > for enterprise and ISPs > > > > Inline. > > > > On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl > wrote: > > Listening to this thread, I am afraid we are missing the very point and > necessity for this milestone! > > - There are severe NAT traversal and quality issues that should and can b= e > dealt with by a good auto-discovery mechanism and the right usage by the > turn client (the WebRTC browser) > > > > There are ways, not only: Enterprises or ISPs wishing to provide their > own TURN server, in an attempt to reduce so-called "triangle routing",nee= d > a new auto-discovery mechanism > > But also: - NSPs (Network Service Providers) want to provide a path where > the bandwidth of WebRTC is better coped with. > > - NSPs or Enterprises want to offer an Internet access quality pipe for > prioritized RTC (Real Time Communication) traffic. > > - Enterprises having restrictive firewalls, want to provide a UDP-path fo= r > WebRTC and possibly also for better quality where RTC do not compete with > data traffic. > > Also considering > > - Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4= G > OTT channels, all should be able to automatically offer their own optimal > TURN server > > > > This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80= =9D etc! It is not a > mistake, but the very need for this milestone! > > > > Again, it has not been demonstrated why TURN is the right technology here= , > compared to a more transparent flow identification tool like MALICE. We > don't force all HTTP requests to locate a HTTP proxy via anycast, I don't > see why we need to do the same for WebRTC. > > > > What are the hesitations raised here? > > > TURN primarily to identify WebRTC flows, as opposed to using it as a NA= T > traversal tool. This makes me concerned that we may be using the wrong > technology to solve the problem > > It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall > traversal problem associated with real-time communication (SIP at that > time). However, its largest flaw/problem is that quality things were not > (could not be?) considered. The method=E2=80=99s very idea (like all simi= lar > methods for getting RTC through ordinary NAT/Firewalls) is to fool the > media through a NAT/Firewall that is unaware of what is happening. Thus, > this is root of quality issues (and bandwidth allocation optimization) th= at > needs to be dealt with: Real-time traffic fighting with a data traffic > crowded congestion point. > > > > I think that "fooling" is an incorrect description. The NAT is supposed t= o > be transparent to the client. > > > > But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate > request for a suitable pipe for quality demanding real time traffic. J > > ICE is a pre-protocol you use because you want a path for real-time media > between parties. Here: The browser says knock knock, I want to get media > through (and of course with as good quality as required and possible). > > > > If the NAT/Firewall owner and network owner are allowed to see these > requests, they can help/assist in achieving the good media path. If they > are not aware, they cannot help! > > > > Hope this made it understandable on an overview level how this can become= =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D > > It is also the ONLY way I can see to achieve what we want to achieve and > should be the aim and requirement of this milestone. > > > > I am talking about general usage of WebRTC over Internet/mobile OTT (not > feeding WebRTC into application specific networks like IMS where other > methods may exist). > > > > This is good, not evil! > > > > If the hesitations are raised because of a belief/hope/wish that there ar= e > no or will not be severe quality issues =E2=80=9Cbecause it is all about > bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D et= c., I strongly object! > That is wrong and will be very detrimental for WebRTC usage. We already s= ee > it and I can give numerous examples of how much less quality demanding Vo= IP > is/is not handled quality wise and that it matters. And, what would be ba= d > considering quality issues and allowing/encouraging methods to deal with > them? > > > > If the hesitations are raised, because of suspicion that the methods we > may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to > protect income from carrier telephony traffic), I could understand and > would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At > least forward thinking carrier=E2=80=99s realize that already. Web RTC wi= ll happen. > Which customers want to pay for an access with blocked WebRTC? The > carrier=E2=80=99s offering/assuring good WebRTC will rather get the custo= mers and > income J. (Maybe the Web browser can detect and encourage this=E2=80=A6) > > > > If there are technical concerns of bad result, or better methods allowing > network providers and LAN managers to offer and inform the browser that > there are good media paths to be used, and that the web browser > automatically can chose those, then let us all understand those, so we ca= n > achieve what should be achieved by this milestone. > > > > Skype, Hangouts, Facetime are doing billions of minutes per week and the > Internet has not melted yet. If we need to do flow identification to allo= w > traffic to be prioritized, fine (see above regarding my preferred > approach), but forcing all WebRTC traffic through a MITM (TURN server) is= a > much bigger jump that I don't yet see the justification for. > > > > In short: TURN is a technology that is supposed to fade away with the mov= e > to IPv6. I don't think we want to make it a critical element of WebRTC. > > > > /Karl > > > > > > *Fr=C3=A5n:* Dan Wing [mailto:dwing@cisco.com] > *Skickat:* den 11 februari 2014 18:25 > *Till:* Marc Blanchet > *Kopia:* Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; > Simon Perreault > > > *=C3=84mne:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism= for > enterprise and ISPs > > > > > > On Feb 11, 2014, at 9:08 AM, Marc Blanchet > wrote: > > > > Le 2014-02-11 =C3=A0 00:39, Dan Wing a =C3=A9crit : > > > > > On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: > > > > Good to see there is a lot of interest for this milestone. But based on > the description here, it seems like we want to use TURN primarily to > identify WebRTC flows, as opposed to using it as a NAT traversal tool. Th= is > makes me concerned that we may be using the wrong technology to solve the > problem. > > > > +1. > > > > I would prefer allowing flows to establish themselves using their 'best' > path, and the best path is seldom through a TURN server. When we imagine > IPv6 in our future, we don't want to force an application-level proxy > (TURN) server on the path solely for traversing an IPv6 firewall. > > > > > > It seems this thread is conflating all the possible reasons / > justifications for TURN: > > * mobility > > * NAT traversal (both endpoints are behind endpoint-dependent mapping > NATs) > > * firewall traversal (firewall blocks UDP) > > * enhancing privacy > > > > Unfortunately the TURN server nor the endpoint really know which of those > use-cases is desired (by the user or by the IT network administrator) or > necessary (for the call to work at all). > > > > Dan, while I agree in principle, I doubt that a user could ever say "I > want mobility or I want NAT traversal". I think the user only want the ca= ll > to succeed, whatever the properties of its network point of attachment ar= e. > > > > So what can we do? Should the TURN server provide any and all services > the TURN client might possibly want, as that is what a robust TURN server > will do, and the endpoint should prefer TURN candidates over all others > because there might be some functionality / usefulness of TURN that the > user might gain through TURN (e.g., enhanced privacy)? > > > > -d > > > > > > > > This seems problematic. Perhaps we need a way to signal the desired > use-case ("trait"), or as Justin suggests, using a different technology f= or > some of these use-cases. > > > > -d > > > > > > > > > > On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl > wrote: > > Simon, > > Good questions - see inline below --> . > Some more thought is required! > > /Karl > > -----Ursprungligt meddelande----- > Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault > Skickat: den 10 februari 2014 15:16 > Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com > =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism f= or > enterprise and ISPs > > > Karl, > > It is great to see such enthusiasm! Thanks! > > I have a couple technical questions... > > Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > > - Note that to achieve some of the above points, TURN must be favored > > over STUN to enforce that the TURN-path actually is used. (The Anycast > > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) > > I understand the STUN vs TURN priority issue. But I don't see how anycast > affects it in any way. Can you please explain? > > --- Good point - I was a bit quick here (maybe too quick) > We have given this quite bit of thought, since even if a TURN server is > provided and discovered, CURRENT usage of ICE may suggest a candidate fro= m > the remote party that will make a connection without the need/usage of th= e > TURN server (that we wanted to be used for the good purposes listed). > > The only way we found around this, was to stop STUN through the IP defaul= t > gateway (like a restrictive Enterprise firewall does inhibiting ICE > connectivity, which others are concerned about...). Since the provisionin= g > of auto-discovery using the anycast mechanism, would be adding a route in= a > default gateway, adding a firewall rule to eat STUN packets would assure > that the provisioned TURN server actually becomes used (and not bypassed > "by accident"). (That was the thought behind the =E2=80=9Cautomatically= =E2=80=9D within > quotes.) > > BUT, since you brought up the question, assuming that we have the power t= o > enforce WebRTC usage of ICE, I believe a MUST requirement to use an > auto-discovered TURN server instead of STUN, would solve the same problem= . > However, thinking further (in relation to your next question - "anyone > could set up a badly-maintained" - enforcing such ICE usage may not be > good.) > > > > > - 3^rd The Anycast method below =E2=80=93 I see no problem > > > > It also has the advantage of encouraging (but not requiring) the > > STUN/TURN to be built in the default gateway or NAT/firewall/access > > router itself, with a second interface to a public IP address on the > > WAN side. (Current volume deployed, low cost NSP triple play modems > > usually have a quality assured level 2 or level 3 WAN pipe for just > > voice (and another for IPTV) =E2=80=93 The anycast discovered TURN-serv= er can > > be the access gateway to such quality pipe for WebRTC media, in a > > single NSP provided CPE, scaling from residential and up.) > > Suppose we define well-known anycast TURN server addresses. How would thi= s > not be subject to the same service quality issues that plagued 6to4? That > is, anyone could set up a badly-maintained, under-provisioned TURN server > and announce it over BGP to the world, as it was done for > 6to4 relays. Or just bad BGP outbound filter configuration. And how can w= e > prevent triangle routing? There is nothing guaranteeing that the anycast > server you see is being provided to you by your ISP, rather than a server > sitting on the other side of the planet. > > --- Good point - needs to be resolved. For this I don't have a ready > answer... > An auto-discovered TURN server must be trusted (whatever method it is > discovered by). We are trusting the one providing us with an IP address a= nd > default gateway anyway. It would be easy if we could reuse that trust, > instead of another mechanisms. > > Is there a good way for the browser to check that the anycast address is > not handled beyond the network service provider's default gateway? Ideas? > > > > > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --001a11368658a17b7d04f24e1b0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Karl,

You sent 23 messages to the list = on this same thread in the past few hours. This is not an effective way of = presenting your ideas; I myself have lost track of what you are hoping to a= ccomplish.

Right now the only currently viable mechanism for auto-= discovery is WPAD. If you think the anycast mechanism is worth pursuing, I = suggest writing it up as an I-D.

There have also been several mechanisms proposed for do= ing QoS provisioning, namely=C2=A0http://tools.ietf.org/searc= h/draft-penno-pcp-mobile-qos-00 and=C2=A0http://tools.ietf.org/html/draft-m= artinsen-tram-discuss-00. If you think those proposals are insufficient= , I suggest pointing out your concerns in threads specific to those documen= ts.

Justin




On Thu, Feb 13, 2014 at 4:04 AM, Karl Stahl <k= arl.stahl@intertex.se> wrote:

Note that some things being questioned in this discussion alread= y are in the draft-ietf-rtcweb-use-cases-and-requirements document (pointed= out below). I think this may clarify some things also=E2=80=A6

=C2=A0

=C2=A0

On the si= de of this TRAM-list, I also got this question:

> Regarding the enterprise case, I am not sure I follow your = argument.

> Do you mean that by setting up an enterpris= e TURN server, and open the firewall for media over UDP from/to TURN server= be the solution?

---- As we all = realize, that would of course not help or improve things

=C2=A0

The intended solution in the enterprise case has not yet been spelled out = in this TRAM-list discussion, so for better understanding, let me copy a fe= w things from the discussion in September/October on the RTCWEB-list and wh= at is (since long) spelled out in the draft-ietf-rtcweb-use-cases-and-requi= rements.

=C2=A0

For better understanding, I also want to point out that a TURN can have tw= o interfaces (acting like a router for media between different networks). T= his allows to easier understand that can TURN servers can direct a best med= ia path (rather than just thinking that a TURN service is a device which me= dia just bounces against at one interface).

=C2=A0

And, we can also hope for that a TURN server becomes a (common) component = of a firewall, which would allow the firewall to understand that the media = directed to it is RTC and should be prioritized whereby the firewall can tr= affic shaped (back-off data traffic that may be filling its Internet pipe) = as well as e.g. set diffserve bits or take other measures to assist proper = quality handling thought the network. (These are common mechanisms availabl= e and used in firewalls/NATs/access routers, but TURN servers are not yet i= ncluded such devices.) The same goes for access routers/default gateways, D= PIs in the transport network itself =E2=80=93 TURN servers included in such= points were media can pass and quality measures applied may/will be very u= seful to get us WebRTC media with through networks without quality destruct= ion.

=C2=A0

From the RTCWEB mailing list September 20th (by me):<= /u>

An enterprise network that want to keep a restricti= ve firewall not allowing UDP traffic, could provide a real-time path using = a TURN server paralleling the firewall, instead of tunneling RTP through al= ways open http or https ports resulting in RTP media over TCP =E2=80=93 wit= h severe quality problems from TCP retransmissions of dropped packets. The = TURN server address is most easily provided in the same way as the IP addre= ss and DNS address. (That would also put the right party in control =E2=80= =93 The network provider (here the enterprise) decides what is allowed on h= is network.)

=C2=A0

The browser should select which available TURN server address to use in= the following priority order, where ICE could be used to try several:

=C2=A0

1) TURN server address configured in the browser by the user (special c= ases, normally not used)

2)= TURN server address configured by the network administrator via an =E2=80= =9Cadmin policy template=E2=80=9D

3) TURN server address supplied by DHCP or similar = automatic network method

4)= TURN server address being supplied by the web application"<= /u>

=C2=A0

=C2=A0

And from yester= days(!) http://tools.ietf.org/html/draft-ietf= -rtcweb-use-cases-and-requirements-14 these enterprise things and neces= sity are spelled out in:

=C2=A0

F19=C2=A0=C2=A0=C2=A0=C2=A0 The browser must be= able to use several STUN and TURN servers

=C2=A0=C2=A0 --------------------------------------------------= --------------

=C2=A0

A22

3.3.= 5.=C2=A0 Simple Video Communication Service, enterprise aspects

3.3.5.1.=C2=A0 Description=

=C2=A0=C2=A0 This use-case is similar to the Simple Video Commu= nication Service

=C2=A0=C2=A0 use-case= (Section 3.3.1).=

=C2=A0

=C2=A0=C2=A0 What is= added is aspects when using the service in enterprises.=C2=A0 ICE

=C2=A0=C2=A0 is assumed in the further description of this use-= case.

=C2=A0

=C2=A0=C2=A0 An enterprise that uses a RTCWEB based web applica= tion for

=C2=A0=C2=A0 communication des= ires to audit all RTCWEB based application sessions

=C2=A0=C2=A0 used from inside the company towards any external = peer.=C2=A0 To be able

=C2=A0=C2=A0 to = do this they deploy a TURN server that straddles the boundary=

=C2=A0=C2=A0 between the internal and the external network.<= /u>

=C2=A0

=C2=A0=C2=A0 The firewall will block all attempts to use STUN w= ith an external

=C2=A0=C2=A0 destinat= ion unless they go to the enterprise auditing TURN server.

=C2=A0=C2=A0 In cases where employees are using RTCWEB applicat= ions provided by an

=C2=A0=C2=A0 extern= al service provider they still want the traffic to stay inside

=C2=A0=C2=A0 their internal network and in addition not load th= e straddling TURN

=C2=A0=C2=A0 server, = thus they deploy a STUN server allowing the RTCWEB client to<= /span>

=C2=A0=C2=A0 determine its server reflexive address on the inte= rnal side.=C2=A0 Thus

=C2=A0=C2=A0 enab= ling cases where peers are both on the internal side to connect

=C2=A0=C2=A0 without the traffic leaving the internal network.= =C2=A0 It must be

=C2=A0=C2=A0 possible= to configure the browsers used in the enterprise with=

=C2=A0=C2=A0 network specific STUN and TURN servers.=C2=A0 This= should be possible to

=C2=A0=C2=A0achi= eve by auto-configuration methods.=C2=A0 The RTCWEB functionality will

=C2=A0=C2=A0 need to utilize both network specific STUN and TUR= N resources and

=C2=A0=C2=A0 STUN and= TURN servers provisioned by the web application.

3.3.5.2.=C2=A0 Additional Require= ments

=C2=A0=C2=A0 --------------------------------------------------= --------------

=C2=A0=C2=A0 REQ-ID=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 DESCRIPTION

=C2=A0=C2=A0 --------------------------------------------------= --------------

=C2=A0=C2=A0 F20=C2=A0= =C2=A0=C2=A0=C2=A0 The browser must support the use of STUN and TURN=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 se= rvers that are supplied by entities other than

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the we= b application (i.e. the network provider).

=C2=A0=C2=A0 --------------------------------------------------= --------------

=C2=A0

There are furth= er requirement listed, helping us to understand the need for auto discovery= and a network provided TURN-server should be used to ENFORCE that media ta= kes that path (and thus, other paths e.g. suggested by the remote MUST not = happen to be used). This is related to the mobility aspect (valid even with= out the roaming idea):

3.3.6<= /span>.=C2=A0 Simple Video Communication Service, acc= ess change

3.= 3.6.1.=C2=A0 Description<= /h5> 
=C2=A0=C2=A0 This use-case is almost identical to th=
e
=C2=A0=C2=A0 Simple Vide=
o Communication Service use-case (Section 3.3.1).=C2=A0 The
=C2=A0=C2=A0 difference is that the user changes net=
work access during the
=C2=
=A0=C2=A0 session.
=
=C2=A0
=C2=A0=C2=A0 The communication device used by one of the =
users has several network
=
=C2=A0=C2=A0 adapters (Ethernet, WiFi, Cellular).=C2=A0 The communication d=
evice is
=C2=A0=C2=A0 accessing the Internet using Ethernet, =
but the user has to start a
=C2=A0=C2=A0 trip during the session.=C2=A0 The communication device auto=
matically
=C2=A0=C2=A0 changes to use WiFi when the Ethernet c=
able is removed and then moves
=C2=A0=C2=A0 to cellular access to the Internet when moving out of WiF=
i coverage.
=C2=A0=C2=A0 The session continues even though the a=
ccess method changes.
3.3.6.2.=C2=A0 Additional Requirements
=C2=A0=C2=A0 ---------------------------------------=
-------------------------
=
=C2=A0=C2=A0 REQ-ID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DESCRIPTION=

=C2=A0=C2=A0 --------------------------=
--------------------------------------
=C2=A0=C2=A0 F17=C2=A0=C2=A0=C2=A0=C2=A0 The communi=
cation session must survive across a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cha=
nge of the network interface used by the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 session
=C2=A0=C2=A0 ---------------------------------------=
-------------------------

3.3.7.=C2=A0 Simple Video Communication Service, QoS

3.= 3.7.1.=C2=A0 Description<= /h5> 
=C2=A0=C2=A0 This use-case is almost identical to th=
e
=C2=A0=C2=A0 Simple Vide=
o Communication Service, access change use-case
<= pre>=C2=A0=C2=A0 (Section 3.3.6).=C2=A0 The use of Quality of Service (QoS) capabili= ties is 
=C2=A0=C2=A0 added:
<=
span lang=3D"EN">=C2=A0
=
=C2=A0=C2=A0 The user in the previous use case that starts a trip is behind=
 a
=C2=A0=C2=A0 common residential router that supports=
 prioritization of traffic.
=C2=A0=C2=A0 In addition, the user's provider of cellular access has =
QoS support
=C2=A0=C2=A0 enabled.=C2=A0 The user is able to take=
 advantage of the QoS support both
=C2=A0=C2=A0 when accessing via the residential router and when us=
ing cellular.
3.= 3.7.2.=C2=A0 Additional Requirements= 
=C2=A0=C2=A0 ---------------------------------------=
-------------------------
=
=C2=A0=C2=A0 REQ-ID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DESCRIPTION=

=C2=A0=C2=A0 --------------------------=
--------------------------------------
=C2=A0=C2=A0 F17=C2=A0=C2=A0=C2=A0=C2=A0 The communi=
cation session must survive across a
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cha=
nge of the network interface used by the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 session
=C2=A0=C2=A0 ---------------------------------------=
-------------------------
=
=C2=A0=C2=A0 F22=C2=A0=C2=A0=C2=A0=C2=A0 The browser must be able to receiv=
e streams and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 data from multiple peers concurrently.
= 
=C2=A0=C2=A0 ---------------------------------------=
-------------------------

=C2=A0

Further from the RTCWE= B mailing list September 20th (by me):

=C2=A0

There are several reasons for a net= work service provider to supply a TURN server as part of his offered access= :

- to keep media paths short, specifically not sendi= ng media outside its own network to some distant application provided TURN = server

- to support mobilit= y, i.e. you may want to move from a LAN with a configured TURN server to ac= cessing via WiFi or 3G/4G OTT channels

- to offer a media path with better quality (than b= est effort data traffic).

G= etting =E2=80=9CWebRTC-ready=E2=80=9D access and we look forward to telepre= sence for everyone.

=C2=A0

=C2=A0

I hope this (a = bit lengthy) summary of already thought-out and discussed aspects/requireme= nts will help us understand that the auto-discovered TURN server is an ORDE= R from the enterprise and/or the NSP/ISP =C2=A0to send the media through th= is TURN path, and that other media paths that may exist MUST NOT BE USED. (= That is why we especially have to watch/advice that workable media paths pr= oposed by the remote party not becomes used =E2=80=9Cby accident=E2=80=9D.<= u>

=C2=A0

/Karl

=C2=A0

=C2=A0

Fr=C3=A5n: Tirumaleswar Reddy (ti= reddy) [mailto:tired= dy@cisco.com]

Skickat: den 13 februari 2014 04:3= 7
Till: Hutton, Andrew; Justin Uberti; Muthu Arul Moz= hi Perumal (mperumal)
Kopia: tireddy@icisco.com; Simon Perreault; Oleg Moskalenk= o; tram@ietf.org; Ma= rc Blanchet; Dan Wing (dwing); Karl Stahl
=C3=84mne: RE: [tram] Milestone 3: TURN server auto-discovery mechan= ism for enterprise and ISPs

=C2=A0

Hi Andy,

=

=C2= =A0

There are = other ways to solve the problem for example using PCP. Can you clarify how = deploying a TURN server in the Enterprise protects the users and the networ= k ?

=C2= =A0

-Tiru.

From: tram [mailto:tram-bounces@ietf.org] On = Behalf Of Hutton, Andrew
Sent: Thursday, February 13, 2014 1:00 AM
To: Justin Ubert= i; Muthu Arul Mozhi Perumal (mperumal)
Cc: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ie= tf.org; Marc Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

=C2=A0

The case where the TURN server is= the only option may become common within enterprise networks and that migh= t be deliberate enterprise policy because it provides the better path (UDP = through the F/W) and protects the users and the network.

=C2= =A0

Andy

=C2= =A0

=C2=A0

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: 12 February 2014 17:46
To: Muthu Arul Mozhi Perumal = (mperumal)
Cc: tireddy@icisco.com= ; Simon Perreault; Oleg Moskalenko; <= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">tram@ietf.org; Marc= Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

=C2=A0

Agree. If TURN is indeed being provided for the user&#= 39;s benefit, the client's ICE logic (based on RTT or similar) should r= esult in it preferring the TURN path.

= =C2=A0

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) &= lt;mperumal@cisco.c= om> wrote:

Yes, I believe the second case is= rare, but would be better than a rat race b/w administrators trying to blo= ck p2p traffic and force it through a TURN server and apps/endpoints findin= g smarter ways to bypass them.

=C2=A0

Muthu

=C2=A0

From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Wednesday, February 12, 2014 1:07 PM
To: Muthu Arul = Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl Stahl; = tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault


Subject: R= e: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise = and ISPs

=C2=A0

The TURN server has to be used when it is either = the only option, or if it provides a better path (I guess the second case i= s rather rare).

=C2=A0

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mper= umal) <mperumal@= cisco.com> wrote:

+1=

=C2=A0

Forcing all traffic through a TURN server a= nd expecting it would provide the best user experience doesn't look the= right approach. Instead, if a path through a TURN server exists and does p= rovide lower RTT, jitter etc, being able to detect and use (or switch to) t= hat path might be desirable..

=C2=A0

Muthu

=C2=A0

From: tram [mailto:tr= am-bounces@ietf.org] On Beh= alf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl=
Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault=
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs<= /p>

=C2=A0=

Inline.

=C2=A0=

On Tue, Feb 11,= 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

Liste= ning to this thread, I am afraid we are missing the very point and necessit= y for this milestone!

- There are sev= ere NAT traversal and quality issues that should and can be dealt with by a= good auto-discovery mechanism and the right usage by the turn client (the = WebRTC browser)

=C2=A0

There are ways, not only: Ente= rprises or ISPs wishing to provide their own TURN server, in an attempt to = reduce so-called "triangle routing",need a new auto-discovery mec= hanism

But also: - NSP= s (Network Service Providers) want to provide a path where the bandwidth of= WebRTC is better coped with.

- NSPs or = Enterprises want to offer an Internet access quality pipe for prioritized R= TC (Real Time Communication) traffic.

- Enterprises h= aving restrictive firewalls, want to provide a UDP-path for WebRTC and poss= ibly also for better quality where RTC do not compete with data traffic.

Also cons= idering

- Mobility; It is common to move from = a LAN to accessing via WiFi or 3G/4G OTT channels, all should be able to au= tomatically offer their own optimal TURN server=

=C2=A0

This leads us into =C2=A0=E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80= =9D etc! It is not a mistake, but the very need = for this milestone!=

=C2=A0<= u>

Aga= in, it has not been demonstrated why TURN is the right technology here, com= pared to a more transparent flow identification tool like MALICE. We don= 9;t force all HTTP requests to locate a HTTP proxy via anycast, I don't= see why we need to do the same for WebRTC.=C2=A0

=C2=A0

What are the he= sitations raised here?

=

> TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. This= makes me concerned that we may be using the wrong technology to solve the = problem

It is cor= rect that ICE/STUN/TURN was designed to address the NAT/Firewall traversal = problem associated with real-time communication (SIP at that time). However= , its largest flaw/problem is that quality things were not (could not be?) = considered. The method=E2=80=99s very idea (like all similar methods for ge= tting RTC through ordinary NAT/Firewalls) is to fool the media through a NA= T/Firewall that is unaware of what is happening. Thus, this is root of qual= ity issues (and bandwidth allocation optimization) that needs to be dealt w= ith: Real-time traffic fighting with a data traffic crowded congestion poin= t.

= =C2=A0

I think that "fooling" is an incorrect description. Th= e NAT is supposed to be transparent to the client.

=C2=A0

But, a BLESSING= of ICE/STUN/TURN is that it can be seen as a legitimate request for a suit= able pipe for quality demanding real time traffic. J

ICE is a pre-pr= otocol you use because you want a path for real-time media between parties.= Here: The browser says knock knock, I want to get media through (and of co= urse with as good quality as required and possible).

=C2=A0

If the NAT/Firewall owner and network owner ar= e allowed to see these requests, they can help/assist in achieving the good= media path. If they are not aware, they cannot help!

=C2=A0=

Hope this made = it understandable on an overview level how this can become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D=

It is also the = ONLY way I can see to achieve what we want to achieve and should be the aim= and requirement of this milestone.

=C2=A0

I am talking about general usage of WebRTC ove= r Internet/mobile OTT (not feeding WebRTC into application specific network= s like IMS where other methods may exist). <= /u>

=C2=A0

This is good, not evil!

=C2=A0

If the hesitations are raised because of a bel= ief/hope/wish that there are no or will not be severe quality issues =E2=80= =9Cbecause it is all about bandwidth=E2=80=9D, =E2=80=9Cit will resolve its= elf with time=E2=80=9D etc., I strongly object! That is wrong and will be v= ery detrimental for WebRTC usage. We already see it and I can give numerous= examples of how much less quality demanding VoIP is/is not handled quality= wise and that it matters. And, what would be bad considering quality issue= s and allowing/encouraging methods to deal with them?

=C2=A0=

If the hesitati= ons are raised, because of suspicion that the methods we may recommend may = be misused to stop/block/destroy WebRTC usage (e.g. to protect income from = carrier telephony traffic), I could understand and would fight the same bat= tle. But hopefully, those days are (soon) over =E2=80=93 At least forward t= hinking carrier=E2=80=99s realize that already. Web RTC will happen. Which = customers want to pay for an access with blocked WebRTC? The carrier=E2=80= =99s offering/assuring good WebRTC will rather get the customers and income= J. (Maybe the Web= browser can detect and encourage this=E2=80=A6)=C2=A0

=C2=A0=

If there are te= chnical concerns of bad result, or better methods allowing network provider= s and LAN managers to offer and inform the browser that there are good medi= a paths to be used, and that the web browser automatically can chose those,= then let us all understand those, so we can achieve what should be achieve= d by this milestone.

= =C2=A0

Skype, Hangouts, Facetime are doing billions of minutes per week= and the Internet has not melted yet. If we need to do flow identification = to allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) is a= much bigger jump that I don't yet see the justification for.=

=C2=A0=

In short:= TURN is a technology that is supposed to fade away with the move to IPv6. = I don't think we want to make it a critical element of WebRTC.

=C2=A0

/Karl

=C2=A0

=C2=A0

Fr=C3=A5n:<= span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"= ;,"sans-serif""> Dan Wing [mailto:dwing@cisco.c= om]
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; Simon Pe= rreault


=C3=84mne: Re: [tram] Milestone= 3: TURN server auto-discovery mechanism for enterprise and ISPs

=C2=A0

= =C2=A0

On Feb 11, 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

=C2=A0

Le 2014-02= -11 =C3=A0 00:39, Dan Wing <dwing@cisco.com<= /span>> a =C3=A9crit :

=C2=A0


On Feb 10, 2014, at 5:30 PM, Justin Uberti <= juberti@google.com> wrote:=

=C2=A0

Good to see there is a lot of interest for this milestone. But based on= the description here, it seems like we want to use TURN primarily to ident= ify WebRTC flows, as opposed to using it as a NAT traversal tool. This make= s me concerned that we may be using the wrong technology to solve the probl= em.

=C2=A0

+1.

=C2=A0

I would prefer allowing flows to establish themselves using their '= ;best' path, and the best path is seldom through a TURN server. =C2=A0W= hen we imagine IPv6 in our future, we don't want to force an applicatio= n-level proxy (TURN) server on the path solely for traversing an IPv6 firew= all.

=C2=A0

=C2=A0

It seems this thread is con= flating all the possible reasons / justifications for TURN:

=C2=A0 * mobility

=C2=A0 * NAT traversal (both endpoints are behind endpoint-= dependent mapping NATs)

=C2=A0 *=C2=A0firewall trav= ersal (firewall blocks UDP)

=C2=A0 * enhancing privacy

= =C2=A0

Unfortunately the TURN serv= er nor the endpoint really know which of those use-cases is desired (by the= user or by the IT network administrator) or necessary (for the call to wor= k at all).

=C2=A0<= u>

Dan, while I agree in pr= inciple, I doubt that a user could ever say "I want mobility or I want= NAT traversal". I think the user only want the call to succeed, whate= ver the properties of its network point of attachment are.

=C2=A0

So what can we do?= =C2=A0Should the TURN server provide any and all services the TURN client = might possibly want, as that is what a robust TURN server will do, and the = endpoint should prefer TURN candidates over all others because there might = be some functionality / usefulness of TURN that the user might gain through= TURN (e.g., enhanced privacy)?

=C2=A0=

-d=

=C2=A0

=C2=A0=

=C2=A0

=C2=A0This seems problematic= . =C2=A0Perhaps we need a way to signal the desired use-case ("trait&q= uot;), or as Justin suggests, using a different technology for some of thes= e use-cases.

=C2=A0

-d

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 10, 2014 at 3:18 PM, = Karl Stahl=C2=A0<karl.stahl@inter= tex.se>=C2=A0wrote:

Simon,

Good questions - see inl= ine below --> .
Some more thought is required!

/Karl

--= ---Ursprungligt meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounces@= ietf.org] F=C3=B6r Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl;=C2=A0tram@ietf.org;=C2=A0tireddy@icisco.com
=C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for= enterprise and ISPs


Karl,

It is great to see such enthusiasm! Thanks!

I have a co= uple technical questions...

Le 2014-02-08 08:11, Karl Stahl a =C3=A9= crit :
> - Note that to achieve some of the above points, TURN must b= e favored
> over STUN to enforce that the TURN-path actually is used. (The Anycast=
> method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.= )

I understand the STUN vs TURN priority issue. But I don't see = how anycast affects it in any way. Can you please explain?

--- Good point - I was a bit qui= ck here (maybe too quick)
We have given this quite bit of thought, since= even if a TURN server is provided and discovered, CURRENT usage of ICE may= suggest a candidate from the remote party that will make a connection with= out the need/usage of the TURN server (that we wanted to be used for the go= od purposes listed).

The only way we found around this, was to stop STUN through the IP defa= ult gateway (like a restrictive Enterprise firewall does inhibiting ICE con= nectivity, which others are concerned about...). Since the provisioning of = auto-discovery using the anycast mechanism, would be adding a route in a de= fault gateway, adding a firewall rule to eat STUN packets would assure that= the provisioned TURN server actually becomes used (and not bypassed "= by accident"). (That was the thought behind the =E2=80=9Cautomatically= =E2=80=9D within quotes.)

BUT, since you brought up the question, assuming that we have the power= to enforce WebRTC usage of ICE, I believe a MUST requirement to use an aut= o-discovered TURN server instead of STUN, would solve the same problem. How= ever, thinking further (in relation to your next question - "anyone co= uld set up a badly-maintained" - enforcing such ICE usage may not be g= ood.)


> - 3^rd The Anycast method below =E2=80=93 I see no problem
&g= t;
> It also has the advantage of encouraging (but not requiring) the=
> STUN/TURN to be built in the default gateway or NAT/firewall/access> router itself, with a second interface to a public IP address on the<= br>> WAN side. (Current volume deployed, low cost NSP triple play modems=
> usually have a quality assured level 2 or level 3 WAN pipe for just> voice (and another for IPTV) =E2=80=93 The anycast discovered TURN-se= rver can
> be the access gateway to such quality pipe for WebRTC medi= a, in a
> single NSP provided CPE, scaling from residential and up.)

Supp= ose we define well-known anycast TURN server addresses. How would this not = be subject to the same service quality issues that plagued 6to4? That is, a= nyone could set up a badly-maintained, under-provisioned TURN server and an= nounce it over BGP to the world, as it was done for
6to4 relays. Or just bad BGP outbound filter configuration. And how can we = prevent triangle routing? There is nothing guaranteeing that the anycast se= rver you see is being provided to you by your ISP, rather than a server sit= ting on the other side of the planet.=

--- Good point - needs to be res= olved. For this I don't have a ready answer...
An auto-discovered TU= RN server must be trusted (whatever method it is discovered by). We are tru= sting the one providing us with an IP address and default gateway anyway. I= t would be easy if we could reuse that trust, instead of another mechanisms= .

Is there a good way for the browser to check that the anycast address i= s not handled beyond the network service provider's default gateway? Id= eas?




Thanks,
Simon
--
DTN made easy, lean, an= d smart -->=C2=A0http://postel= lation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0-->=C2=A0<= span lang=3D"SV" style=3D"font-size:9.0pt;font-family:"Helvetica"= ,"sans-serif"">http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -->=C2= =A0http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org https://www.ietf.org/ma= ilman/listinfo/tram

_______________________________________________
tram mailing listtram@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tram

=C2=A0

_______________________________________________
tram mailing list
tram@ietf.org=
https://www.ietf.org/ma= ilman/listinfo/tram


____________________________= ___________________
tram mailing list
t= ram@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tram

=C2=A0

=C2=A0

<= p class=3D"MsoNormal"> =C2=A0


_______________________________________________
t= ram mailing list
tram@ietf.org
https= ://www.ietf.org/mailman/listinfo/tram

=C2=A0

=C2=A0


____= ___________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--001a11368658a17b7d04f24e1b0b-- From nobody Thu Feb 13 10:53:55 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3FA1A03FA for ; Thu, 13 Feb 2014 10:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 Zu2fu8NhZ6kk for ; Thu, 13 Feb 2014 10:52:59 -0800 (PST) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 612061A03DE for ; Thu, 13 Feb 2014 10:52:59 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id m1so13192543oag.34 for ; Thu, 13 Feb 2014 10:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=D3y5+ky1uPO9lwLCBGBruSr/RE7ZA7S7gaKEP+9GVAk=; b=RRRq1lfw8hBkwT013Ltj4FJL2ZnhDS3G9lVYI5a/0MxyCFsif96xvp3IMtRhVrC0HM h/3SDnHznSX9jLRmI8mvVHRuWKGjxWrdubE0R81MADY8fuD6iFipNlMlgxPHfGwZExZy NLBo86dWrNyX5uB1Avnv6VqFJkxHR39LneOpe/G9WrkpHHlSjNtwjmpawqEUgHMhjH/e I7sa1gTDWyPXjtmi1eEByd34Kow0drSdBQ9CVkbUfaKRsFSnZgdHtir8YGzMbPervH98 na0DxqxrD/4FSdHxnwL1B0kP5eAYoOx1iEF6lA9hEYKllWOUCF6vnZjJ9tRV9KLOX6+R 3rsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=D3y5+ky1uPO9lwLCBGBruSr/RE7ZA7S7gaKEP+9GVAk=; b=fkxA6XDv2hlvqTwcPzUTdY1zVYiycVh5rFOs3kmE93U8o8dd+ZhtwHtnEQQ2XBnaVp YUCEhd2iLcKJYAZWT7B28BJ9x6zT/8OoWaqAxvms34Kr1pV6Ec9reoyO2yll/t2PoBJd Wy9D/y27l4PAriTx7NTCRU/KJ2M9oQqrR1FkOq2K/3uO4l4+pE2kE5C2IpSKbpuASBaK kFd5IR7blEm1m61Hp/kYvqW0kCo/N2Qir8CgxPnaXEYxCHs0lWL8j42fMBzjSDw1EOnN ue+apiWUGFXECuR9BCa8mlkgaehzpzsrucn/uiTgZJ/0ST9dFjOKQidpbslpnzHR2fZ9 PMzQ== X-Gm-Message-State: ALoCoQkNWNigTrZeZYxJBckCRRaTus2WzlMCnHBMtg0POnBMHsdbvRnf/7Bh67aC6eoKYoowswAZZ94UTr6XNhLfpRa9MXRwl9BG630tR8Fkkmknus7yrNFT6NlvLZ8Ry3niJ4/xYUoyCf0ohAWEU98i/PTup/B5gjqGdk8LuxgmID3Jysylb+UGT0TlWIW1POnCPKFqjeJj X-Received: by 10.182.87.42 with SMTP id u10mr2551726obz.22.1392317577773; Thu, 13 Feb 2014 10:52:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.96.230 with HTTP; Thu, 13 Feb 2014 10:52:37 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> <52fccc18.6501430a.3f96.ffffa2f0SMTPIN_ADDED_BROKEN@mx.google.com> From: Justin Uberti Date: Thu, 13 Feb 2014 10:52:37 -0800 Message-ID: To: Karl Stahl Content-Type: multipart/alternative; boundary=089e013cba62a36a6d04f24e3208 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/koY4UDgTmDbAPN9mcRuj_Uafti4 X-Mailman-Approved-At: Thu, 13 Feb 2014 10:53:49 -0800 Cc: "tireddy@icisco.com" , Simon Perreault , Oleg Moskalenko , "tram@ietf.org" , "Muthu Arul Mozhi Perumal \(mperumal\)" , "Hutton, Andrew" , "Tirumaleswar Reddy \(tireddy\)" , Marc Blanchet , "Dan Wing \(dwing\)" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:53:08 -0000 --089e013cba62a36a6d04f24e3208 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 13, 2014 at 10:45 AM, Justin Uberti wrote: > Karl, > > You sent 23 messages to the list on this same thread in the past few > hours. This is not an effective way of presenting your ideas; I myself ha= ve > lost track of what you are hoping to accomplish. > > Right now the only currently viable mechanism for auto-discovery is WPAD. > If you think the anycast mechanism is worth pursuing, I suggest writing i= t > up as an I-D. > I now see that http://www.ietf.org/id/draft-patil-tram-turn-serv-disc-00.tx= tcovers the anycast mechanism. > > There have also been several mechanisms proposed for doing QoS > provisioning, namely > http://tools.ietf.org/search/draft-penno-pcp-mobile-qos-00 and > http://tools.ietf.org/html/draft-martinsen-tram-discuss-00. If you think > those proposals are insufficient, I suggest pointing out your concerns in > threads specific to those documents. > > Justin > > > > > On Thu, Feb 13, 2014 at 4:04 AM, Karl Stahl wrote= : > >> Note that some things being questioned in this discussion already are in >> the draft-ietf-rtcweb-use-cases-and-requirements document (pointed out >> below). I think this may clarify some things also=E2=80=A6 >> >> >> >> >> >> On the side of this TRAM-list, I also got this question: >> >> > Regarding the enterprise case, I am not sure I follow your argument. >> >> > Do you mean that by setting up an enterprise TURN server, and open the >> firewall for media over UDP from/to TURN server be the solution? >> >> ---- As we all realize, that would of course not help or improve things >> >> >> >> The intended solution in the enterprise case has not yet been spelled ou= t >> in this TRAM-list discussion, so for better understanding, let me copy a >> few things from the discussion in September/October on the RTCWEB-list a= nd >> what is (since long) spelled out in the >> draft-ietf-rtcweb-use-cases-and-requirements. >> >> >> >> For better understanding, I also want to point out that a TURN can have >> two interfaces (acting like a router for media between different network= s). >> This allows to easier understand that can TURN servers can direct a best >> media path (rather than just thinking that a TURN service is a device wh= ich >> media just bounces against at one interface). >> >> >> >> And, we can also hope for that a TURN server becomes a (common) componen= t >> of a firewall, which would allow the firewall to understand that the med= ia >> directed to it is RTC and should be prioritized whereby the firewall can >> traffic shaped (back-off data traffic that may be filling its Internet >> pipe) as well as e.g. set diffserve bits or take other measures to assis= t >> proper quality handling thought the network. (These are common mechanism= s >> available and used in firewalls/NATs/access routers, but TURN servers ar= e >> not yet included such devices.) The same goes for access routers/default >> gateways, DPIs in the transport network itself =E2=80=93 TURN servers in= cluded in >> such points were media can pass and quality measures applied may/will be >> very useful to get us WebRTC media with through networks without quality >> destruction. >> >> >> >> From the RTCWEB mailing list September 20th (by me): >> >> An enterprise network that want to keep a restrictive firewall not >> allowing UDP traffic, could provide a real-time path using a TURN server >> paralleling the firewall, instead of tunneling RTP through always open h= ttp >> or https ports resulting in RTP media over TCP =E2=80=93 with severe qua= lity >> problems from TCP retransmissions of dropped packets. The TURN server >> address is most easily provided in the same way as the IP address and DN= S >> address. (That would also put the right party in control =E2=80=93 The n= etwork >> provider (here the enterprise) decides what is allowed on his network.) >> >> >> >> The browser should select which available TURN server address to use in >> the following priority order, where ICE could be used to try several: >> >> >> >> 1) TURN server address configured in the browser by the user (special >> cases, normally not used) >> >> 2) TURN server address configured by the network administrator via an >> =E2=80=9Cadmin policy template=E2=80=9D >> >> 3) TURN server address supplied by DHCP or similar automatic network >> method >> >> 4) TURN server address being supplied by the web application" >> >> >> >> >> >> And from yesterdays(!) >> http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-= 14these enterprise things and necessity are spelled out in: >> >> >> >> F19 The browser must be able to use several STUN and TURN servers >> >> ---------------------------------------------------------------- >> >> >> >> A22 >> >> *3.3.5**. >> Simple Video Communication Service, enterprise aspects* >> >> *3.3.5.1**. >> Description* >> >> This use-case is similar to the Simple Video Communication Service >> >> use-case (Section 3.3.1 >> ). >> >> >> >> What is added is aspects when using the service in enterprises. ICE >> >> is assumed in the further description of this use-case. >> >> >> >> An enterprise that uses a RTCWEB based web application for >> >> communication desires to audit all RTCWEB based application sessions >> >> used from inside the company towards any external peer. To be able >> >> to do this they deploy a TURN server that straddles the boundary >> >> between the internal and the external network. >> >> >> >> The firewall will block all attempts to use STUN with an external >> >> destination unless they go to the enterprise auditing TURN server. >> >> In cases where employees are using RTCWEB applications provided by an >> >> external service provider they still want the traffic to stay inside >> >> their internal network and in addition not load the straddling TURN >> >> server, thus they deploy a STUN server allowing the RTCWEB client to >> >> determine its server reflexive address on the internal side. Thus >> >> enabling cases where peers are both on the internal side to connect >> >> without the traffic leaving the internal network. It must be >> >> possible to configure the browsers used in the enterprise with >> >> network specific STUN and TURN servers. This should be possible to >> >> achieve by auto-configuration methods. The RTCWEB functionality will >> >> need to utilize both network specific STUN and TURN resources and >> >> STUN and TURN servers provisioned by the web application. >> >> *3.3.5.2**. >> Additional Requirements* >> >> ---------------------------------------------------------------- >> >> REQ-ID DESCRIPTION >> >> ---------------------------------------------------------------- >> >> F20 The browser must support the use of STUN and TURN >> >> servers that are supplied by entities other than >> >> the web application (i.e. the network provider). >> >> ---------------------------------------------------------------- >> >> >> >> There are further requirement listed, helping us to understand the need >> for auto discovery and a network provided TURN-server should be used to >> ENFORCE that media takes that path (and thus, other paths e.g. suggested= by >> the remote MUST not happen to be used). This is related to the mobility >> aspect (valid even without the roaming idea): >> 3.3.6. >> Simple Video Communication Service, access change 3.3.6.1. >> Description >> >> This use-case is almost identical to the >> >> Simple Video Communication Service use-case (Section 3.3.1 ). The >> >> difference is that the user changes network access during the >> >> session. >> >> >> >> The communication device used by one of the users has several network >> >> adapters (Ethernet, WiFi, Cellular). The communication device is >> >> accessing the Internet using Ethernet, but the user has to start a >> >> trip during the session. The communication device automatically >> >> changes to use WiFi when the Ethernet cable is removed and then moves >> >> to cellular access to the Internet when moving out of WiFi coverage. >> >> The session continues even though the access method changes. >> >> 3.3.6.2. >> Additional Requirements >> >> ---------------------------------------------------------------- >> >> REQ-ID DESCRIPTION >> >> ---------------------------------------------------------------- >> >> F17 The communication session must survive across a >> >> change of the network interface used by the >> >> session >> >> ---------------------------------------------------------------- >> >> 3.3.7. >> Simple Video Communication Service, QoS 3.3.7.1. >> Description >> >> This use-case is almost identical to the >> >> Simple Video Communication Service, access change use-case >> >> (Section 3.3.6 ). The use of Quality of Service (QoS)= capabilities is >> >> added: >> >> >> >> The user in the previous use case that starts a trip is behind a >> >> common residential router that supports prioritization of traffic. >> >> In addition, the user's provider of cellular access has QoS support >> >> enabled. The user is able to take advantage of the QoS support both >> >> when accessing via the residential router and when using cellular. >> >> 3.3.7.2. >> Additional Requirements >> >> ---------------------------------------------------------------- >> >> REQ-ID DESCRIPTION >> >> ---------------------------------------------------------------- >> >> F17 The communication session must survive across a >> >> change of the network interface used by the >> >> session >> >> ---------------------------------------------------------------- >> >> F22 The browser must be able to receive streams and >> >> data from multiple peers concurrently. >> >> ---------------------------------------------------------------- >> >> >> >> Further from the RTCWEB mailing list September 20th (by me): >> >> >> >> There are several reasons for a network service provider to supply a TUR= N >> server as part of his offered access: >> >> - to keep media paths short, specifically not sending media outside its >> own network to some distant application provided TURN server >> >> - to support mobility, i.e. you may want to move from a LAN with a >> configured TURN server to accessing via WiFi or 3G/4G OTT channels >> >> - to offer a media path with better quality (than best effort data >> traffic). >> >> Getting =E2=80=9CWebRTC-ready=E2=80=9D access and we look forward to tel= epresence for >> everyone. >> >> >> >> >> >> I hope this (a bit lengthy) summary of already thought-out and discussed >> aspects/requirements will help us understand that the auto-discovered TU= RN >> server is an ORDER from the enterprise and/or the NSP/ISP to send the >> media through this TURN path, and that other media paths that may exist >> MUST NOT BE USED. (That is why we especially have to watch/advice that >> workable media paths proposed by the remote party not becomes used =E2= =80=9Cby >> accident=E2=80=9D. >> >> >> >> /Karl >> >> >> >> >> >> *Fr=C3=A5n:* Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] >> >> *Skickat:* den 13 februari 2014 04:37 >> *Till:* Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal >> (mperumal) >> *Kopia:* tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; >> tram@ietf.org; Marc Blanchet; Dan Wing (dwing); Karl Stahl >> *=C3=84mne:* RE: [tram] Milestone 3: TURN server auto-discovery mechanis= m for >> enterprise and ISPs >> >> >> >> Hi Andy, >> >> >> >> There are other ways to solve the problem for example using PCP. Can you >> clarify how deploying a TURN server in the Enterprise protects the users >> and the network ? >> >> >> >> -Tiru. >> >> *From:* tram [mailto:tram-bounces@ietf.org ] *On >> Behalf Of *Hutton, Andrew >> *Sent:* Thursday, February 13, 2014 1:00 AM >> *To:* Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) >> *Cc:* tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.or= g; >> Marc Blanchet; Dan Wing (dwing); Karl Stahl >> *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism >> for enterprise and ISPs >> >> >> >> The case where the TURN server is the only option may become common >> within enterprise networks and that might be deliberate enterprise polic= y >> because it provides the better path (UDP through the F/W) and protects t= he >> users and the network. >> >> >> >> Andy >> >> >> >> >> >> *From:* tram [mailto:tram-bounces@ietf.org ] *On >> Behalf Of *Justin Uberti >> *Sent:* 12 February 2014 17:46 >> *To:* Muthu Arul Mozhi Perumal (mperumal) >> *Cc:* tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.or= g; >> Marc Blanchet; Dan Wing (dwing); Karl Stahl >> *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism >> for enterprise and ISPs >> >> >> >> Agree. If TURN is indeed being provided for the user's benefit, the >> client's ICE logic (based on RTT or similar) should result in it preferr= ing >> the TURN path. >> >> >> >> On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) < >> mperumal@cisco.com> wrote: >> >> Yes, I believe the second case is rare, but would be better than a rat >> race b/w administrators trying to block p2p traffic and force it through= a >> TURN server and apps/endpoints finding smarter ways to bypass them. >> >> >> >> Muthu >> >> >> >> *From:* Oleg Moskalenko [mailto:mom040267@gmail.com] >> *Sent:* Wednesday, February 12, 2014 1:07 PM >> *To:* Muthu Arul Mozhi Perumal (mperumal) >> *Cc:* Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; >> tram@ietf.org; Dan Wing (dwing); Simon Perreault >> >> >> *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism >> for enterprise and ISPs >> >> >> >> The TURN server has to be used when it is either the only option, or if >> it provides a better path (I guess the second case is rather rare). >> >> >> >> On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) < >> mperumal@cisco.com> wrote: >> >> +1 >> >> >> >> Forcing all traffic through a TURN server and expecting it would provide >> the best user experience doesn't look the right approach. Instead, if a >> path through a TURN server exists and does provide lower RTT, jitter etc= , >> being able to detect and use (or switch to) that path might be desirable= .. >> >> >> >> Muthu >> >> >> >> *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Justin Uberti >> *Sent:* Wednesday, February 12, 2014 11:43 AM >> *To:* Karl Stahl >> *Cc:* tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing >> (dwing); Simon Perreault >> *Subject:* Re: [tram] Milestone 3: TURN server auto-discovery mechanism >> for enterprise and ISPs >> >> >> >> Inline. >> >> >> >> On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl >> wrote: >> >> Listening to this thread, I am afraid we are missing the very point and >> necessity for this milestone! >> >> - There are severe NAT traversal and quality issues that should and can >> be dealt with by a good auto-discovery mechanism and the right usage by = the >> turn client (the WebRTC browser) >> >> >> >> There are ways, not only: Enterprises or ISPs wishing to provide their >> own TURN server, in an attempt to reduce so-called "triangle routing",ne= ed >> a new auto-discovery mechanism >> >> But also: - NSPs (Network Service Providers) want to provide a path wher= e >> the bandwidth of WebRTC is better coped with. >> >> - NSPs or Enterprises want to offer an Internet access quality pipe for >> prioritized RTC (Real Time Communication) traffic. >> >> - Enterprises having restrictive firewalls, want to provide a UDP-path >> for WebRTC and possibly also for better quality where RTC do not compete >> with data traffic. >> >> Also considering >> >> - Mobility; It is common to move from a LAN to accessing via WiFi or >> 3G/4G OTT channels, all should be able to automatically offer their own >> optimal TURN server >> >> >> >> This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80= =9D etc! It is not a >> mistake, but the very need for this milestone! >> >> >> >> Again, it has not been demonstrated why TURN is the right technology >> here, compared to a more transparent flow identification tool like MALIC= E. >> We don't force all HTTP requests to locate a HTTP proxy via anycast, I >> don't see why we need to do the same for WebRTC. >> >> >> >> What are the hesitations raised here? >> >> > TURN primarily to identify WebRTC flows, as opposed to using it as a >> NAT traversal tool. This makes me concerned that we may be using the wro= ng >> technology to solve the problem >> >> It is correct that ICE/STUN/TURN was designed to address the NAT/Firewal= l >> traversal problem associated with real-time communication (SIP at that >> time). However, its largest flaw/problem is that quality things were not >> (could not be?) considered. The method=E2=80=99s very idea (like all sim= ilar >> methods for getting RTC through ordinary NAT/Firewalls) is to fool the >> media through a NAT/Firewall that is unaware of what is happening. Thus, >> this is root of quality issues (and bandwidth allocation optimization) t= hat >> needs to be dealt with: Real-time traffic fighting with a data traffic >> crowded congestion point. >> >> >> >> I think that "fooling" is an incorrect description. The NAT is supposed >> to be transparent to the client. >> >> >> >> But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate >> request for a suitable pipe for quality demanding real time traffic. J >> >> ICE is a pre-protocol you use because you want a path for real-time medi= a >> between parties. Here: The browser says knock knock, I want to get media >> through (and of course with as good quality as required and possible). >> >> >> >> If the NAT/Firewall owner and network owner are allowed to see these >> requests, they can help/assist in achieving the good media path. If they >> are not aware, they cannot help! >> >> >> >> Hope this made it understandable on an overview level how this can becom= e=E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D >> >> It is also the ONLY way I can see to achieve what we want to achieve and >> should be the aim and requirement of this milestone. >> >> >> >> I am talking about general usage of WebRTC over Internet/mobile OTT (not >> feeding WebRTC into application specific networks like IMS where other >> methods may exist). >> >> >> >> This is good, not evil! >> >> >> >> If the hesitations are raised because of a belief/hope/wish that there >> are no or will not be severe quality issues =E2=80=9Cbecause it is all a= bout >> bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D e= tc., I strongly object! >> That is wrong and will be very detrimental for WebRTC usage. We already = see >> it and I can give numerous examples of how much less quality demanding V= oIP >> is/is not handled quality wise and that it matters. And, what would be b= ad >> considering quality issues and allowing/encouraging methods to deal with >> them? >> >> >> >> If the hesitations are raised, because of suspicion that the methods we >> may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to >> protect income from carrier telephony traffic), I could understand and >> would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At >> least forward thinking carrier=E2=80=99s realize that already. Web RTC w= ill happen. >> Which customers want to pay for an access with blocked WebRTC? The >> carrier=E2=80=99s offering/assuring good WebRTC will rather get the cust= omers and >> income J. (Maybe the Web browser can detect and encourage this=E2=80=A6) >> >> >> >> If there are technical concerns of bad result, or better methods allowin= g >> network providers and LAN managers to offer and inform the browser that >> there are good media paths to be used, and that the web browser >> automatically can chose those, then let us all understand those, so we c= an >> achieve what should be achieved by this milestone. >> >> >> >> Skype, Hangouts, Facetime are doing billions of minutes per week and the >> Internet has not melted yet. If we need to do flow identification to all= ow >> traffic to be prioritized, fine (see above regarding my preferred >> approach), but forcing all WebRTC traffic through a MITM (TURN server) i= s a >> much bigger jump that I don't yet see the justification for. >> >> >> >> In short: TURN is a technology that is supposed to fade away with the >> move to IPv6. I don't think we want to make it a critical element of Web= RTC. >> >> >> >> /Karl >> >> >> >> >> >> *Fr=C3=A5n:* Dan Wing [mailto:dwing@cisco.com] >> *Skickat:* den 11 februari 2014 18:25 >> *Till:* Marc Blanchet >> *Kopia:* Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ietf.org; >> Simon Perreault >> >> >> *=C3=84mne:* Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for >> enterprise and ISPs >> >> >> >> >> >> On Feb 11, 2014, at 9:08 AM, Marc Blanchet >> wrote: >> >> >> >> Le 2014-02-11 =C3=A0 00:39, Dan Wing a =C3=A9crit : >> >> >> >> >> On Feb 10, 2014, at 5:30 PM, Justin Uberti wrote: >> >> >> >> Good to see there is a lot of interest for this milestone. But based on >> the description here, it seems like we want to use TURN primarily to >> identify WebRTC flows, as opposed to using it as a NAT traversal tool. T= his >> makes me concerned that we may be using the wrong technology to solve th= e >> problem. >> >> >> >> +1. >> >> >> >> I would prefer allowing flows to establish themselves using their 'best' >> path, and the best path is seldom through a TURN server. When we imagin= e >> IPv6 in our future, we don't want to force an application-level proxy >> (TURN) server on the path solely for traversing an IPv6 firewall. >> >> >> >> >> >> It seems this thread is conflating all the possible reasons / >> justifications for TURN: >> >> * mobility >> >> * NAT traversal (both endpoints are behind endpoint-dependent mapping >> NATs) >> >> * firewall traversal (firewall blocks UDP) >> >> * enhancing privacy >> >> >> >> Unfortunately the TURN server nor the endpoint really know which of thos= e >> use-cases is desired (by the user or by the IT network administrator) or >> necessary (for the call to work at all). >> >> >> >> Dan, while I agree in principle, I doubt that a user could ever say "I >> want mobility or I want NAT traversal". I think the user only want the c= all >> to succeed, whatever the properties of its network point of attachment a= re. >> >> >> >> So what can we do? Should the TURN server provide any and all services >> the TURN client might possibly want, as that is what a robust TURN serve= r >> will do, and the endpoint should prefer TURN candidates over all others >> because there might be some functionality / usefulness of TURN that the >> user might gain through TURN (e.g., enhanced privacy)? >> >> >> >> -d >> >> >> >> >> >> >> >> This seems problematic. Perhaps we need a way to signal the desired >> use-case ("trait"), or as Justin suggests, using a different technology = for >> some of these use-cases. >> >> >> >> -d >> >> >> >> >> >> >> >> >> >> On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl > > wrote: >> >> Simon, >> >> Good questions - see inline below --> . >> Some more thought is required! >> >> /Karl >> >> -----Ursprungligt meddelande----- >> Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Simon Perreault >> Skickat: den 10 februari 2014 15:16 >> Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com >> =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for >> enterprise and ISPs >> >> >> Karl, >> >> It is great to see such enthusiasm! Thanks! >> >> I have a couple technical questions... >> >> Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : >> > - Note that to achieve some of the above points, TURN must be favored >> > over STUN to enforce that the TURN-path actually is used. (The Anycast >> > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) >> >> I understand the STUN vs TURN priority issue. But I don't see how anycas= t >> affects it in any way. Can you please explain? >> >> --- Good point - I was a bit quick here (maybe too quick) >> We have given this quite bit of thought, since even if a TURN server is >> provided and discovered, CURRENT usage of ICE may suggest a candidate fr= om >> the remote party that will make a connection without the need/usage of t= he >> TURN server (that we wanted to be used for the good purposes listed). >> >> The only way we found around this, was to stop STUN through the IP >> default gateway (like a restrictive Enterprise firewall does inhibiting = ICE >> connectivity, which others are concerned about...). Since the provisioni= ng >> of auto-discovery using the anycast mechanism, would be adding a route i= n a >> default gateway, adding a firewall rule to eat STUN packets would assure >> that the provisioned TURN server actually becomes used (and not bypassed >> "by accident"). (That was the thought behind the =E2=80=9Cautomatically= =E2=80=9D within >> quotes.) >> >> BUT, since you brought up the question, assuming that we have the power >> to enforce WebRTC usage of ICE, I believe a MUST requirement to use an >> auto-discovered TURN server instead of STUN, would solve the same proble= m. >> However, thinking further (in relation to your next question - "anyone >> could set up a badly-maintained" - enforcing such ICE usage may not be >> good.) >> >> >> >> > - 3^rd The Anycast method below =E2=80=93 I see no problem >> > >> > It also has the advantage of encouraging (but not requiring) the >> > STUN/TURN to be built in the default gateway or NAT/firewall/access >> > router itself, with a second interface to a public IP address on the >> > WAN side. (Current volume deployed, low cost NSP triple play modems >> > usually have a quality assured level 2 or level 3 WAN pipe for just >> > voice (and another for IPTV) =E2=80=93 The anycast discovered TURN-ser= ver can >> > be the access gateway to such quality pipe for WebRTC media, in a >> > single NSP provided CPE, scaling from residential and up.) >> >> Suppose we define well-known anycast TURN server addresses. How would >> this not be subject to the same service quality issues that plagued 6to4= ? >> That is, anyone could set up a badly-maintained, under-provisioned TURN >> server and announce it over BGP to the world, as it was done for >> 6to4 relays. Or just bad BGP outbound filter configuration. And how can >> we prevent triangle routing? There is nothing guaranteeing that the anyc= ast >> server you see is being provided to you by your ISP, rather than a serve= r >> sitting on the other side of the planet. >> >> --- Good point - needs to be resolved. For this I don't have a ready >> answer... >> An auto-discovered TURN server must be trusted (whatever method it is >> discovered by). We are trusting the one providing us with an IP address = and >> default gateway anyway. It would be easy if we could reuse that trust, >> instead of another mechanisms. >> >> Is there a good way for the browser to check that the anycast address is >> not handled beyond the network service provider's default gateway? Ideas= ? >> >> >> >> >> Thanks, >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> >> >> >> >> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> >> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > --089e013cba62a36a6d04f24e3208 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 13, 2014 at 10:45 AM, Justin Uberti &= lt;juberti@google.c= om> wrote:
Karl,

You sent 23 mess= ages to the list on this same thread in the past few hours. This is not an = effective way of presenting your ideas; I myself have lost track of what yo= u are hoping to accomplish.

Right now the only currently viable mechanism for auto-= discovery is WPAD. If you think the anycast mechanism is worth pursuing, I = suggest writing it up as an I-D.

I now see that http://www.ietf.org/id/draft-patil-tram-turn-serv-disc-0= 0.txt covers the anycast mechanism.

There have also been several mechanisms proposed for do= ing QoS provisioning, namely=C2=A0http://tools.ietf.org/searc= h/draft-penno-pcp-mobile-qos-00 and=C2=A0http://tools.iet= f.org/html/draft-martinsen-tram-discuss-00. If you think those proposal= s are insufficient, I suggest pointing out your concerns in threads specifi= c to those documents.

Justin




On T= hu, Feb 13, 2014 at 4:04 AM, Karl Stahl <karl.stahl@intertex.se&g= t; wrote:
=

Note that some things being questioned in this discussion alread= y are in the draft-ietf-rtcweb-use-cases-and-requirements document (pointed= out below). I think this may clarify some things also=E2=80=A6

=C2=A0

=C2=A0

On the side of this TRAM-list, I al= so got this question:

> Regarding the enterprise case, I am not sure I follow your argume= nt.

> Do you mean that by setting up an enterpri= se TURN server, and open the firewall for media over UDP from/to TURN serve= r be the solution?

---- As we all realize, that would of cou= rse not help or improve things

=C2=A0

The intended solution in the enterprise case has = not yet been spelled out in this TRAM-list discussion, so for better unders= tanding, let me copy a few things from the discussion in September/October = on the RTCWEB-list and what is (since long) spelled out in the draft-ietf-r= tcweb-use-cases-and-requirements.

=C2=A0

For better understanding, I also want to point ou= t that a TURN can have two interfaces (acting like a router for media betwe= en different networks). This allows to easier understand that can TURN serv= ers can direct a best media path (rather than just thinking that a TURN ser= vice is a device which media just bounces against at one interface).

=C2=A0

And, we can also hope for that a TURN server beco= mes a (common) component of a firewall, which would allow the firewall to u= nderstand that the media directed to it is RTC and should be prioritized wh= ereby the firewall can traffic shaped (back-off data traffic that may be fi= lling its Internet pipe) as well as e.g. set diffserve bits or take other m= easures to assist proper quality handling thought the network. (These are c= ommon mechanisms available and used in firewalls/NATs/access routers, but T= URN servers are not yet included such devices.) The same goes for access ro= uters/default gateways, DPIs in the transport network itself =E2=80=93 TURN= servers included in such points were media can pass and quality measures a= pplied may/will be very useful to get us WebRTC media with through networks= without quality destruction.

=C2=A0

From the RTCWEB mailing list September 20th<= /sup> (by me):

An enterprise network that want to keep a restricti= ve firewall not allowing UDP traffic, could provide a real-time path using = a TURN server paralleling the firewall, instead of tunneling RTP through al= ways open http or https ports resulting in RTP media over TCP =E2=80=93 wit= h severe quality problems from TCP retransmissions of dropped packets. The = TURN server address is most easily provided in the same way as the IP addre= ss and DNS address. (That would also put the right party in control =E2=80= =93 The network provider (here the enterprise) decides what is allowed on h= is network.)

=C2=A0

The browser should select which available TURN server address to use in= the following priority order, where ICE could be used to try several:

=C2=A0

1) TURN server address configured in the browser by the user (special c= ases, normally not used)

2)= TURN server address configured by the network administrator via an =E2=80= =9Cadmin policy template=E2=80=9D

3) TURN server address supplied by DHCP or similar = automatic network method

4)= TURN server address being supplied by the web application"<= /u>

=C2=A0

=C2=A0

And from yesterdays(!) http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requ= irements-14 these enterprise things and necessity are spelled out in:

=C2=A0

=C2=A0=C2=A0 ----------------------------------------------------= ------------

=C2=A0<= /p>

A22

3.3.5.=C2=A0 Simple Video Communication Service, enterprise a= spects

3.3.5.1<= b>.=C2=A0 Des= cription

=C2=A0=C2=A0 This use-case is similar to the Simple Video Communi= cation Service

=C2=A0=C2=A0 use-case (Section 3.3.1).<= /span>

=C2=A0

=C2=A0=C2=A0 What is ad= ded is aspects when using the service in enterprises.=C2=A0 ICE

=C2=A0=C2=A0 is assumed in the further description of this use-ca= se.

=C2=A0

=C2=A0=C2=A0 An enterprise that uses a RTCWEB based web applicati= on for

=C2=A0=C2=A0 communication desires= to audit all RTCWEB based application sessions

=C2=A0=C2=A0 used from inside the company towards any external pe= er.=C2=A0 To be able

=C2=A0=C2=A0 to do t= his they deploy a TURN server that straddles the boundary

=C2=A0=C2=A0 between the internal and the external network.

=C2=A0

=C2=A0=C2=A0 The firewall will block all attempts to use STUN wit= h an external

=C2=A0=C2=A0 destination un= less they go to the enterprise auditing TURN server.

=C2=A0=C2=A0 In cases where employees are using RTCWEB applicatio= ns provided by an

=C2=A0=C2=A0 external s= ervice provider they still want the traffic to stay inside

=C2=A0=C2=A0 their internal network and in addition not load the = straddling TURN

=C2=A0=C2=A0 server, th= us they deploy a STUN server allowing the RTCWEB client to

=C2=A0=C2=A0 determine its server reflexive address on the intern= al side.=C2=A0 Thus

=C2=A0=C2=A0 enabling= cases where peers are both on the internal side to connect

=C2=A0=C2=A0 without the traffic leaving the internal network.=C2= =A0 It must be

=C2=A0=C2=A0 possible to c= onfigure the browsers used in the enterprise with

=C2=A0=C2=A0 network specific STUN and TURN servers.=C2=A0 This s= hould be possible to

=C2=A0=C2=A0achieve = by auto-configuration methods.=C2=A0 The RTCWEB functionality will

=C2=A0=C2=A0 need to utilize both network specific STUN and TURN = resources and

=C2=A0=C2=A0 STUN and TURN = servers provisioned by the web application.

3.3.5.2<= b>.=C2=A0 Add= itional Requirements

=C2=A0=C2=A0 ----------------------------------------------------= ------------

=C2=A0=C2=A0 REQ-ID=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 DESCRIPTION

=C2=A0=C2=A0 ----------------------------------------------------= ------------

=C2=A0=C2=A0 F20=C2=A0=C2=A0= =C2=A0=C2=A0 The browser must support the use of STUN and TURN

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 serv= ers that are supplied by entities other than

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the web ap= plication (i.e. the network provider).

=C2=A0=C2=A0 ----------------------------------------------------= ------------

<= /u>=C2=A0

There are further requirement listed, hel= ping us to understand the need for auto discovery and a network provided TU= RN-server should be used to ENFORCE that media takes that path (and thus, o= ther paths e.g. suggested by the remote MUST not happen to be used). This i= s related to the mobility aspect (valid even without the roaming idea):<= /u>

3.3.6.=C2=A0 Simple Video Communica= tion Service, access change

3.3.6.1.=C2=A0 Description
=C2=A0=C2=A0 This use-case is almost identical to th=
e
=C2=A0=C2=A0 Simple Vide=
o Communication Service use-case (Section 3.3.1).=C2=A0 The
=C2=A0=C2=A0 difference is that the user changes net=
work access during the
=C2=
=A0=C2=A0 session.
=
=C2=A0
=C2=A0=C2=A0 The communication device used by one of=
 the users has several network
=C2=A0=C2=A0 adapters (Ethernet, WiFi, Cellular).=C2=A0 The communicat=
ion device is
=C2=A0=C2=A0 accessing the Internet using Ethernet, =
but the user has to start a
=C2=A0=C2=A0 trip during the session.=C2=A0 The communication device auto=
matically
=C2=A0=C2=A0 changes to use WiFi when the Ethernet c=
able is removed and then moves
=C2=A0=C2=A0 to cellular access to the Internet when moving out of WiF=
i coverage.
=C2=A0=C2=A0 The session continues even though the a=
ccess method changes.
3.3.6.2.=C2=A0 Additional Requirements
=C2=A0=C2=A0 ---------------------------------------=
-------------------------
=
=C2=A0=C2=A0 REQ-ID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DESCRIPTION=

=C2=A0=C2=A0 --------------------------=
--------------------------------------
=C2=A0=C2=A0 F17=C2=A0=C2=A0=C2=A0=C2=A0 The communi=
cation session must survive across a
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cha=
nge of the network interface used by the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 session
=C2=A0=C2=A0 ---------------------------------------=
-------------------------

3.3.7= .=C2=A0 Simple Video Communication Service, QoS

3.3.7.1.=C2=A0 Description
=C2=A0=C2=A0 This use-case is almost identical to th=
e
=C2=A0=C2=A0 Simple Vide=
o Communication Service, access change use-case
<= pre>=C2=A0=C2=A0 (Section 3.3.6).=C2=A0 The use of Quality of Service (QoS) capabili= ties is 
=C2=A0=C2=A0 added:
<=
span lang=3D"EN">=C2=A0
=
=C2=A0=C2=A0 The user in the previous use case that starts a trip is behind=
 a
=C2=A0=C2=A0 common residential router that supports=
 prioritization of traffic.
=C2=A0=C2=A0 In addition, the user's provider of cellular access has =
QoS support
=C2=A0=C2=A0 enabled.=C2=A0 The user is able to take=
 advantage of the QoS support both
=C2=A0=C2=A0 when accessing via the residential router and when us=
ing cellular.
3.3.7.2.=C2=A0 Additional Requi= rements
=C2=A0=C2=A0 ---------------------------------------=
-------------------------
=
=C2=A0=C2=A0 REQ-ID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DESCRIPTION=

=C2=A0=C2=A0 --------------------------=
--------------------------------------
=C2=A0=C2=A0 F17=C2=A0=C2=A0=C2=A0=C2=A0 The communi=
cation session must survive across a
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0cha=
nge of the network interface used by the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 session
=C2=A0=C2=A0 ---------------------------------------=
-------------------------
=
=C2=A0=C2=A0 F22=C2=A0=C2=A0=C2=A0=C2=A0 The browser must be able to receiv=
e streams and
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 data from multiple peers concurrently.
= 
=C2=A0=C2=A0 ---------------------------------------=
-------------------------

=C2=A0

Further from the RTCWEB mailing list September 20th (by me):=

=C2=A0

There are several reasons for a network service provider to s= upply a TURN server as part of his offered access:

- to keep media paths short, specifically not sendi= ng media outside its own network to some distant application provided TURN = server

- to support mobilit= y, i.e. you may want to move from a LAN with a configured TURN server to ac= cessing via WiFi or 3G/4G OTT channels

- to offer a media path with better quality (than b= est effort data traffic).

G= etting =E2=80=9CWebRTC-ready=E2=80=9D access and we look forward to telepre= sence for everyone.

=C2=A0

=C2=A0

I hope this (a bit lengthy) summary of al= ready thought-out and discussed aspects/requirements will help us understan= d that the auto-discovered TURN server is an ORDER from the enterprise and/= or the NSP/ISP =C2=A0to send the media through this TURN path, and that oth= er media paths that may exist MUST NOT BE USED. (That is why we especially = have to watch/advice that workable media paths proposed by the remote party= not becomes used =E2=80=9Cby accident=E2=80=9D.

=C2=A0

/Karl

=C2=A0

=C2=A0

Fr=C3=A5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]

Till: Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal (m= perumal)
Kopia: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org; Marc Blanchet; = Dan Wing (dwing); Karl Stahl
=C3=84mne: RE: [tram] Milestone 3: TURN server auto-discovery mechan= ism for enterprise and ISPs

=C2=A0

Hi Andy,

=C2=A0

There are other ways to solve= the problem for example using PCP. Can you clarify how deploying a TURN se= rver in the Enterprise protects the users and the network ? <= /span>

=C2=A0

-Tiru.=

From: tram [mailto:tram-bounces@ietf.org] On = Behalf Of Hutton, Andrew
Sent: Thursday, February 13, 2014 1:00 AM
To: Justin Ubert= i; Muthu Arul Mozhi Perumal (mperumal)
Cc: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ie= tf.org; Marc Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

=C2=A0

The case where the TURN server is the only option ma= y become common within enterprise networks and that might be deliberate ent= erprise policy because it provides the better path (UDP through the F/W) an= d protects the users and the network.

=C2=A0

Andy

=C2=A0

=C2=A0=

From: tram [mailto:tram-bounces@ietf.= org] On Behalf Of Justin Uberti
Sent: 12 February 2014 17:46
To: Muthu Arul Mozhi Perumal = (mperumal)
Cc: tireddy@icisco.com; Simon Perreault;= Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing (dwing); = Karl Stahl
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs

=C2=A0

Agree. If TURN is indeed being provided for the user&#= 39;s benefit, the client's ICE logic (based on RTT or similar) should r= esult in it preferring the TURN path.

=C2=A0

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) <= ;mperumal@cisco.com= > wrote:

Yes, I believe the second case is rar= e, but would be better than a rat race b/w administrators trying to block p= 2p traffic and force it through a TURN server and apps/endpoints finding sm= arter ways to bypass them.=

=C2=A0

Muthu

=C2=A0

= From: Oleg Moskalenko [mailto:mom040267@gmail.com]
Sent: Wednesday, February 12, 2014 1:07 PM
To: Muthu Arul = Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl Stahl; = tireddy@icisco= .com; Marc Blanchet; tram@ietf.org; Dan Wing (d= wing); Simon Perreault


Subject: R= e: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise = and ISPs

=C2=A0

The TURN server has to be used when it is either = the only option, or if it provides a better path (I guess the second case i= s rather rare).

=C2=A0

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperuma= l) <mperumal@cis= co.com> wrote:

+1=

=C2=A0

Forcing all traffic through a TURN server and e= xpecting it would provide the best user experience doesn't look the rig= ht approach. Instead, if a path through a TURN server exists and does provi= de lower RTT, jitter etc, being able to detect and use (or switch to) that = path might be desirable..<= /p>

=C2=A0

Muthu

=C2=A0

= From: tram [mailto:tram-bounces@ietf.org] = On Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 11:43 AM
To: Karl Stahl=
Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org<= /a>; Dan Wing (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs<= /p>

=C2=A0=

Inline.

=C2=A0=

On Tue, Feb 11,= 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> wrote:

Listening to this thread, I am = afraid we are missing the very point and necessity for this milestone!

- There are severe NAT traversal and qual= ity issues that should and can be dealt with by a good auto-discovery mecha= nism and the right usage by the turn client (the WebRTC browser)

=C2=A0=

There are ways, not onl= y: Enterprises or ISPs wishing to provide their own TURN server= , in an attempt to reduce so-called "triangle routing",need a new= auto-discovery mechanism<= /p>

But also: - NSPs (Network Service Provide= rs) want to provide a path where the bandwidth of WebRTC is better coped wi= th.

- NSPs or Enterprises want to offer = an Internet access quality pipe for prioritized RTC (Real Time Communicatio= n) traffic.

- Enterprises having restrictive firewall= s, want to provide a UDP-path for WebRTC and possibly also for better quali= ty where RTC do not compete with data traffic. =

Also considering

- Mobility; It is common to move from a LAN to accessing via WiF= i or 3G/4G OTT channels, all should be able to automatically offer their ow= n optimal TURN server

=C2=A0=

This leads us i= nto =C2=A0=E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D= etc! It is not a mistake, but the very need for= this milestone!

=C2=A0<= u>

Aga= in, it has not been demonstrated why TURN is the right technology here, com= pared to a more transparent flow identification tool like MALICE. We don= 9;t force all HTTP requests to locate a HTTP proxy via anycast, I don't= see why we need to do the same for WebRTC.=C2=A0

=C2=A0=

What are the hesitations raised here?

> TURN primarily to identify WebRTC flows, as = opposed to using it as a NAT traversal tool. This makes me concerned that w= e may be using the wrong technology to solve the problem

It is correct that ICE/STUN/TURN wa= s designed to address the NAT/Firewall traversal problem associated with re= al-time communication (SIP at that time). However, its largest flaw/problem= is that quality things were not (could not be?) considered. The method=E2= =80=99s very idea (like all similar methods for getting RTC through ordinar= y NAT/Firewalls) is to fool the media through a NAT/Firewall that is unawar= e of what is happening. Thus, this is root of quality issues (and bandwidth= allocation optimization) that needs to be dealt with: Real-time traffic fi= ghting with a data traffic crowded congestion point.

= =C2=A0

I think that "fooling" is an incorrect description. Th= e NAT is supposed to be transparent to the client.

=C2=A0=

But, a BLESSING of ICE/STUN/TURN is that = it can be seen as a legitimate request for a suitable pipe for quality dema= nding real time traffic. J

ICE is a pre-protocol you use because you= want a path for real-time media between parties. Here: The browser says kn= ock knock, I want to get media through (and of course with as good quality = as required and possible).

=C2=A0=

If the NAT/Firewall own= er and network owner are allowed to see these requests, they can help/assis= t in achieving the good media path. If they are not aware, they cannot help= !

=C2=A0

Hope this made it understandable on an ov= erview level how this can become =E2=80=9CTURN=E2=80=A6to identif= y WebRTC flows=E2=80=9D

It is also the ONLY way I can see to achi= eve what we want to achieve and should be the aim and requirement of this m= ilestone.

=C2=A0=

I am talking about gene= ral usage of WebRTC over Internet/mobile OTT (not feeding WebRTC into appli= cation specific networks like IMS where other methods may exist).

=C2=A0=

This is good, not evil!=

=C2=A0=

If the hesitations are = raised because of a belief/hope/wish that there are no or will not be sever= e quality issues =E2=80=9Cbecause it is all about bandwidth=E2=80=9D, =E2= =80=9Cit will resolve itself with time=E2=80=9D etc., I strongly object! Th= at is wrong and will be very detrimental for WebRTC usage. We already see i= t and I can give numerous examples of how much less quality demanding VoIP = is/is not handled quality wise and that it matters. And, what would be bad = considering quality issues and allowing/encouraging methods to deal with th= em?

=C2=A0

If the hesitations are raised, because of= suspicion that the methods we may recommend may be misused to stop/block/d= estroy WebRTC usage (e.g. to protect income from carrier telephony traffic)= , I could understand and would fight the same battle. But hopefully, those = days are (soon) over =E2=80=93 At least forward thinking carrier=E2=80=99s = realize that already. Web RTC will happen. Which customers want to pay for = an access with blocked WebRTC? The carrier=E2=80=99s offering/assuring good= WebRTC will rather get the customers and income J. (Maybe the Web browser can detect and encourage this=E2=80=A6)= =C2=A0

=C2=A0

If there are technical concerns of bad re= sult, or better methods allowing network providers and LAN managers to offe= r and inform the browser that there are good media paths to be used, and th= at the web browser automatically can chose those, then let us all understan= d those, so we can achieve what should be achieved by this milestone.

= =C2=A0

Skype, Hangouts, Facetime are doing billions of minutes per week= and the Internet has not melted yet. If we need to do flow identification = to allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) is a= much bigger jump that I don't yet see the justification for.=

=C2=A0=

In short:= TURN is a technology that is supposed to fade away with the move to IPv6. = I don't think we want to make it a critical element of WebRTC.

=C2=A0=

/Karl<= u>

=C2=A0

=C2=A0=

Fr=C3=A5n: Dan Wing [mailto:= <= span style=3D"font-size:10pt;font-family:Tahoma,sans-serif">dwing@cisco.com= ]
Skickat: den 11 februari 2014 18:25
Till: Marc Blanchet
Kop= ia: Justin Uberti; tireddy@icisco.com; Karl Stahl; tram@ie= tf.org; Simon Perreault


=C3=84mne: Re: [tram] Milestone= 3: TURN server auto-discovery mechanism for enterprise and ISPs

=C2=A0

= =C2=A0

On Feb 11, 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

=C2=A0

Le 2014-02-= 11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit :

=C2=A0


On Feb 10, 2014, at 5:30 PM, Justin Uberti <= juberti@google.com<= /span>> wrote:

=C2=A0

Good to see there is a = lot of interest for this milestone. But based on the description here, it s= eems like we want to use TURN primarily to identify WebRTC flows, as oppose= d to using it as a NAT traversal tool. This makes me concerned that we may = be using the wrong technology to solve the problem.

=C2=A0

+1.

=C2=A0

I would prefer allowing flows to establish them= selves using their 'best' path, and the best path is seldom through= a TURN server. =C2=A0When we imagine IPv6 in our future, we don't want= to force an application-level proxy (TURN) server on the path solely for t= raversing an IPv6 firewall.

=C2=A0

=C2=A0

It seems this thread is conflating all the possible r= easons / justifications for TURN:=

=C2=A0 * mobility<= u>

=C2=A0 * NAT traversal (both endpoin= ts are behind endpoint-dependent mapping NATs)<= u>

=C2=A0 *=C2=A0firewall traversal (firewall blocks UDP= )

=C2=A0 * enhancing privacy=

=C2=A0<= /u>

Unfortunately the TURN server nor the endpoint really= know which of those use-cases is desired (by the user or by the IT network= administrator) or necessary (for the call to work at all).

=C2=A0<= u>

Dan, while I agree in pr= inciple, I doubt that a user could ever say "I want mobility or I want= NAT traversal". I think the user only want the call to succeed, whate= ver the properties of its network point of attachment are.

=C2=A0

So what can we do?= =C2=A0Should the TURN server provide any and all services the TURN client = might possibly want, as that is what a robust TURN server will do, and the = endpoint should prefer TURN candidates over all others because there might = be some functionality / usefulness of TURN that the user might gain through= TURN (e.g., enhanced privacy)?

=C2=A0=

-d=

=C2=A0

=C2=A0=

=C2=A0

=C2=A0This seems problematic. =C2=A0Perhaps we need a = way to signal the desired use-case ("trait"), or as Justin sugges= ts, using a different technology for some of these use-cases.

=C2=A0

-d

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl=C2=A0<karl.stahl@intertex.se>=C2=A0wrote:

Simon,

Good questions - see inline below --> .
Some= more thought is required!

/Karl

-----Ursprungligt meddelande= -----
Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org= ] F=C3=B6r S= imon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl Stahl;=C2=A0tram@ietf= .org;=C2=A0tireddy@icisco.com
=C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for= enterprise and ISPs


Karl,

It is great to see such enthusiasm! Thanks!

I have a co= uple technical questions...

Le 2014-02-08 08:11, Karl Stahl a =C3=A9= crit :
> - Note that to achieve some of the above points, TURN must b= e favored
> over STUN to enforce that the TURN-path actually is used. (The Anycast=
> method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.= )

I understand the STUN vs TURN priority issue. But I don't see = how anycast affects it in any way. Can you please explain?

--- Good point - I was a bit quick here (maybe too quick)<= br>We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate from = the remote party that will make a connection without the need/usage of the = TURN server (that we wanted to be used for the good purposes listed).

The only way we found around this, was to stop STUN through the IP defa= ult gateway (like a restrictive Enterprise firewall does inhibiting ICE con= nectivity, which others are concerned about...). Since the provisioning of = auto-discovery using the anycast mechanism, would be adding a route in a de= fault gateway, adding a firewall rule to eat STUN packets would assure that= the provisioned TURN server actually becomes used (and not bypassed "= by accident"). (That was the thought behind the =E2=80=9Cautomatically= =E2=80=9D within quotes.)

BUT, since you brought up the question, assuming that we have the power= to enforce WebRTC usage of ICE, I believe a MUST requirement to use an aut= o-discovered TURN server instead of STUN, would solve the same problem. How= ever, thinking further (in relation to your next question - "anyone co= uld set up a badly-maintained" - enforcing such ICE usage may not be g= ood.)



> - 3^rd The Anycas= t method below =E2=80=93 I see no problem
>
> It also has the a= dvantage of encouraging (but not requiring) the
> STUN/TURN to be built in the default gateway or NAT/firewall/access> router itself, with a second interface to a public IP address on the<= br>> WAN side. (Current volume deployed, low cost NSP triple play modems=
> usually have a quality assured level 2 or level 3 WAN pipe for just> voice (and another for IPTV) =E2=80=93 The anycast discovered TURN-se= rver can
> be the access gateway to such quality pipe for WebRTC medi= a, in a
> single NSP provided CPE, scaling from residential and up.)

Supp= ose we define well-known anycast TURN server addresses. How would this not = be subject to the same service quality issues that plagued 6to4? That is, a= nyone could set up a badly-maintained, under-provisioned TURN server and an= nounce it over BGP to the world, as it was done for
6to4 relays. Or just bad BGP outbound filter configuration. And how can we = prevent triangle routing? There is nothing guaranteeing that the anycast se= rver you see is being provided to you by your ISP, rather than a server sit= ting on the other side of the planet.=

--- Good point - needs to be resolved. For this I don'= t have a ready answer...
An auto-discovered TURN server must be trusted = (whatever method it is discovered by). We are trusting the one providing us= with an IP address and default gateway anyway. It would be easy if we coul= d reuse that trust, instead of another mechanisms.

Is there a good way for the browser to check that the anycast address i= s not handled beyond the network service provider's default gateway? Id= eas?




= Thanks,
Simon
--
DTN made easy, lean, and smart -->=C2=A0http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0-->=C2=A0<= span lang=3D"SV" style=3D"font-size:9pt;font-family:Helvetica,sans-serif">h= ttp://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -->=C2= =A0http://numb.viagenie.ca
_______________________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram= <= br>
_______________________________________________
tram mailing listtram@ietf.org
https://www.ietf.org/mailman/listinfo/tram=

=C2=A0

_____________________________________________= __
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram=


_______________________________________________
tra= m mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram=

=C2=A0

=C2=A0

<= p class=3D"MsoNormal"> =C2=A0


_______________________________________________
tra= m mailing list
tram@ietf.org
https= ://www.ietf.org/mailman/listinfo/tram

=C2=A0

=C2=A0


____= ___________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram



--089e013cba62a36a6d04f24e3208-- From nobody Thu Feb 13 11:25:57 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 466F01A0350 for ; Thu, 13 Feb 2014 11:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 SPbipTaBMRw5 for ; Thu, 13 Feb 2014 11:25:50 -0800 (PST) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 96B491A034A for ; Thu, 13 Feb 2014 11:25:49 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx11.unify.com (Server) with ESMTP id D6D021EB86FA; Thu, 13 Feb 2014 20:25:47 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.100]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Thu, 13 Feb 2014 20:25:47 +0100 From: "Hutton, Andrew" To: "Tirumaleswar Reddy (tireddy)" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: Ac8obNsCFphKtERXaUGRovqHSSrR3gAPBsvwAAfsigAACiZ2kA== Date: Thu, 13 Feb 2014 19:25:46 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17CF5660@MCHP04MSX.global-ad.net> References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> <9F33F40F6F2CD847824537F3C4E37DDF17CF4032@MCHP04MSX.global-ad.net> <913383AAA69FF945B8F946018B75898A242AD903@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242AD903@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17CF5660MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Q5S0RbCgClVDW2zDz91Z6FIdONA Cc: "tram@ietf.org" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 19:25:56 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF17CF5660MCHP04MSXglobal_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIHN1Y2ggZW5oYW5jZW1lbnQgaXMgZGVzY3JpYmVkIGluIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWpvaG5zdG9uLXRyYW0tc3R1bi1vcmlnaW4tMDEuDQoNCkFuZHkNCg0KDQoN CkZyb206IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgW21haWx0bzp0aXJlZGR5QGNpc2Nv LmNvbV0NClNlbnQ6IDEzIEZlYnJ1YXJ5IDIwMTQgMTU6MzQNClRvOiBIdXR0b24sIEFuZHJldw0K Q2M6IHRyYW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4g c2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0K DQpIaSBBbmR5LA0KDQpZZXMsIFdlYlJUQyBicm93c2VyIHdpbGwgaGF2ZSB0byBhIHN1cHBvcnQg YSBudW1iZXIgb2YgbWVjaGFuaXNtcy4gVGhpcyB3YXMgZGlzY3Vzc2VkIGluIFJUQ1dFQiBtYWls aW5nIGxpc3Qgc29tZXRpbWUgYmFjayBhbmQgc2VjdGlvbiAzLjMuNC4xIGluIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1l bnRzLTE0IGhhcyBiZWVuIHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGlzIHBvaW50Lg0KQ2FuIHlvdSBw bGVhc2UgY2xhcmlmeSB0aGUgZW5oYW5jZW1lbnRzIFRVUk4gc2VydmVyIHlvdSBhcmUgbG9va2lu ZyBmb3IgYW5kIHdoYXQgcHJvYmxlbXMgZG9lcyBpdCBzb2x2ZSA/DQoNCi1UaXJ1Lg0KRnJvbTog SHV0dG9uLCBBbmRyZXcgW21haWx0bzphbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbV0NClNlbnQ6IFRo dXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCA0OjE4IFBNDQpUbzogVGlydW1hbGVzd2FyIFJlZGR5 ICh0aXJlZGR5KQ0KQ2M6IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSRTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBt ZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KVGhlIHByaW1lIHVzZSBjYXNlIGZv ciB0aGlzIGlzIGRvY3VtZW50ZWQgaW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTIjc2VjdGlvbi0zLjMuNS4x IGFuZCBJIHRoaW5rIHRoYXQgVFJBTSB3aWxsIHByb2JhYmx5IG1ha2UgZW5oYW5jZW1lbnRzIHRv IFRVUk4gZW5hYmxpbmcgc3VjaCBhbiDigJxlbnRlcnByaXNlIGF1ZGl0aW5nIFRVUk4gc2VydmVy 4oCdIHRvIGRvIGFuIGVmZmVjdGl2ZSBqb2Igb2YgbWFuYWdpbmcgV2ViUlRDIHRyYWZmaWMgaW4g YW4gZW50ZXJwcmlzZS4NCg0KVGhlcmUgYXJlIG9mIGNvdXJzZSBtb3JlIHRoYW4gb25lIHByb2Js ZW0gYW5kIG1hbnkgcG9zc2libHkgd2F5cyB0byBzb2x2ZSB0aGVtIGFuZCBJIHJlY2VudGx5IHVw ZGF0ZWQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHV0dG9uLXJ0Y3dlYi1uYXQt ZmlyZXdhbGwtY29uc2lkZXJhdGlvbnMtMDMgdG8gbGlzdCB0aGVzZSBmb3IgZGlzY3Vzc2lvbiBp bmNsdWRpbmcgUENQLg0KDQpVbmZvcnR1bmF0ZWx5IHNvbHV0aW9ucyBhcmUgbmVlZGVkIHRvZGF5 IHdpdGhpbiBleGlzdGluZyBuZXR3b3JrcyBhbmQgUENQIGRvZXMgbm90IHNlZW0gc28gdXNlZnVs IGhlcmUgc28gd2UgaGF2ZSB0byBsb29rIGF0IG11bHRpcGxlIHNvbHV0aW9ucyBhbmQgcHJvYmFi bHkgV2ViUlRDIGJyb3dzZXJzIGhhdmUgdG8gc3VwcG9ydCBhIG51bWJlciBvZiBtZWNoYW5pc21z Lg0KDQpSZWdhcmRzDQpBbmR5DQoNCg0KDQpGcm9tOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpIFttYWlsdG86dGlyZWRkeUBjaXNjby5jb21dDQpTZW50OiAxMyBGZWJydWFyeSAyMDE0IDAz OjM3DQpUbzogSHV0dG9uLCBBbmRyZXc7IEp1c3RpbiBVYmVydGk7IE11dGh1IEFydWwgTW96aGkg UGVydW1hbCAobXBlcnVtYWwpDQpDYzogdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5 QGljaXNjby5jb20+OyBTaW1vbiBQZXJyZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsgdHJhbUBpZXRm Lm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IE1hcmMgQmxhbmNoZXQ7IERhbiBXaW5nIChkd2lu Zyk7IEthcmwgU3RhaGwNClN1YmplY3Q6IFJFOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2Vy dmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpI aSBBbmR5LA0KDQpUaGVyZSBhcmUgb3RoZXIgd2F5cyB0byBzb2x2ZSB0aGUgcHJvYmxlbSBmb3Ig ZXhhbXBsZSB1c2luZyBQQ1AuIENhbiB5b3UgY2xhcmlmeSBob3cgZGVwbG95aW5nIGEgVFVSTiBz ZXJ2ZXIgaW4gdGhlIEVudGVycHJpc2UgcHJvdGVjdHMgdGhlIHVzZXJzIGFuZCB0aGUgbmV0d29y ayA/DQoNCi1UaXJ1Lg0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEh1dHRvbiwgQW5kcmV3DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTMs IDIwMTQgMTowMCBBTQ0KVG86IEp1c3RpbiBVYmVydGk7IE11dGh1IEFydWwgTW96aGkgUGVydW1h bCAobXBlcnVtYWwpDQpDYzogdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGljaXNj by5jb20+OyBTaW1vbiBQZXJyZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsgdHJhbUBpZXRmLm9yZzxt YWlsdG86dHJhbUBpZXRmLm9yZz47IE1hcmMgQmxhbmNoZXQ7IERhbiBXaW5nIChkd2luZyk7IEth cmwgU3RhaGwNClN1YmplY3Q6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1 dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpUaGUgY2Fz ZSB3aGVyZSB0aGUgVFVSTiBzZXJ2ZXIgaXMgdGhlIG9ubHkgb3B0aW9uIG1heSBiZWNvbWUgY29t bW9uIHdpdGhpbiBlbnRlcnByaXNlIG5ldHdvcmtzIGFuZCB0aGF0IG1pZ2h0IGJlIGRlbGliZXJh dGUgZW50ZXJwcmlzZSBwb2xpY3kgYmVjYXVzZSBpdCBwcm92aWRlcyB0aGUgYmV0dGVyIHBhdGgg KFVEUCB0aHJvdWdoIHRoZSBGL1cpIGFuZCBwcm90ZWN0cyB0aGUgdXNlcnMgYW5kIHRoZSBuZXR3 b3JrLg0KDQpBbmR5DQoNCg0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IDEyIEZlYnJ1YXJ5IDIwMTQgMTc6 NDYNClRvOiBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KQ2M6IHRpcmVkZHlA aWNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tPjsgU2ltb24gUGVycmVhdWx0OyBP bGVnIE1vc2thbGVua287IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+OyBNYXJj IEJsYW5jaGV0OyBEYW4gV2luZyAoZHdpbmcpOyBLYXJsIFN0YWhsDQpTdWJqZWN0OiBSZTogW3Ry YW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9y IGVudGVycHJpc2UgYW5kIElTUHMNCg0KQWdyZWUuIElmIFRVUk4gaXMgaW5kZWVkIGJlaW5nIHBy b3ZpZGVkIGZvciB0aGUgdXNlcidzIGJlbmVmaXQsIHRoZSBjbGllbnQncyBJQ0UgbG9naWMgKGJh c2VkIG9uIFJUVCBvciBzaW1pbGFyKSBzaG91bGQgcmVzdWx0IGluIGl0IHByZWZlcnJpbmcgdGhl IFRVUk4gcGF0aC4NCg0KT24gV2VkLCBGZWIgMTIsIDIwMTQgYXQgMToyNyBBTSwgTXV0aHUgQXJ1 bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgPG1wZXJ1bWFsQGNpc2NvLmNvbTxtYWlsdG86bXBl cnVtYWxAY2lzY28uY29tPj4gd3JvdGU6DQpZZXMsIEkgYmVsaWV2ZSB0aGUgc2Vjb25kIGNhc2Ug aXMgcmFyZSwgYnV0IHdvdWxkIGJlIGJldHRlciB0aGFuIGEgcmF0IHJhY2UgYi93IGFkbWluaXN0 cmF0b3JzIHRyeWluZyB0byBibG9jayBwMnAgdHJhZmZpYyBhbmQgZm9yY2UgaXQgdGhyb3VnaCBh IFRVUk4gc2VydmVyIGFuZCBhcHBzL2VuZHBvaW50cyBmaW5kaW5nIHNtYXJ0ZXIgd2F5cyB0byBi eXBhc3MgdGhlbS4NCg0KTXV0aHUNCg0KRnJvbTogT2xlZyBNb3NrYWxlbmtvIFttYWlsdG86bW9t MDQwMjY3QGdtYWlsLmNvbTxtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbT5dDQpTZW50OiBXZWRu ZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0IDE6MDcgUE0NClRvOiBNdXRodSBBcnVsIE1vemhpIFBl cnVtYWwgKG1wZXJ1bWFsKQ0KQ2M6IEp1c3RpbiBVYmVydGk7IEthcmwgU3RhaGw7IHRpcmVkZHlA aWNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tPjsgTWFyYyBCbGFuY2hldDsgdHJh bUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IERhbiBXaW5nIChkd2luZyk7IFNpbW9u IFBlcnJlYXVsdA0KDQpTdWJqZWN0OiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZl ciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KVGhl IFRVUk4gc2VydmVyIGhhcyB0byBiZSB1c2VkIHdoZW4gaXQgaXMgZWl0aGVyIHRoZSBvbmx5IG9w dGlvbiwgb3IgaWYgaXQgcHJvdmlkZXMgYSBiZXR0ZXIgcGF0aCAoSSBndWVzcyB0aGUgc2Vjb25k IGNhc2UgaXMgcmF0aGVyIHJhcmUpLg0KDQpPbiBUdWUsIEZlYiAxMSwgMjAxNCBhdCAxMTozMiBQ TSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgPG1wZXJ1bWFsQGNpc2NvLmNv bTxtYWlsdG86bXBlcnVtYWxAY2lzY28uY29tPj4gd3JvdGU6DQorMQ0KDQpGb3JjaW5nIGFsbCB0 cmFmZmljIHRocm91Z2ggYSBUVVJOIHNlcnZlciBhbmQgZXhwZWN0aW5nIGl0IHdvdWxkIHByb3Zp ZGUgdGhlIGJlc3QgdXNlciBleHBlcmllbmNlIGRvZXNuJ3QgbG9vayB0aGUgcmlnaHQgYXBwcm9h Y2guIEluc3RlYWQsIGlmIGEgcGF0aCB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgZXhpc3RzIGFuZCBk b2VzIHByb3ZpZGUgbG93ZXIgUlRULCBqaXR0ZXIgZXRjLCBiZWluZyBhYmxlIHRvIGRldGVjdCBh bmQgdXNlIChvciBzd2l0Y2ggdG8pIHRoYXQgcGF0aCBtaWdodCBiZSBkZXNpcmFibGUuLg0KDQpN dXRodQ0KDQpGcm9tOiB0cmFtIFttYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0 cmFtLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSnVzdGluIFViZXJ0aQ0KU2VudDog V2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAxNCAxMTo0MyBBTQ0KVG86IEthcmwgU3RhaGwNCkNj OiB0aXJlZGR5QGljaXNjby5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT47IE1hcmMgQmxh bmNoZXQ7IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+OyBEYW4gV2luZyAoZHdp bmcpOyBTaW1vbiBQZXJyZWF1bHQNClN1YmplY3Q6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRV Uk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQ cw0KDQpJbmxpbmUuDQoNCk9uIFR1ZSwgRmViIDExLCAyMDE0IGF0IDI6MzcgUE0sIEthcmwgU3Rh aGwgPGthcmwuc3RhaGxAaW50ZXJ0ZXguc2U8bWFpbHRvOmthcmwuc3RhaGxAaW50ZXJ0ZXguc2U+ PiB3cm90ZToNCkxpc3RlbmluZyB0byB0aGlzIHRocmVhZCwgSSBhbSBhZnJhaWQgd2UgYXJlIG1p c3NpbmcgdGhlIHZlcnkgcG9pbnQgYW5kIG5lY2Vzc2l0eSBmb3IgdGhpcyBtaWxlc3RvbmUhDQot IFRoZXJlIGFyZSBzZXZlcmUgTkFUIHRyYXZlcnNhbCBhbmQgcXVhbGl0eSBpc3N1ZXMgdGhhdCBz aG91bGQgYW5kIGNhbiBiZSBkZWFsdCB3aXRoIGJ5IGEgZ29vZCBhdXRvLWRpc2NvdmVyeSBtZWNo YW5pc20gYW5kIHRoZSByaWdodCB1c2FnZSBieSB0aGUgdHVybiBjbGllbnQgKHRoZSBXZWJSVEMg YnJvd3NlcikNCg0KVGhlcmUgYXJlIHdheXMsIG5vdCBvbmx5OiBFbnRlcnByaXNlcyBvciBJU1Bz IHdpc2hpbmcgdG8gcHJvdmlkZSB0aGVpciBvd24gVFVSTiBzZXJ2ZXIsIGluIGFuIGF0dGVtcHQg dG8gcmVkdWNlIHNvLWNhbGxlZCAidHJpYW5nbGUgcm91dGluZyIsbmVlZCBhIG5ldyBhdXRvLWRp c2NvdmVyeSBtZWNoYW5pc20NCkJ1dCBhbHNvOiAtIE5TUHMgKE5ldHdvcmsgU2VydmljZSBQcm92 aWRlcnMpIHdhbnQgdG8gcHJvdmlkZSBhIHBhdGggd2hlcmUgdGhlIGJhbmR3aWR0aCBvZiBXZWJS VEMgaXMgYmV0dGVyIGNvcGVkIHdpdGguDQotIE5TUHMgb3IgRW50ZXJwcmlzZXMgd2FudCB0byBv ZmZlciBhbiBJbnRlcm5ldCBhY2Nlc3MgcXVhbGl0eSBwaXBlIGZvciBwcmlvcml0aXplZCBSVEMg KFJlYWwgVGltZSBDb21tdW5pY2F0aW9uKSB0cmFmZmljLg0KLSBFbnRlcnByaXNlcyBoYXZpbmcg cmVzdHJpY3RpdmUgZmlyZXdhbGxzLCB3YW50IHRvIHByb3ZpZGUgYSBVRFAtcGF0aCBmb3IgV2Vi UlRDIGFuZCBwb3NzaWJseSBhbHNvIGZvciBiZXR0ZXIgcXVhbGl0eSB3aGVyZSBSVEMgZG8gbm90 IGNvbXBldGUgd2l0aCBkYXRhIHRyYWZmaWMuDQpBbHNvIGNvbnNpZGVyaW5nDQotIE1vYmlsaXR5 OyBJdCBpcyBjb21tb24gdG8gbW92ZSBmcm9tIGEgTEFOIHRvIGFjY2Vzc2luZyB2aWEgV2lGaSBv ciAzRy80RyBPVFQgY2hhbm5lbHMsIGFsbCBzaG91bGQgYmUgYWJsZSB0byBhdXRvbWF0aWNhbGx5 IG9mZmVyIHRoZWlyIG93biBvcHRpbWFsIFRVUk4gc2VydmVyDQoNClRoaXMgbGVhZHMgdXMgaW50 byAg4oCcVFVSTuKApnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnSBldGMhIEl0IGlzIG5vdCBh IG1pc3Rha2UsIGJ1dCB0aGUgdmVyeSBuZWVkIGZvciB0aGlzIG1pbGVzdG9uZSENCg0KQWdhaW4s IGl0IGhhcyBub3QgYmVlbiBkZW1vbnN0cmF0ZWQgd2h5IFRVUk4gaXMgdGhlIHJpZ2h0IHRlY2hu b2xvZ3kgaGVyZSwgY29tcGFyZWQgdG8gYSBtb3JlIHRyYW5zcGFyZW50IGZsb3cgaWRlbnRpZmlj YXRpb24gdG9vbCBsaWtlIE1BTElDRS4gV2UgZG9uJ3QgZm9yY2UgYWxsIEhUVFAgcmVxdWVzdHMg dG8gbG9jYXRlIGEgSFRUUCBwcm94eSB2aWEgYW55Y2FzdCwgSSBkb24ndCBzZWUgd2h5IHdlIG5l ZWQgdG8gZG8gdGhlIHNhbWUgZm9yIFdlYlJUQy4NCg0KV2hhdCBhcmUgdGhlIGhlc2l0YXRpb25z IHJhaXNlZCBoZXJlPw0KPiBUVVJOIHByaW1hcmlseSB0byBpZGVudGlmeSBXZWJSVEMgZmxvd3Ms IGFzIG9wcG9zZWQgdG8gdXNpbmcgaXQgYXMgYSBOQVQgdHJhdmVyc2FsIHRvb2wuIFRoaXMgbWFr ZXMgbWUgY29uY2VybmVkIHRoYXQgd2UgbWF5IGJlIHVzaW5nIHRoZSB3cm9uZyB0ZWNobm9sb2d5 IHRvIHNvbHZlIHRoZSBwcm9ibGVtDQpJdCBpcyBjb3JyZWN0IHRoYXQgSUNFL1NUVU4vVFVSTiB3 YXMgZGVzaWduZWQgdG8gYWRkcmVzcyB0aGUgTkFUL0ZpcmV3YWxsIHRyYXZlcnNhbCBwcm9ibGVt IGFzc29jaWF0ZWQgd2l0aCByZWFsLXRpbWUgY29tbXVuaWNhdGlvbiAoU0lQIGF0IHRoYXQgdGlt ZSkuIEhvd2V2ZXIsIGl0cyBsYXJnZXN0IGZsYXcvcHJvYmxlbSBpcyB0aGF0IHF1YWxpdHkgdGhp bmdzIHdlcmUgbm90IChjb3VsZCBub3QgYmU/KSBjb25zaWRlcmVkLiBUaGUgbWV0aG9k4oCZcyB2 ZXJ5IGlkZWEgKGxpa2UgYWxsIHNpbWlsYXIgbWV0aG9kcyBmb3IgZ2V0dGluZyBSVEMgdGhyb3Vn aCBvcmRpbmFyeSBOQVQvRmlyZXdhbGxzKSBpcyB0byBmb29sIHRoZSBtZWRpYSB0aHJvdWdoIGEg TkFUL0ZpcmV3YWxsIHRoYXQgaXMgdW5hd2FyZSBvZiB3aGF0IGlzIGhhcHBlbmluZy4gVGh1cywg dGhpcyBpcyByb290IG9mIHF1YWxpdHkgaXNzdWVzIChhbmQgYmFuZHdpZHRoIGFsbG9jYXRpb24g b3B0aW1pemF0aW9uKSB0aGF0IG5lZWRzIHRvIGJlIGRlYWx0IHdpdGg6IFJlYWwtdGltZSB0cmFm ZmljIGZpZ2h0aW5nIHdpdGggYSBkYXRhIHRyYWZmaWMgY3Jvd2RlZCBjb25nZXN0aW9uIHBvaW50 Lg0KDQpJIHRoaW5rIHRoYXQgImZvb2xpbmciIGlzIGFuIGluY29ycmVjdCBkZXNjcmlwdGlvbi4g VGhlIE5BVCBpcyBzdXBwb3NlZCB0byBiZSB0cmFuc3BhcmVudCB0byB0aGUgY2xpZW50Lg0KDQpC dXQsIGEgQkxFU1NJTkcgb2YgSUNFL1NUVU4vVFVSTiBpcyB0aGF0IGl0IGNhbiBiZSBzZWVuIGFz IGEgbGVnaXRpbWF0ZSByZXF1ZXN0IGZvciBhIHN1aXRhYmxlIHBpcGUgZm9yIHF1YWxpdHkgZGVt YW5kaW5nIHJlYWwgdGltZSB0cmFmZmljLiDimLoNCklDRSBpcyBhIHByZS1wcm90b2NvbCB5b3Ug dXNlIGJlY2F1c2UgeW91IHdhbnQgYSBwYXRoIGZvciByZWFsLXRpbWUgbWVkaWEgYmV0d2VlbiBw YXJ0aWVzLiBIZXJlOiBUaGUgYnJvd3NlciBzYXlzIGtub2NrIGtub2NrLCBJIHdhbnQgdG8gZ2V0 IG1lZGlhIHRocm91Z2ggKGFuZCBvZiBjb3Vyc2Ugd2l0aCBhcyBnb29kIHF1YWxpdHkgYXMgcmVx dWlyZWQgYW5kIHBvc3NpYmxlKS4NCg0KSWYgdGhlIE5BVC9GaXJld2FsbCBvd25lciBhbmQgbmV0 d29yayBvd25lciBhcmUgYWxsb3dlZCB0byBzZWUgdGhlc2UgcmVxdWVzdHMsIHRoZXkgY2FuIGhl bHAvYXNzaXN0IGluIGFjaGlldmluZyB0aGUgZ29vZCBtZWRpYSBwYXRoLiBJZiB0aGV5IGFyZSBu b3QgYXdhcmUsIHRoZXkgY2Fubm90IGhlbHAhDQoNCkhvcGUgdGhpcyBtYWRlIGl0IHVuZGVyc3Rh bmRhYmxlIG9uIGFuIG92ZXJ2aWV3IGxldmVsIGhvdyB0aGlzIGNhbiBiZWNvbWUg4oCcVFVSTuKA pnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnQ0KSXQgaXMgYWxzbyB0aGUgT05MWSB3YXkgSSBj YW4gc2VlIHRvIGFjaGlldmUgd2hhdCB3ZSB3YW50IHRvIGFjaGlldmUgYW5kIHNob3VsZCBiZSB0 aGUgYWltIGFuZCByZXF1aXJlbWVudCBvZiB0aGlzIG1pbGVzdG9uZS4NCg0KSSBhbSB0YWxraW5n IGFib3V0IGdlbmVyYWwgdXNhZ2Ugb2YgV2ViUlRDIG92ZXIgSW50ZXJuZXQvbW9iaWxlIE9UVCAo bm90IGZlZWRpbmcgV2ViUlRDIGludG8gYXBwbGljYXRpb24gc3BlY2lmaWMgbmV0d29ya3MgbGlr ZSBJTVMgd2hlcmUgb3RoZXIgbWV0aG9kcyBtYXkgZXhpc3QpLg0KDQpUaGlzIGlzIGdvb2QsIG5v dCBldmlsIQ0KDQpJZiB0aGUgaGVzaXRhdGlvbnMgYXJlIHJhaXNlZCBiZWNhdXNlIG9mIGEgYmVs aWVmL2hvcGUvd2lzaCB0aGF0IHRoZXJlIGFyZSBubyBvciB3aWxsIG5vdCBiZSBzZXZlcmUgcXVh bGl0eSBpc3N1ZXMg4oCcYmVjYXVzZSBpdCBpcyBhbGwgYWJvdXQgYmFuZHdpZHRo4oCdLCDigJxp dCB3aWxsIHJlc29sdmUgaXRzZWxmIHdpdGggdGltZeKAnSBldGMuLCBJIHN0cm9uZ2x5IG9iamVj dCEgVGhhdCBpcyB3cm9uZyBhbmQgd2lsbCBiZSB2ZXJ5IGRldHJpbWVudGFsIGZvciBXZWJSVEMg dXNhZ2UuIFdlIGFscmVhZHkgc2VlIGl0IGFuZCBJIGNhbiBnaXZlIG51bWVyb3VzIGV4YW1wbGVz IG9mIGhvdyBtdWNoIGxlc3MgcXVhbGl0eSBkZW1hbmRpbmcgVm9JUCBpcy9pcyBub3QgaGFuZGxl ZCBxdWFsaXR5IHdpc2UgYW5kIHRoYXQgaXQgbWF0dGVycy4gQW5kLCB3aGF0IHdvdWxkIGJlIGJh ZCBjb25zaWRlcmluZyBxdWFsaXR5IGlzc3VlcyBhbmQgYWxsb3dpbmcvZW5jb3VyYWdpbmcgbWV0 aG9kcyB0byBkZWFsIHdpdGggdGhlbT8NCg0KSWYgdGhlIGhlc2l0YXRpb25zIGFyZSByYWlzZWQs IGJlY2F1c2Ugb2Ygc3VzcGljaW9uIHRoYXQgdGhlIG1ldGhvZHMgd2UgbWF5IHJlY29tbWVuZCBt YXkgYmUgbWlzdXNlZCB0byBzdG9wL2Jsb2NrL2Rlc3Ryb3kgV2ViUlRDIHVzYWdlIChlLmcuIHRv IHByb3RlY3QgaW5jb21lIGZyb20gY2FycmllciB0ZWxlcGhvbnkgdHJhZmZpYyksIEkgY291bGQg dW5kZXJzdGFuZCBhbmQgd291bGQgZmlnaHQgdGhlIHNhbWUgYmF0dGxlLiBCdXQgaG9wZWZ1bGx5 LCB0aG9zZSBkYXlzIGFyZSAoc29vbikgb3ZlciDigJMgQXQgbGVhc3QgZm9yd2FyZCB0aGlua2lu ZyBjYXJyaWVy4oCZcyByZWFsaXplIHRoYXQgYWxyZWFkeS4gV2ViIFJUQyB3aWxsIGhhcHBlbi4g V2hpY2ggY3VzdG9tZXJzIHdhbnQgdG8gcGF5IGZvciBhbiBhY2Nlc3Mgd2l0aCBibG9ja2VkIFdl YlJUQz8gVGhlIGNhcnJpZXLigJlzIG9mZmVyaW5nL2Fzc3VyaW5nIGdvb2QgV2ViUlRDIHdpbGwg cmF0aGVyIGdldCB0aGUgY3VzdG9tZXJzIGFuZCBpbmNvbWUg4pi6LiAoTWF5YmUgdGhlIFdlYiBi cm93c2VyIGNhbiBkZXRlY3QgYW5kIGVuY291cmFnZSB0aGlz4oCmKQ0KDQpJZiB0aGVyZSBhcmUg dGVjaG5pY2FsIGNvbmNlcm5zIG9mIGJhZCByZXN1bHQsIG9yIGJldHRlciBtZXRob2RzIGFsbG93 aW5nIG5ldHdvcmsgcHJvdmlkZXJzIGFuZCBMQU4gbWFuYWdlcnMgdG8gb2ZmZXIgYW5kIGluZm9y bSB0aGUgYnJvd3NlciB0aGF0IHRoZXJlIGFyZSBnb29kIG1lZGlhIHBhdGhzIHRvIGJlIHVzZWQs IGFuZCB0aGF0IHRoZSB3ZWIgYnJvd3NlciBhdXRvbWF0aWNhbGx5IGNhbiBjaG9zZSB0aG9zZSwg dGhlbiBsZXQgdXMgYWxsIHVuZGVyc3RhbmQgdGhvc2UsIHNvIHdlIGNhbiBhY2hpZXZlIHdoYXQg c2hvdWxkIGJlIGFjaGlldmVkIGJ5IHRoaXMgbWlsZXN0b25lLg0KDQpTa3lwZSwgSGFuZ291dHMs IEZhY2V0aW1lIGFyZSBkb2luZyBiaWxsaW9ucyBvZiBtaW51dGVzIHBlciB3ZWVrIGFuZCB0aGUg SW50ZXJuZXQgaGFzIG5vdCBtZWx0ZWQgeWV0LiBJZiB3ZSBuZWVkIHRvIGRvIGZsb3cgaWRlbnRp ZmljYXRpb24gdG8gYWxsb3cgdHJhZmZpYyB0byBiZSBwcmlvcml0aXplZCwgZmluZSAoc2VlIGFi b3ZlIHJlZ2FyZGluZyBteSBwcmVmZXJyZWQgYXBwcm9hY2gpLCBidXQgZm9yY2luZyBhbGwgV2Vi UlRDIHRyYWZmaWMgdGhyb3VnaCBhIE1JVE0gKFRVUk4gc2VydmVyKSBpcyBhIG11Y2ggYmlnZ2Vy IGp1bXAgdGhhdCBJIGRvbid0IHlldCBzZWUgdGhlIGp1c3RpZmljYXRpb24gZm9yLg0KDQpJbiBz aG9ydDogVFVSTiBpcyBhIHRlY2hub2xvZ3kgdGhhdCBpcyBzdXBwb3NlZCB0byBmYWRlIGF3YXkg d2l0aCB0aGUgbW92ZSB0byBJUHY2LiBJIGRvbid0IHRoaW5rIHdlIHdhbnQgdG8gbWFrZSBpdCBh IGNyaXRpY2FsIGVsZW1lbnQgb2YgV2ViUlRDLg0KDQovS2FybA0KDQoNCkZyw6VuOiBEYW4gV2lu ZyBbbWFpbHRvOmR3aW5nQGNpc2NvLmNvbTxtYWlsdG86ZHdpbmdAY2lzY28uY29tPl0NClNraWNr YXQ6IGRlbiAxMSBmZWJydWFyaSAyMDE0IDE4OjI1DQpUaWxsOiBNYXJjIEJsYW5jaGV0DQpLb3Bp YTogSnVzdGluIFViZXJ0aTsgdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGljaXNj by5jb20+OyBLYXJsIFN0YWhsOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPjsg U2ltb24gUGVycmVhdWx0DQoNCsOEbW5lOiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNl cnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0K DQpPbiBGZWIgMTEsIDIwMTQsIGF0IDk6MDggQU0sIE1hcmMgQmxhbmNoZXQgPG1hcmMuYmxhbmNo ZXRAdmlhZ2VuaWUuY2E8bWFpbHRvOm1hcmMuYmxhbmNoZXRAdmlhZ2VuaWUuY2E+PiB3cm90ZToN Cg0KTGUgMjAxNC0wMi0xMSDDoCAwMDozOSwgRGFuIFdpbmcgPGR3aW5nQGNpc2NvLmNvbTxtYWls dG86ZHdpbmdAY2lzY28uY29tPj4gYSDDqWNyaXQgOg0KDQoNCk9uIEZlYiAxMCwgMjAxNCwgYXQg NTozMCBQTSwgSnVzdGluIFViZXJ0aSA8anViZXJ0aUBnb29nbGUuY29tPG1haWx0bzpqdWJlcnRp QGdvb2dsZS5jb20+PiB3cm90ZToNCg0KR29vZCB0byBzZWUgdGhlcmUgaXMgYSBsb3Qgb2YgaW50 ZXJlc3QgZm9yIHRoaXMgbWlsZXN0b25lLiBCdXQgYmFzZWQgb24gdGhlIGRlc2NyaXB0aW9uIGhl cmUsIGl0IHNlZW1zIGxpa2Ugd2Ugd2FudCB0byB1c2UgVFVSTiBwcmltYXJpbHkgdG8gaWRlbnRp ZnkgV2ViUlRDIGZsb3dzLCBhcyBvcHBvc2VkIHRvIHVzaW5nIGl0IGFzIGEgTkFUIHRyYXZlcnNh bCB0b29sLiBUaGlzIG1ha2VzIG1lIGNvbmNlcm5lZCB0aGF0IHdlIG1heSBiZSB1c2luZyB0aGUg d3JvbmcgdGVjaG5vbG9neSB0byBzb2x2ZSB0aGUgcHJvYmxlbS4NCg0KKzEuDQoNCkkgd291bGQg cHJlZmVyIGFsbG93aW5nIGZsb3dzIHRvIGVzdGFibGlzaCB0aGVtc2VsdmVzIHVzaW5nIHRoZWly ICdiZXN0JyBwYXRoLCBhbmQgdGhlIGJlc3QgcGF0aCBpcyBzZWxkb20gdGhyb3VnaCBhIFRVUk4g c2VydmVyLiAgV2hlbiB3ZSBpbWFnaW5lIElQdjYgaW4gb3VyIGZ1dHVyZSwgd2UgZG9uJ3Qgd2Fu dCB0byBmb3JjZSBhbiBhcHBsaWNhdGlvbi1sZXZlbCBwcm94eSAoVFVSTikgc2VydmVyIG9uIHRo ZSBwYXRoIHNvbGVseSBmb3IgdHJhdmVyc2luZyBhbiBJUHY2IGZpcmV3YWxsLg0KDQoNCkl0IHNl ZW1zIHRoaXMgdGhyZWFkIGlzIGNvbmZsYXRpbmcgYWxsIHRoZSBwb3NzaWJsZSByZWFzb25zIC8g anVzdGlmaWNhdGlvbnMgZm9yIFRVUk46DQogICogbW9iaWxpdHkNCiAgKiBOQVQgdHJhdmVyc2Fs IChib3RoIGVuZHBvaW50cyBhcmUgYmVoaW5kIGVuZHBvaW50LWRlcGVuZGVudCBtYXBwaW5nIE5B VHMpDQogICogZmlyZXdhbGwgdHJhdmVyc2FsIChmaXJld2FsbCBibG9ja3MgVURQKQ0KICAqIGVu aGFuY2luZyBwcml2YWN5DQoNClVuZm9ydHVuYXRlbHkgdGhlIFRVUk4gc2VydmVyIG5vciB0aGUg ZW5kcG9pbnQgcmVhbGx5IGtub3cgd2hpY2ggb2YgdGhvc2UgdXNlLWNhc2VzIGlzIGRlc2lyZWQg KGJ5IHRoZSB1c2VyIG9yIGJ5IHRoZSBJVCBuZXR3b3JrIGFkbWluaXN0cmF0b3IpIG9yIG5lY2Vz c2FyeSAoZm9yIHRoZSBjYWxsIHRvIHdvcmsgYXQgYWxsKS4NCg0KRGFuLCB3aGlsZSBJIGFncmVl IGluIHByaW5jaXBsZSwgSSBkb3VidCB0aGF0IGEgdXNlciBjb3VsZCBldmVyIHNheSAiSSB3YW50 IG1vYmlsaXR5IG9yIEkgd2FudCBOQVQgdHJhdmVyc2FsIi4gSSB0aGluayB0aGUgdXNlciBvbmx5 IHdhbnQgdGhlIGNhbGwgdG8gc3VjY2VlZCwgd2hhdGV2ZXIgdGhlIHByb3BlcnRpZXMgb2YgaXRz IG5ldHdvcmsgcG9pbnQgb2YgYXR0YWNobWVudCBhcmUuDQoNClNvIHdoYXQgY2FuIHdlIGRvPyAg U2hvdWxkIHRoZSBUVVJOIHNlcnZlciBwcm92aWRlIGFueSBhbmQgYWxsIHNlcnZpY2VzIHRoZSBU VVJOIGNsaWVudCBtaWdodCBwb3NzaWJseSB3YW50LCBhcyB0aGF0IGlzIHdoYXQgYSByb2J1c3Qg VFVSTiBzZXJ2ZXIgd2lsbCBkbywgYW5kIHRoZSBlbmRwb2ludCBzaG91bGQgcHJlZmVyIFRVUk4g Y2FuZGlkYXRlcyBvdmVyIGFsbCBvdGhlcnMgYmVjYXVzZSB0aGVyZSBtaWdodCBiZSBzb21lIGZ1 bmN0aW9uYWxpdHkgLyB1c2VmdWxuZXNzIG9mIFRVUk4gdGhhdCB0aGUgdXNlciBtaWdodCBnYWlu IHRocm91Z2ggVFVSTiAoZS5nLiwgZW5oYW5jZWQgcHJpdmFjeSk/DQoNCi1kDQoNCg0KDQogVGhp cyBzZWVtcyBwcm9ibGVtYXRpYy4gIFBlcmhhcHMgd2UgbmVlZCBhIHdheSB0byBzaWduYWwgdGhl IGRlc2lyZWQgdXNlLWNhc2UgKCJ0cmFpdCIpLCBvciBhcyBKdXN0aW4gc3VnZ2VzdHMsIHVzaW5n IGEgZGlmZmVyZW50IHRlY2hub2xvZ3kgZm9yIHNvbWUgb2YgdGhlc2UgdXNlLWNhc2VzLg0KDQot ZA0KDQoNCg0KDQpPbiBNb24sIEZlYiAxMCwgMjAxNCBhdCAzOjE4IFBNLCBLYXJsIFN0YWhsIDxr YXJsLnN0YWhsQGludGVydGV4LnNlPG1haWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlPj4gd3Jv dGU6DQpTaW1vbiwNCg0KR29vZCBxdWVzdGlvbnMgLSBzZWUgaW5saW5lIGJlbG93IC0tPiAuDQpT b21lIG1vcmUgdGhvdWdodCBpcyByZXF1aXJlZCENCg0KL0thcmwNCg0KLS0tLS1VcnNwcnVuZ2xp Z3QgbWVkZGVsYW5kZS0tLS0tDQpGcsOlbjogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPl0gRsO2ciBTaW1vbiBQZXJyZWF1bHQN ClNraWNrYXQ6IGRlbiAxMCBmZWJydWFyaSAyMDE0IDE1OjE2DQpUaWxsOiBLYXJsIFN0YWhsOyB0 cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPjsgdGlyZWRkeUBpY2lzY28uY29tPG1h aWx0bzp0aXJlZGR5QGljaXNjby5jb20+DQrDhG1uZTogUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzog VFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJ U1BzDQoNCkthcmwsDQoNCkl0IGlzIGdyZWF0IHRvIHNlZSBzdWNoIGVudGh1c2lhc20hIFRoYW5r cyENCg0KSSBoYXZlIGEgY291cGxlIHRlY2huaWNhbCBxdWVzdGlvbnMuLi4NCg0KTGUgMjAxNC0w Mi0wOCAwODoxMSwgS2FybCBTdGFobCBhIMOpY3JpdCA6DQo+IC0gTm90ZSB0aGF0IHRvIGFjaGll dmUgc29tZSBvZiB0aGUgYWJvdmUgcG9pbnRzLCBUVVJOIG11c3QgYmUgZmF2b3JlZA0KPiBvdmVy IFNUVU4gdG8gZW5mb3JjZSB0aGF0IHRoZSBUVVJOLXBhdGggYWN0dWFsbHkgaXMgdXNlZC4gKFRo ZSBBbnljYXN0DQo+IG1ldGhvZCBzdWdnZXN0ZWQgYmVsb3csIOKAnGF1dG9tYXRpY2FsbHnigJ0g ZG9lcyB0aGlzLikNCg0KSSB1bmRlcnN0YW5kIHRoZSBTVFVOIHZzIFRVUk4gcHJpb3JpdHkgaXNz dWUuIEJ1dCBJIGRvbid0IHNlZSBob3cgYW55Y2FzdCBhZmZlY3RzIGl0IGluIGFueSB3YXkuIENh biB5b3UgcGxlYXNlIGV4cGxhaW4/DQotLS0gR29vZCBwb2ludCAtIEkgd2FzIGEgYml0IHF1aWNr IGhlcmUgKG1heWJlIHRvbyBxdWljaykNCldlIGhhdmUgZ2l2ZW4gdGhpcyBxdWl0ZSBiaXQgb2Yg dGhvdWdodCwgc2luY2UgZXZlbiBpZiBhIFRVUk4gc2VydmVyIGlzIHByb3ZpZGVkIGFuZCBkaXNj b3ZlcmVkLCBDVVJSRU5UIHVzYWdlIG9mIElDRSBtYXkgc3VnZ2VzdCBhIGNhbmRpZGF0ZSBmcm9t IHRoZSByZW1vdGUgcGFydHkgdGhhdCB3aWxsIG1ha2UgYSBjb25uZWN0aW9uIHdpdGhvdXQgdGhl IG5lZWQvdXNhZ2Ugb2YgdGhlIFRVUk4gc2VydmVyICh0aGF0IHdlIHdhbnRlZCB0byBiZSB1c2Vk IGZvciB0aGUgZ29vZCBwdXJwb3NlcyBsaXN0ZWQpLg0KDQpUaGUgb25seSB3YXkgd2UgZm91bmQg YXJvdW5kIHRoaXMsIHdhcyB0byBzdG9wIFNUVU4gdGhyb3VnaCB0aGUgSVAgZGVmYXVsdCBnYXRl d2F5IChsaWtlIGEgcmVzdHJpY3RpdmUgRW50ZXJwcmlzZSBmaXJld2FsbCBkb2VzIGluaGliaXRp bmcgSUNFIGNvbm5lY3Rpdml0eSwgd2hpY2ggb3RoZXJzIGFyZSBjb25jZXJuZWQgYWJvdXQuLi4p LiBTaW5jZSB0aGUgcHJvdmlzaW9uaW5nIG9mIGF1dG8tZGlzY292ZXJ5IHVzaW5nIHRoZSBhbnlj YXN0IG1lY2hhbmlzbSwgd291bGQgYmUgYWRkaW5nIGEgcm91dGUgaW4gYSBkZWZhdWx0IGdhdGV3 YXksIGFkZGluZyBhIGZpcmV3YWxsIHJ1bGUgdG8gZWF0IFNUVU4gcGFja2V0cyB3b3VsZCBhc3N1 cmUgdGhhdCB0aGUgcHJvdmlzaW9uZWQgVFVSTiBzZXJ2ZXIgYWN0dWFsbHkgYmVjb21lcyB1c2Vk IChhbmQgbm90IGJ5cGFzc2VkICJieSBhY2NpZGVudCIpLiAoVGhhdCB3YXMgdGhlIHRob3VnaHQg YmVoaW5kIHRoZSDigJxhdXRvbWF0aWNhbGx54oCdIHdpdGhpbiBxdW90ZXMuKQ0KDQpCVVQsIHNp bmNlIHlvdSBicm91Z2h0IHVwIHRoZSBxdWVzdGlvbiwgYXNzdW1pbmcgdGhhdCB3ZSBoYXZlIHRo ZSBwb3dlciB0byBlbmZvcmNlIFdlYlJUQyB1c2FnZSBvZiBJQ0UsIEkgYmVsaWV2ZSBhIE1VU1Qg cmVxdWlyZW1lbnQgdG8gdXNlIGFuIGF1dG8tZGlzY292ZXJlZCBUVVJOIHNlcnZlciBpbnN0ZWFk IG9mIFNUVU4sIHdvdWxkIHNvbHZlIHRoZSBzYW1lIHByb2JsZW0uIEhvd2V2ZXIsIHRoaW5raW5n IGZ1cnRoZXIgKGluIHJlbGF0aW9uIHRvIHlvdXIgbmV4dCBxdWVzdGlvbiAtICJhbnlvbmUgY291 bGQgc2V0IHVwIGEgYmFkbHktbWFpbnRhaW5lZCIgLSBlbmZvcmNpbmcgc3VjaCBJQ0UgdXNhZ2Ug bWF5IG5vdCBiZSBnb29kLikNCg0KDQo+IC0gM15yZCBUaGUgQW55Y2FzdCBtZXRob2QgYmVsb3cg 4oCTIEkgc2VlIG5vIHByb2JsZW0NCj4NCj4gSXQgYWxzbyBoYXMgdGhlIGFkdmFudGFnZSBvZiBl bmNvdXJhZ2luZyAoYnV0IG5vdCByZXF1aXJpbmcpIHRoZQ0KPiBTVFVOL1RVUk4gdG8gYmUgYnVp bHQgaW4gdGhlIGRlZmF1bHQgZ2F0ZXdheSBvciBOQVQvZmlyZXdhbGwvYWNjZXNzDQo+IHJvdXRl ciBpdHNlbGYsIHdpdGggYSBzZWNvbmQgaW50ZXJmYWNlIHRvIGEgcHVibGljIElQIGFkZHJlc3Mg b24gdGhlDQo+IFdBTiBzaWRlLiAoQ3VycmVudCB2b2x1bWUgZGVwbG95ZWQsIGxvdyBjb3N0IE5T UCB0cmlwbGUgcGxheSBtb2RlbXMNCj4gdXN1YWxseSBoYXZlIGEgcXVhbGl0eSBhc3N1cmVkIGxl dmVsIDIgb3IgbGV2ZWwgMyBXQU4gcGlwZSBmb3IganVzdA0KPiB2b2ljZSAoYW5kIGFub3RoZXIg Zm9yIElQVFYpIOKAkyBUaGUgYW55Y2FzdCBkaXNjb3ZlcmVkIFRVUk4tc2VydmVyIGNhbg0KPiBi ZSB0aGUgYWNjZXNzIGdhdGV3YXkgdG8gc3VjaCBxdWFsaXR5IHBpcGUgZm9yIFdlYlJUQyBtZWRp YSwgaW4gYQ0KPiBzaW5nbGUgTlNQIHByb3ZpZGVkIENQRSwgc2NhbGluZyBmcm9tIHJlc2lkZW50 aWFsIGFuZCB1cC4pDQoNClN1cHBvc2Ugd2UgZGVmaW5lIHdlbGwta25vd24gYW55Y2FzdCBUVVJO IHNlcnZlciBhZGRyZXNzZXMuIEhvdyB3b3VsZCB0aGlzIG5vdCBiZSBzdWJqZWN0IHRvIHRoZSBz YW1lIHNlcnZpY2UgcXVhbGl0eSBpc3N1ZXMgdGhhdCBwbGFndWVkIDZ0bzQ/IFRoYXQgaXMsIGFu eW9uZSBjb3VsZCBzZXQgdXAgYSBiYWRseS1tYWludGFpbmVkLCB1bmRlci1wcm92aXNpb25lZCBU VVJOIHNlcnZlciBhbmQgYW5ub3VuY2UgaXQgb3ZlciBCR1AgdG8gdGhlIHdvcmxkLCBhcyBpdCB3 YXMgZG9uZSBmb3INCjZ0bzQgcmVsYXlzLiBPciBqdXN0IGJhZCBCR1Agb3V0Ym91bmQgZmlsdGVy IGNvbmZpZ3VyYXRpb24uIEFuZCBob3cgY2FuIHdlIHByZXZlbnQgdHJpYW5nbGUgcm91dGluZz8g VGhlcmUgaXMgbm90aGluZyBndWFyYW50ZWVpbmcgdGhhdCB0aGUgYW55Y2FzdCBzZXJ2ZXIgeW91 IHNlZSBpcyBiZWluZyBwcm92aWRlZCB0byB5b3UgYnkgeW91ciBJU1AsIHJhdGhlciB0aGFuIGEg c2VydmVyIHNpdHRpbmcgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIHBsYW5ldC4NCi0tLSBHb29k IHBvaW50IC0gbmVlZHMgdG8gYmUgcmVzb2x2ZWQuIEZvciB0aGlzIEkgZG9uJ3QgaGF2ZSBhIHJl YWR5IGFuc3dlci4uLg0KQW4gYXV0by1kaXNjb3ZlcmVkIFRVUk4gc2VydmVyIG11c3QgYmUgdHJ1 c3RlZCAod2hhdGV2ZXIgbWV0aG9kIGl0IGlzIGRpc2NvdmVyZWQgYnkpLiBXZSBhcmUgdHJ1c3Rp bmcgdGhlIG9uZSBwcm92aWRpbmcgdXMgd2l0aCBhbiBJUCBhZGRyZXNzIGFuZCBkZWZhdWx0IGdh dGV3YXkgYW55d2F5LiBJdCB3b3VsZCBiZSBlYXN5IGlmIHdlIGNvdWxkIHJldXNlIHRoYXQgdHJ1 c3QsIGluc3RlYWQgb2YgYW5vdGhlciBtZWNoYW5pc21zLg0KDQpJcyB0aGVyZSBhIGdvb2Qgd2F5 IGZvciB0aGUgYnJvd3NlciB0byBjaGVjayB0aGF0IHRoZSBhbnljYXN0IGFkZHJlc3MgaXMgbm90 IGhhbmRsZWQgYmV5b25kIHRoZSBuZXR3b3JrIHNlcnZpY2UgcHJvdmlkZXIncyBkZWZhdWx0IGdh dGV3YXk/IElkZWFzPw0KDQoNCg0KVGhhbmtzLA0KU2ltb24NCi0tDQpEVE4gbWFkZSBlYXN5LCBs ZWFuLCBhbmQgc21hcnQgLS0+IGh0dHA6Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUuY2E8aHR0cDov L3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5jYS8+DQpOQVQ2NC9ETlM2NCBvcGVuLXNvdXJjZSAgICAg ICAgLS0+IGh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhPGh0dHA6Ly9lY2R5c2lzLnZpYWdlbmll LmNhLz4NClNUVU4vVFVSTiBzZXJ2ZXIgICAgICAgICAgICAgICAtLT4gaHR0cDovL251bWIudmlh Z2VuaWUuY2E8aHR0cDovL251bWIudmlhZ2VuaWUuY2EvPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYu b3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90cmFtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5n IGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3Jn PG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90cmFtDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQoN Cg== --_000_9F33F40F6F2CD847824537F3C4E37DDF17CF5660MCHP04MSXglobal_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5PbmUgc3VjaCBlbmhhbmNlbWVudCBpcyBkZXNjcmliZWQgaW4NCjwvc3Bh bj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb2huc3Rvbi10cmFt LXN0dW4tb3JpZ2luLTAxIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb2huc3Rv bi10cmFtLXN0dW4tb3JpZ2luLTAxPC9hPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgW21haWx0bzp0aXJlZGR5QGNpc2NvLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAxMyBGZWJydWFyeSAyMDE0IDE1OjM0PGJyPg0KPGI+VG86 PC9iPiBIdXR0b24sIEFuZHJldzxicj4NCjxiPkNjOjwvYj4gdHJhbUBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSRTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRp c2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SGkgQW5keSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgV2ViUlRDIGJyb3dzZXIg d2lsbCBoYXZlIHRvIGEgc3VwcG9ydCBhIG51bWJlciBvZiBtZWNoYW5pc21zLiBUaGlzIHdhcyBk aXNjdXNzZWQgaW4gUlRDV0VCIG1haWxpbmcgbGlzdCBzb21ldGltZSBiYWNrIGFuZCBzZWN0aW9u IDMuMy40LjEgaW4NCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0Ij4NCmh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRz LTE0PC9hPiBoYXMgYmVlbiB1cGRhdGVkIHRvIHJlZmxlY3QgdGhpcyBwb2ludC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB0aGUgZW5oYW5jZW1l bnRzIFRVUk4gc2VydmVyIHlvdSBhcmUgbG9va2luZyBmb3IgYW5kIHdoYXQgcHJvYmxlbXMgZG9l cyBpdCBzb2x2ZSA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBIdXR0b24sIEFuZHJldyBbPGEg aHJlZj0ibWFpbHRvOmFuZHJldy5odXR0b25AdW5pZnkuY29tIj5tYWlsdG86YW5kcmV3Lmh1dHRv bkB1bmlmeS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAx MywgMjAxNCA0OjE4IFBNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVk ZHkpPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyI+dHJhbUBp ZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFt0cmFtXSBNaWxlc3RvbmUgMzog VFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJ U1BzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBwcmltZSB1c2UgY2FzZSBm b3IgdGhpcyBpcyBkb2N1bWVudGVkIGluDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xMiNzZWN0 aW9uLTMuMy41LjEiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3 ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTIjc2VjdGlvbi0zLjMuNS4xPC9hPiBhbmQg SSB0aGluayB0aGF0IFRSQU0gd2lsbCBwcm9iYWJseSBtYWtlIGVuaGFuY2VtZW50cyB0byBUVVJO IGVuYWJsaW5nIHN1Y2ggYW4g4oCcZW50ZXJwcmlzZSBhdWRpdGluZyBUVVJOIHNlcnZlcuKAnSB0 byBkbyBhbiBlZmZlY3RpdmUgam9iIG9mIG1hbmFnaW5nIFdlYlJUQyB0cmFmZmljDQogaW4gYW4g ZW50ZXJwcmlzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGFyZSBvZiBjb3Vyc2UgbW9yZSB0aGFuIG9uZSBw cm9ibGVtIGFuZCBtYW55IHBvc3NpYmx5IHdheXMgdG8gc29sdmUgdGhlbSBhbmQgSSByZWNlbnRs eSB1cGRhdGVkDQo8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odXR0 b24tcnRjd2ViLW5hdC1maXJld2FsbC1jb25zaWRlcmF0aW9ucy0wMyI+DQpodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1odXR0b24tcnRjd2ViLW5hdC1maXJld2FsbC1jb25zaWRlcmF0 aW9ucy0wMzwvYT4gdG8gbGlzdCB0aGVzZSBmb3IgZGlzY3Vzc2lvbiBpbmNsdWRpbmcgUENQLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VW5mb3J0dW5hdGVseSBzb2x1dGlvbnMgYXJlIG5lZWRlZCB0b2RheSB3aXRoaW4g ZXhpc3RpbmcgbmV0d29ya3MgYW5kIFBDUCBkb2VzIG5vdCBzZWVtIHNvIHVzZWZ1bCBoZXJlIHNv IHdlIGhhdmUgdG8gbG9vayBhdCBtdWx0aXBsZSBzb2x1dGlvbnMgYW5kIHByb2JhYmx5DQogV2Vi UlRDIGJyb3dzZXJzIGhhdmUgdG8gc3VwcG9ydCBhIG51bWJlciBvZiBtZWNoYW5pc21zLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmR5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGly dW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSBbPGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAY2lzY28u Y29tIj5tYWlsdG86dGlyZWRkeUBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IDEz IEZlYnJ1YXJ5IDIwMTQgMDM6Mzc8YnI+DQo8Yj5Ubzo8L2I+IEh1dHRvbiwgQW5kcmV3OyBKdXN0 aW4gVWJlcnRpOyBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKTxicj4NCjxiPkNj OjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbSI+dGlyZWRkeUBpY2lzY28u Y29tPC9hPjsgU2ltb24gUGVycmVhdWx0OyBPbGVnIE1vc2thbGVua287DQo8YSBocmVmPSJtYWls dG86dHJhbUBpZXRmLm9yZyI+dHJhbUBpZXRmLm9yZzwvYT47IE1hcmMgQmxhbmNoZXQ7IERhbiBX aW5nIChkd2luZyk7IEthcmwgU3RhaGw8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFt0cmFtXSBN aWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRl cnByaXNlIGFuZCBJU1BzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEFuZHks PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGVyZSBhcmUgb3RoZXIgd2F5cyB0byBzb2x2ZSB0aGUgcHJvYmxlbSBmb3Ig ZXhhbXBsZSB1c2luZyBQQ1AuIENhbiB5b3UgY2xhcmlmeSBob3cgZGVwbG95aW5nIGEgVFVSTiBz ZXJ2ZXIgaW4gdGhlIEVudGVycHJpc2UgcHJvdGVjdHMgdGhlIHVzZXJzIGFuZCB0aGUgbmV0d29y aw0KID8gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4tVGlydS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0cmFtIFs8YSBocmVmPSJtYWlsdG86dHJh bS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+SHV0dG9uLCBBbmRyZXc8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIEZlYnJ1YXJ5IDEzLCAyMDE0IDE6MDAgQU08YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBVYmVy dGk7IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpPGJyPg0KPGI+Q2M6PC9iPiA8 YSBocmVmPSJtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tIj50aXJlZGR5QGljaXNjby5jb208L2E+ OyBTaW1vbiBQZXJyZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsNCjxhIGhyZWY9Im1haWx0bzp0cmFt QGlldGYub3JnIj50cmFtQGlldGYub3JnPC9hPjsgTWFyYyBCbGFuY2hldDsgRGFuIFdpbmcgKGR3 aW5nKTsgS2FybCBTdGFobDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1dIE1pbGVzdG9u ZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2Ug YW5kIElTUHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGNhc2Ugd2hlcmUg dGhlIFRVUk4gc2VydmVyIGlzIHRoZSBvbmx5IG9wdGlvbiBtYXkgYmVjb21lIGNvbW1vbiB3aXRo aW4gZW50ZXJwcmlzZSBuZXR3b3JrcyBhbmQgdGhhdCBtaWdodCBiZSBkZWxpYmVyYXRlIGVudGVy cHJpc2UgcG9saWN5IGJlY2F1c2UgaXQgcHJvdmlkZXMNCiB0aGUgYmV0dGVyIHBhdGggKFVEUCB0 aHJvdWdoIHRoZSBGL1cpIGFuZCBwcm90ZWN0cyB0aGUgdXNlcnMgYW5kIHRoZSBuZXR3b3JrLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBbPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5tYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0K PGI+U2VudDo8L2I+IDEyIEZlYnJ1YXJ5IDIwMTQgMTc6NDY8YnI+DQo8Yj5Ubzo8L2I+IE11dGh1 IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpPGJyPg0KPGI+Q2M6PC9iPiA8L3NwYW4+PGEg aHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPnRpcmVkZHlAaWNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjsgU2ltb24gUGVycmVhdWx0OyBPbGVnIE1vc2thbGVua287DQo8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnRyYW1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGll dGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBNYXJjIEJsYW5j aGV0OyBEYW4gV2luZyAoZHdpbmcpOyBLYXJsIFN0YWhsPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlz bSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZS4gSWYgVFVSTiBpcyBpbmRlZWQgYmVpbmcgcHJv dmlkZWQgZm9yIHRoZSB1c2VyJ3MgYmVuZWZpdCwgdGhlIGNsaWVudCdzIElDRSBsb2dpYyAoYmFz ZWQgb24gUlRUIG9yIHNpbWlsYXIpIHNob3VsZCByZXN1bHQgaW4gaXQgcHJlZmVycmluZyB0aGUg VFVSTiBwYXRoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAxMiwgMjAxNCBhdCAxOjI3 IEFNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1wZXJ1bWFsQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1wZXJ1bWFsQGNpc2NvLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5ZZXMsIEkgYmVsaWV2ZSB0aGUgc2Vjb25kIGNhc2UgaXMg cmFyZSwgYnV0IHdvdWxkIGJlIGJldHRlciB0aGFuIGEgcmF0IHJhY2UgYi93IGFkbWluaXN0cmF0 b3JzIHRyeWluZyB0byBibG9jayBwMnAgdHJhZmZpYw0KIGFuZCBmb3JjZSBpdCB0aHJvdWdoIGEg VFVSTiBzZXJ2ZXIgYW5kIGFwcHMvZW5kcG9pbnRzIGZpbmRpbmcgc21hcnRlciB3YXlzIHRvIGJ5 cGFzcyB0aGVtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPk11dGh1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBPbGVnIE1vc2thbGVua28gW21h aWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+bW9tMDQwMjY3QGdtYWlsLmNvbTwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0IDE6MDcgUE08YnI+DQo8Yj5Ubzo8L2I+IE11 dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpPGJyPg0KPGI+Q2M6PC9iPiBKdXN0aW4g VWJlcnRpOyBLYXJsIFN0YWhsOyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2Nv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50aXJlZGR5 QGljaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47DQogTWFy YyBCbGFuY2hldDsgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47IERhbiBXaW5nIChkd2luZyk7IFNpbW9u IFBlcnJlYXVsdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6 IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQg SVNQczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgVFVSTiBzZXJ2ZXIgaGFzIHRvIGJlIHVz ZWQgd2hlbiBpdCBpcyBlaXRoZXIgdGhlIG9ubHkgb3B0aW9uLCBvciBpZiBpdCBwcm92aWRlcyBh IGJldHRlciBwYXRoIChJIGd1ZXNzIHRoZSBzZWNvbmQgY2FzZSBpcyByYXRoZXIgcmFyZSkuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgRmViIDExLCAyMDE0IGF0 IDExOjMyIFBNLCBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1wZXJ1bWFsQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1wZXJ1bWFsQGNp c2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mIzQzOzE8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5Gb3JjaW5nIGFsbCB0cmFm ZmljIHRocm91Z2ggYSBUVVJOIHNlcnZlciBhbmQgZXhwZWN0aW5nIGl0IHdvdWxkIHByb3ZpZGUg dGhlIGJlc3QgdXNlciBleHBlcmllbmNlIGRvZXNuJ3QgbG9vayB0aGUgcmlnaHQNCiBhcHByb2Fj aC4gSW5zdGVhZCwgaWYgYSBwYXRoIHRocm91Z2ggYSBUVVJOIHNlcnZlciBleGlzdHMgYW5kIGRv ZXMgcHJvdmlkZSBsb3dlciBSVFQsIGppdHRlciBldGMsIGJlaW5nIGFibGUgdG8gZGV0ZWN0IGFu ZCB1c2UgKG9yIHN3aXRjaCB0bykgdGhhdCBwYXRoIG1pZ2h0IGJlIGRlc2lyYWJsZS4uPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ TXV0aHU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRyYW0gW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OnRyYW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij50cmFtLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBVYmVydGk8YnI+DQo8 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAxNCAxMTo0MyBBTTxicj4NCjxi PlRvOjwvYj4gS2FybCBTdGFobDxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1haWx0 bzp0aXJlZGR5QGljaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+dGlyZWRkeUBpY2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+OyBNYXJjIEJsYW5jaGV0Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1A aWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47IERhbiBXaW5n IChkd2luZyk7IFNpbW9uIFBlcnJlYXVsdDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1d IE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVu dGVycHJpc2UgYW5kIElTUHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW5saW5lLjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZlYiAxMSwgMjAxNCBhdCAyOjM3IFBN LCBLYXJsIFN0YWhsICZsdDs8YSBocmVmPSJtYWlsdG86a2FybC5zdGFobEBpbnRlcnRleC5zZSIg dGFyZ2V0PSJfYmxhbmsiPmthcmwuc3RhaGxAaW50ZXJ0ZXguc2U8L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkxpc3RlbmluZyB0byB0aGlzIHRocmVhZCwg SSBhbSBhZnJhaWQgd2UgYXJlIG1pc3NpbmcgdGhlIHZlcnkgcG9pbnQgYW5kIG5lY2Vzc2l0eSBm b3IgdGhpcyBtaWxlc3RvbmUhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0gVGhlcmUgYXJl IHNldmVyZSBOQVQgdHJhdmVyc2FsIGFuZCBxdWFsaXR5IGlzc3VlcyB0aGF0IHNob3VsZCBhbmQg Y2FuIGJlIGRlYWx0IHdpdGggYnkgYSBnb29kIGF1dG8tZGlzY292ZXJ5DQogbWVjaGFuaXNtIGFu ZCB0aGUgcmlnaHQgdXNhZ2UgYnkgdGhlIHR1cm4gY2xpZW50ICh0aGUgV2ViUlRDIGJyb3dzZXIp PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj5UaGVyZSBhcmUgd2F5cywgbm90IG9ubHk6DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkVudGVycHJp c2VzIG9yIElTUHMgd2lzaGluZyB0byBwcm92aWRlIHRoZWlyIG93biBUVVJOIHNlcnZlciwgaW4g YW4gYXR0ZW1wdCB0byByZWR1Y2Ugc28tY2FsbGVkICZxdW90O3RyaWFuZ2xlIHJvdXRpbmcmcXVv dDssbmVlZCBhIG5ldyBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc208L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6Ymx1ZSI+QnV0IGFsc286IC0gTlNQcyAoTmV0d29yayBTZXJ2aWNlIFByb3ZpZGVycykgd2Fu dCB0byBwcm92aWRlIGEgcGF0aCB3aGVyZSB0aGUgYmFuZHdpZHRoIG9mIFdlYlJUQyBpcyBiZXR0 ZXINCiBjb3BlZCB3aXRoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LSBOU1Bz IG9yIEVudGVycHJpc2VzIHdhbnQgdG8gb2ZmZXIgYW4gSW50ZXJuZXQgYWNjZXNzIHF1YWxpdHkg cGlwZSBmb3IgcHJpb3JpdGl6ZWQgUlRDIChSZWFsIFRpbWUgQ29tbXVuaWNhdGlvbikNCiB0cmFm ZmljLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LSBFbnRlcnByaXNlcyBoYXZpbmcgcmVz dHJpY3RpdmUgZmlyZXdhbGxzLCB3YW50IHRvIHByb3ZpZGUgYSBVRFAtcGF0aCBmb3IgV2ViUlRD IGFuZCBwb3NzaWJseSBhbHNvIGZvcg0KIGJldHRlciBxdWFsaXR5IHdoZXJlIFJUQyBkbyBub3Qg Y29tcGV0ZSB3aXRoIGRhdGEgdHJhZmZpYy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+QWxzbyBjb25zaWRlcmluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ LSBNb2JpbGl0eTsgSXQgaXMgY29tbW9uIHRvIG1vdmUgZnJvbSBhIExBTiB0byBhY2Nlc3Npbmcg dmlhIFdpRmkgb3IgM0cvNEcgT1RUIGNoYW5uZWxzLCBhbGwgc2hvdWxkIGJlDQogYWJsZSB0byBh dXRvbWF0aWNhbGx5IG9mZmVyIHRoZWlyIG93biBvcHRpbWFsIFRVUk4gc2VydmVyPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPlRoaXMgbGVhZHMgdXMgaW50bw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwO+KAnFRVUk7igKZ0byBpZGVudGlmeSBXZWJSVEMgZmxvd3PigJ0NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibHVlIj5ldGMhIEl0IGlzIG5vdCBhIG1pc3Rha2UsIGJ1dCB0aGUgdmVyeSBu ZWVkIGZvciB0aGlzIG1pbGVzdG9uZSE8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BZ2FpbiwgaXQg aGFzIG5vdCBiZWVuIGRlbW9uc3RyYXRlZCB3aHkgVFVSTiBpcyB0aGUgcmlnaHQgdGVjaG5vbG9n eSBoZXJlLCBjb21wYXJlZCB0byBhIG1vcmUgdHJhbnNwYXJlbnQgZmxvdyBpZGVudGlmaWNhdGlv biB0b29sIGxpa2UgTUFMSUNFLiBXZSBkb24ndCBmb3JjZSBhbGwgSFRUUCByZXF1ZXN0cw0KIHRv IGxvY2F0ZSBhIEhUVFAgcHJveHkgdmlhIGFueWNhc3QsIEkgZG9uJ3Qgc2VlIHdoeSB3ZSBuZWVk IHRvIGRvIHRoZSBzYW1lIGZvciBXZWJSVEMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPldoYXQgYXJlIHRo ZSBoZXNpdGF0aW9ucyByYWlzZWQgaGVyZT88L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7 IFRVUk4gcHJpbWFyaWx5IHRvIGlkZW50aWZ5IFdlYlJUQyBmbG93cywgYXMgb3Bwb3NlZCB0byB1 c2luZyBpdCBhcyBhIE5BVCB0cmF2ZXJzYWwgdG9vbC4gVGhpcyBtYWtlcyBtZSBjb25jZXJuZWQN CiB0aGF0IHdlIG1heSBiZSB1c2luZyB0aGUgd3JvbmcgdGVjaG5vbG9neSB0byBzb2x2ZSB0aGUg cHJvYmxlbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkl0IGlzIGNvcnJlY3Qg dGhhdCBJQ0UvU1RVTi9UVVJOIHdhcyBkZXNpZ25lZCB0byBhZGRyZXNzIHRoZSBOQVQvRmlyZXdh bGwgdHJhdmVyc2FsIHByb2JsZW0gYXNzb2NpYXRlZA0KIHdpdGggcmVhbC10aW1lIGNvbW11bmlj YXRpb24gKFNJUCBhdCB0aGF0IHRpbWUpLiBIb3dldmVyLCBpdHMgbGFyZ2VzdCBmbGF3L3Byb2Js ZW0gaXMgdGhhdCBxdWFsaXR5IHRoaW5ncyB3ZXJlIG5vdCAoY291bGQgbm90IGJlPykgY29uc2lk ZXJlZC4gVGhlIG1ldGhvZOKAmXMgdmVyeSBpZGVhIChsaWtlIGFsbCBzaW1pbGFyIG1ldGhvZHMg Zm9yIGdldHRpbmcgUlRDIHRocm91Z2ggb3JkaW5hcnkgTkFUL0ZpcmV3YWxscykgaXMgdG8gZm9v bCB0aGUgbWVkaWENCiB0aHJvdWdoIGEgTkFUL0ZpcmV3YWxsIHRoYXQgaXMgdW5hd2FyZSBvZiB3 aGF0IGlzIGhhcHBlbmluZy4gVGh1cywgdGhpcyBpcyByb290IG9mIHF1YWxpdHkgaXNzdWVzIChh bmQgYmFuZHdpZHRoIGFsbG9jYXRpb24gb3B0aW1pemF0aW9uKSB0aGF0IG5lZWRzIHRvIGJlIGRl YWx0IHdpdGg6IFJlYWwtdGltZSB0cmFmZmljIGZpZ2h0aW5nIHdpdGggYSBkYXRhIHRyYWZmaWMg Y3Jvd2RlZCBjb25nZXN0aW9uIHBvaW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SSB0aGluayB0aGF0ICZxdW90O2Zvb2xpbmcmcXVvdDsgaXMgYW4gaW5jb3JyZWN0IGRlc2NyaXB0 aW9uLiBUaGUgTkFUIGlzIHN1cHBvc2VkIHRvIGJlIHRyYW5zcGFyZW50IHRvIHRoZSBjbGllbnQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPkJ1dCwgYSBCTEVTU0lORyBvZiBJQ0UvU1RVTi9UVVJOIGlzIHRoYXQgaXQg Y2FuIGJlIHNlZW4gYXMgYSBsZWdpdGltYXRlIHJlcXVlc3QgZm9yIGEgc3VpdGFibGUgcGlwZSBm b3INCiBxdWFsaXR5IGRlbWFuZGluZyByZWFsIHRpbWUgdHJhZmZpYy4gPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibHVlIj5K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+DQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+SUNFIGlzIGEgcHJlLXByb3RvY29sIHlvdSB1c2UgYmVjYXVzZSB5 b3Ugd2FudCBhIHBhdGggZm9yIHJlYWwtdGltZSBtZWRpYSBiZXR3ZWVuIHBhcnRpZXMuIEhlcmU6 IFRoZSBicm93c2VyDQogc2F5cyBrbm9jayBrbm9jaywgSSB3YW50IHRvIGdldCBtZWRpYSB0aHJv dWdoIChhbmQgb2YgY291cnNlIHdpdGggYXMgZ29vZCBxdWFsaXR5IGFzIHJlcXVpcmVkIGFuZCBw b3NzaWJsZSkuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsdWUiPklmIHRoZSBOQVQvRmlyZXdhbGwgb3duZXIgYW5kIG5ldHdvcmsgb3du ZXIgYXJlIGFsbG93ZWQgdG8gc2VlIHRoZXNlIHJlcXVlc3RzLCB0aGV5IGNhbiBoZWxwL2Fzc2lz dCBpbg0KIGFjaGlldmluZyB0aGUgZ29vZCBtZWRpYSBwYXRoLiBJZiB0aGV5IGFyZSBub3QgYXdh cmUsIHRoZXkgY2Fubm90IGhlbHAhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPkhvcGUgdGhpcyBtYWRlIGl0IHVuZGVyc3RhbmRhYmxlIG9uIGFuIG92ZXJ2aWV3IGxl dmVsIGhvdyB0aGlzIGNhbiBiZWNvbWU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+DQog4oCcVFVSTuKApnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj5JdCBpcyBhbHNvIHRoZSBPTkxZIHdheSBJIGNhbiBzZWUgdG8gYWNoaWV2 ZSB3aGF0IHdlIHdhbnQgdG8gYWNoaWV2ZSBhbmQgc2hvdWxkIGJlIHRoZSBhaW0gYW5kIHJlcXVp cmVtZW50DQogb2YgdGhpcyBtaWxlc3RvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JIGFtIHRhbGtpbmcgYWJvdXQgZ2VuZXJh bCB1c2FnZSBvZiBXZWJSVEMgb3ZlciBJbnRlcm5ldC9tb2JpbGUgT1RUIChub3QgZmVlZGluZyBX ZWJSVEMgaW50byBhcHBsaWNhdGlvbg0KIHNwZWNpZmljIG5ldHdvcmtzIGxpa2UgSU1TIHdoZXJl IG90aGVyIG1ldGhvZHMgbWF5IGV4aXN0KS4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5UaGlzIGlzIGdvb2QsIG5vdCBldmlsITwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1 ZSI+SWYgdGhlIGhlc2l0YXRpb25zIGFyZSByYWlzZWQgYmVjYXVzZSBvZiBhIGJlbGllZi9ob3Bl L3dpc2ggdGhhdCB0aGVyZSBhcmUgbm8gb3Igd2lsbCBub3QgYmUgc2V2ZXJlIHF1YWxpdHkNCiBp c3N1ZXMg4oCcYmVjYXVzZSBpdCBpcyBhbGwgYWJvdXQgYmFuZHdpZHRo4oCdLCDigJxpdCB3aWxs IHJlc29sdmUgaXRzZWxmIHdpdGggdGltZeKAnSBldGMuLCBJIHN0cm9uZ2x5IG9iamVjdCEgVGhh dCBpcyB3cm9uZyBhbmQgd2lsbCBiZSB2ZXJ5IGRldHJpbWVudGFsIGZvciBXZWJSVEMgdXNhZ2Uu IFdlIGFscmVhZHkgc2VlIGl0IGFuZCBJIGNhbiBnaXZlIG51bWVyb3VzIGV4YW1wbGVzIG9mIGhv dyBtdWNoIGxlc3MgcXVhbGl0eSBkZW1hbmRpbmcgVm9JUA0KIGlzL2lzIG5vdCBoYW5kbGVkIHF1 YWxpdHkgd2lzZSBhbmQgdGhhdCBpdCBtYXR0ZXJzLiBBbmQsIHdoYXQgd291bGQgYmUgYmFkIGNv bnNpZGVyaW5nIHF1YWxpdHkgaXNzdWVzIGFuZCBhbGxvd2luZy9lbmNvdXJhZ2luZyBtZXRob2Rz IHRvIGRlYWwgd2l0aCB0aGVtPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj5JZiB0aGUgaGVzaXRhdGlvbnMgYXJlIHJhaXNlZCwgYmVjYXVzZSBvZiBzdXNwaWNpb24g dGhhdCB0aGUgbWV0aG9kcyB3ZSBtYXkgcmVjb21tZW5kIG1heSBiZSBtaXN1c2VkIHRvDQogc3Rv cC9ibG9jay9kZXN0cm95IFdlYlJUQyB1c2FnZSAoZS5nLiB0byBwcm90ZWN0IGluY29tZSBmcm9t IGNhcnJpZXIgdGVsZXBob255IHRyYWZmaWMpLCBJIGNvdWxkIHVuZGVyc3RhbmQgYW5kIHdvdWxk IGZpZ2h0IHRoZSBzYW1lIGJhdHRsZS4gQnV0IGhvcGVmdWxseSwgdGhvc2UgZGF5cyBhcmUgKHNv b24pIG92ZXIg4oCTIEF0IGxlYXN0IGZvcndhcmQgdGhpbmtpbmcgY2FycmllcuKAmXMgcmVhbGl6 ZSB0aGF0IGFscmVhZHkuIFdlYiBSVEMgd2lsbA0KIGhhcHBlbi4gV2hpY2ggY3VzdG9tZXJzIHdh bnQgdG8gcGF5IGZvciBhbiBhY2Nlc3Mgd2l0aCBibG9ja2VkIFdlYlJUQz8gVGhlIGNhcnJpZXLi gJlzIG9mZmVyaW5nL2Fzc3VyaW5nIGdvb2QgV2ViUlRDIHdpbGwgcmF0aGVyIGdldCB0aGUgY3Vz dG9tZXJzIGFuZCBpbmNvbWUNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6Ymx1ZSI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi4gKE1heWJlIHRoZSBXZWIgYnJvd3NlciBjYW4gZGV0ZWN0 IGFuZCBlbmNvdXJhZ2UgdGhpc+KApik8L3NwYW4+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JZiB0aGVyZSBhcmUgdGVjaG5p Y2FsIGNvbmNlcm5zIG9mIGJhZCByZXN1bHQsIG9yIGJldHRlciBtZXRob2RzIGFsbG93aW5nIG5l dHdvcmsgcHJvdmlkZXJzIGFuZCBMQU4gbWFuYWdlcnMNCiB0byBvZmZlciBhbmQgaW5mb3JtIHRo ZSBicm93c2VyIHRoYXQgdGhlcmUgYXJlIGdvb2QgbWVkaWEgcGF0aHMgdG8gYmUgdXNlZCwgYW5k IHRoYXQgdGhlIHdlYiBicm93c2VyIGF1dG9tYXRpY2FsbHkgY2FuIGNob3NlIHRob3NlLCB0aGVu IGxldCB1cyBhbGwgdW5kZXJzdGFuZCB0aG9zZSwgc28gd2UgY2FuIGFjaGlldmUgd2hhdCBzaG91 bGQgYmUgYWNoaWV2ZWQgYnkgdGhpcyBtaWxlc3RvbmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Ta3lwZSwgSGFuZ291dHMsIEZhY2V0aW1lIGFyZSBkb2luZyBiaWxsaW9ucyBvZiBt aW51dGVzIHBlciB3ZWVrIGFuZCB0aGUgSW50ZXJuZXQgaGFzIG5vdCBtZWx0ZWQgeWV0LiBJZiB3 ZSBuZWVkIHRvIGRvIGZsb3cgaWRlbnRpZmljYXRpb24gdG8gYWxsb3cgdHJhZmZpYyB0byBiZSBw cmlvcml0aXplZCwgZmluZQ0KIChzZWUgYWJvdmUgcmVnYXJkaW5nIG15IHByZWZlcnJlZCBhcHBy b2FjaCksIGJ1dCBmb3JjaW5nIGFsbCBXZWJSVEMgdHJhZmZpYyB0aHJvdWdoIGEgTUlUTSAoVFVS TiBzZXJ2ZXIpIGlzIGEgbXVjaCBiaWdnZXIganVtcCB0aGF0IEkgZG9uJ3QgeWV0IHNlZSB0aGUg anVzdGlmaWNhdGlvbiBmb3IuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JbiBzaG9ydDogVFVSTiBpcyBhIHRlY2hub2xvZ3kgdGhhdCBp cyBzdXBwb3NlZCB0byBmYWRlIGF3YXkgd2l0aCB0aGUgbW92ZSB0byBJUHY2LiBJIGRvbid0IHRo aW5rIHdlIHdhbnQgdG8gbWFrZSBpdCBhIGNyaXRpY2FsIGVsZW1lbnQgb2YgV2ViUlRDLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj4vS2FybDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyw6VuOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBEYW4gV2luZyBbbWFpbHRvOjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHdpbmdA Y2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmR3 aW5nQGNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl0NCjxi cj4NCjxiPlNraWNrYXQ6PC9iPiBkZW4gMTEgZmVicnVhcmkgMjAxNCAxODoyNTxicj4NCjxiPlRp bGw6PC9iPiA8L3NwYW4+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NYXJj IEJsYW5jaGV0PGJyPg0KPGI+S29waWE6PC9iPiBKdXN0aW4gVWJlcnRpOyA8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dGlyZWRkeUBpY2lzY28uY29tPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsNCiBLYXJsIFN0YWhsOyA8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBTaW1vbiBQZXJyZWF1bHQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iU1YiPjxicj4NCjxiPsOEbW5lOjwvYj4gUmU6IFt0cmFtXSBNaWxlc3RvbmUg MzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFu ZCBJU1BzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1Yi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+T24gRmViIDExLCAyMDE0LCBh dCA5OjA4IEFNLCBNYXJjIEJsYW5jaGV0ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1hcmMu YmxhbmNoZXRAdmlhZ2VuaWUuY2EiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViI+bWFy Yy5ibGFuY2hldEB2aWFnZW5pZS5jYTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiPiZndDsNCiB3 cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5MZSAyMDE0LTAyLTExIMOgIDAwOjM5LCBE YW4gV2luZyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkd2luZ0BjaXNjby5jb20iIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViI+ZHdpbmdAY2lzY28uY29tPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJTViI+Jmd0OyBhIMOpY3JpdCA6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KT24gRmViIDEwLCAyMDE0LCBhdCA1OjMw IFBNLCBKdXN0aW4gVWJlcnRpICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAZ29v Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5qdWJlcnRpQGdvb2dsZS5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7DQogd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+R29vZCB0byBzZWUgdGhlcmUgaXMgYSBsb3Qgb2Yg aW50ZXJlc3QgZm9yIHRoaXMgbWlsZXN0b25lLiBCdXQgYmFzZWQgb24gdGhlIGRlc2NyaXB0aW9u IGhlcmUsIGl0IHNlZW1zDQogbGlrZSB3ZSB3YW50IHRvIHVzZSBUVVJOIHByaW1hcmlseSB0byBp ZGVudGlmeSBXZWJSVEMgZmxvd3MsIGFzIG9wcG9zZWQgdG8gdXNpbmcgaXQgYXMgYSBOQVQgdHJh dmVyc2FsIHRvb2wuIFRoaXMgbWFrZXMgbWUgY29uY2VybmVkIHRoYXQgd2UgbWF5IGJlIHVzaW5n IHRoZSB3cm9uZyB0ZWNobm9sb2d5IHRvIHNvbHZlIHRoZSBwcm9ibGVtLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1Yi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiYjNDM7MS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5JIHdvdWxkIHByZWZlciBhbGxvd2luZyBmbG93cyB0byBlc3RhYmxpc2gg dGhlbXNlbHZlcyB1c2luZyB0aGVpciAnYmVzdCcgcGF0aCwgYW5kIHRoZSBiZXN0IHBhdGggaXMN CiBzZWxkb20gdGhyb3VnaCBhIFRVUk4gc2VydmVyLiAmbmJzcDtXaGVuIHdlIGltYWdpbmUgSVB2 NiBpbiBvdXIgZnV0dXJlLCB3ZSBkb24ndCB3YW50IHRvIGZvcmNlIGFuIGFwcGxpY2F0aW9uLWxl dmVsIHByb3h5IChUVVJOKSBzZXJ2ZXIgb24gdGhlIHBhdGggc29sZWx5IGZvciB0cmF2ZXJzaW5n IGFuIElQdjYgZmlyZXdhbGwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SXQgc2Vl bXMgdGhpcyB0aHJlYWQgaXMgY29uZmxhdGluZyBhbGwgdGhlIHBvc3NpYmxlIHJlYXNvbnMgLyBq dXN0aWZpY2F0aW9ucyBmb3IgVFVSTjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDsgKiBtb2JpbGl0eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAqIE5BVCB0cmF2ZXJzYWwgKGJvdGggZW5kcG9pbnRzIGFy ZSBiZWhpbmQgZW5kcG9pbnQtZGVwZW5kZW50IG1hcHBpbmcgTkFUcyk8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgKiZuYnNwO2ZpcmV3YWxsIHRyYXZl cnNhbCAoZmlyZXdhbGwgYmxvY2tzIFVEUCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDsgKiBlbmhhbmNpbmcgcHJpdmFjeTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlVuZm9ydHVuYXRlbHkgdGhlIFRVUk4gc2VydmVyIG5vciB0 aGUgZW5kcG9pbnQgcmVhbGx5IGtub3cgd2hpY2ggb2YgdGhvc2UgdXNlLWNhc2VzIGlzIGRlc2ly ZWQgKGJ5IHRoZQ0KIHVzZXIgb3IgYnkgdGhlIElUIG5ldHdvcmsgYWRtaW5pc3RyYXRvcikgb3Ig bmVjZXNzYXJ5IChmb3IgdGhlIGNhbGwgdG8gd29yayBhdCBhbGwpLg0KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5EYW4sIHdoaWxlIEkgYWdy ZWUgaW4gcHJpbmNpcGxlLCBJIGRvdWJ0IHRoYXQgYSB1c2VyIGNvdWxkIGV2ZXIgc2F5ICZxdW90 O0kgd2FudCBtb2JpbGl0eSBvciBJIHdhbnQgTkFUIHRyYXZlcnNhbCZxdW90Oy4gSSB0aGluayB0 aGUgdXNlciBvbmx5IHdhbnQgdGhlIGNhbGwgdG8gc3VjY2VlZCwgd2hhdGV2ZXINCiB0aGUgcHJv cGVydGllcyBvZiBpdHMgbmV0d29yayBwb2ludCBvZiBhdHRhY2htZW50IGFyZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+U28g d2hhdCBjYW4gd2UgZG8/ICZuYnNwO1Nob3VsZCB0aGUgVFVSTiBzZXJ2ZXIgcHJvdmlkZSBhbnkg YW5kIGFsbCBzZXJ2aWNlcyB0aGUgVFVSTiBjbGllbnQgbWlnaHQgcG9zc2libHkgd2FudCwgYXMg dGhhdCBpcyB3aGF0IGEgcm9idXN0IFRVUk4gc2VydmVyIHdpbGwgZG8sIGFuZCB0aGUNCiBlbmRw b2ludCBzaG91bGQgcHJlZmVyIFRVUk4gY2FuZGlkYXRlcyBvdmVyIGFsbCBvdGhlcnMgYmVjYXVz ZSB0aGVyZSBtaWdodCBiZSBzb21lIGZ1bmN0aW9uYWxpdHkgLyB1c2VmdWxuZXNzIG9mIFRVUk4g dGhhdCB0aGUgdXNlciBtaWdodCBnYWluIHRocm91Z2ggVFVSTiAoZS5nLiwgZW5oYW5jZWQgcHJp dmFjeSk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+LWQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwO1RoaXMgc2VlbXMgcHJvYmxlbWF0aWMuICZuYnNwO1BlcmhhcHMg d2UgbmVlZCBhIHdheSB0byBzaWduYWwgdGhlIGRlc2lyZWQgdXNlLWNhc2UgKCZxdW90O3RyYWl0 JnF1b3Q7KSwgb3IgYXMgSnVzdGluDQogc3VnZ2VzdHMsIHVzaW5nIGEgZGlmZmVyZW50IHRlY2hu b2xvZ3kgZm9yIHNvbWUgb2YgdGhlc2UgdXNlLWNhc2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPi1kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9uIE1vbiwgRmViIDEwLCAyMDE0 IGF0IDM6MTggUE0sIEthcmwgU3RhaGwmbmJzcDsmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpr YXJsLnN0YWhsQGludGVydGV4LnNlIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPmthcmwuc3RhaGxAaW50ZXJ0ZXguc2U8L3NwYW4+PC9hPjxz cGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7Jm5ic3A7d3JvdGU6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U2ltb24sPGJyPg0KPGJyPg0KR29vZCBxdWVzdGlv bnMgLSBzZWUgaW5saW5lIGJlbG93IC0tJmd0OyAuPGJyPg0KU29tZSBtb3JlIHRob3VnaHQgaXMg cmVxdWlyZWQhPGJyPg0KPGJyPg0KL0thcmw8YnI+DQo8YnI+DQotLS0tLVVyc3BydW5nbGlndCBt ZWRkZWxhbmRlLS0tLS08YnI+DQpGcsOlbjogdHJhbSBbbWFpbHRvOjwvc3Bhbj48YSBocmVmPSJt YWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW0tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl0NCiBGw7ZyIFNpbW9u IFBlcnJlYXVsdDxicj4NClNraWNrYXQ6IGRlbiAxMCBmZWJydWFyaSAyMDE0IDE1OjE2PGJyPg0K VGlsbDogS2FybCBTdGFobDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjsmbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij50aXJlZGR5QGljaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48YnI+DQrDhG1uZTogUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBz ZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkthcmwsPGJyPg0KPGJyPg0KSXQgaXMg Z3JlYXQgdG8gc2VlIHN1Y2ggZW50aHVzaWFzbSEgVGhhbmtzITxicj4NCjxicj4NCkkgaGF2ZSBh IGNvdXBsZSB0ZWNobmljYWwgcXVlc3Rpb25zLi4uPGJyPg0KPGJyPg0KTGUgMjAxNC0wMi0wOCAw ODoxMSwgS2FybCBTdGFobCBhIMOpY3JpdCA6PGJyPg0KJmd0OyAtIE5vdGUgdGhhdCB0byBhY2hp ZXZlIHNvbWUgb2YgdGhlIGFib3ZlIHBvaW50cywgVFVSTiBtdXN0IGJlIGZhdm9yZWQ8YnI+DQom Z3Q7IG92ZXIgU1RVTiB0byBlbmZvcmNlIHRoYXQgdGhlIFRVUk4tcGF0aCBhY3R1YWxseSBpcyB1 c2VkLiAoVGhlIEFueWNhc3Q8YnI+DQomZ3Q7IG1ldGhvZCBzdWdnZXN0ZWQgYmVsb3csIOKAnGF1 dG9tYXRpY2FsbHnigJ0gZG9lcyB0aGlzLik8YnI+DQo8YnI+DQpJIHVuZGVyc3RhbmQgdGhlIFNU VU4gdnMgVFVSTiBwcmlvcml0eSBpc3N1ZS4gQnV0IEkgZG9uJ3Qgc2VlIGhvdyBhbnljYXN0IGFm ZmVjdHMgaXQgaW4gYW55IHdheS4gQ2FuIHlvdSBwbGVhc2UgZXhwbGFpbj88L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1Yi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tLSBHb29kIHBvaW50IC0gSSB3YXMgYSBiaXQgcXVp Y2sgaGVyZSAobWF5YmUgdG9vIHF1aWNrKTxicj4NCldlIGhhdmUgZ2l2ZW4gdGhpcyBxdWl0ZSBi aXQgb2YgdGhvdWdodCwgc2luY2UgZXZlbiBpZiBhIFRVUk4gc2VydmVyIGlzIHByb3ZpZGVkIGFu ZCBkaXNjb3ZlcmVkLCBDVVJSRU5UIHVzYWdlIG9mIElDRSBtYXkgc3VnZ2VzdCBhIGNhbmRpZGF0 ZSBmcm9tIHRoZSByZW1vdGUgcGFydHkgdGhhdCB3aWxsIG1ha2UgYSBjb25uZWN0aW9uIHdpdGhv dXQgdGhlIG5lZWQvdXNhZ2Ugb2YgdGhlIFRVUk4gc2VydmVyICh0aGF0IHdlIHdhbnRlZCB0byBi ZSB1c2VkDQogZm9yIHRoZSBnb29kIHB1cnBvc2VzIGxpc3RlZCkuPGJyPg0KPGJyPg0KVGhlIG9u bHkgd2F5IHdlIGZvdW5kIGFyb3VuZCB0aGlzLCB3YXMgdG8gc3RvcCBTVFVOIHRocm91Z2ggdGhl IElQIGRlZmF1bHQgZ2F0ZXdheSAobGlrZSBhIHJlc3RyaWN0aXZlIEVudGVycHJpc2UgZmlyZXdh bGwgZG9lcyBpbmhpYml0aW5nIElDRSBjb25uZWN0aXZpdHksIHdoaWNoIG90aGVycyBhcmUgY29u Y2VybmVkIGFib3V0Li4uKS4gU2luY2UgdGhlIHByb3Zpc2lvbmluZyBvZiBhdXRvLWRpc2NvdmVy eSB1c2luZyB0aGUgYW55Y2FzdCBtZWNoYW5pc20sDQogd291bGQgYmUgYWRkaW5nIGEgcm91dGUg aW4gYSBkZWZhdWx0IGdhdGV3YXksIGFkZGluZyBhIGZpcmV3YWxsIHJ1bGUgdG8gZWF0IFNUVU4g cGFja2V0cyB3b3VsZCBhc3N1cmUgdGhhdCB0aGUgcHJvdmlzaW9uZWQgVFVSTiBzZXJ2ZXIgYWN0 dWFsbHkgYmVjb21lcyB1c2VkIChhbmQgbm90IGJ5cGFzc2VkICZxdW90O2J5IGFjY2lkZW50JnF1 b3Q7KS4gKFRoYXQgd2FzIHRoZSB0aG91Z2h0IGJlaGluZCB0aGUg4oCcYXV0b21hdGljYWxseeKA nSB3aXRoaW4gcXVvdGVzLik8YnI+DQo8YnI+DQpCVVQsIHNpbmNlIHlvdSBicm91Z2h0IHVwIHRo ZSBxdWVzdGlvbiwgYXNzdW1pbmcgdGhhdCB3ZSBoYXZlIHRoZSBwb3dlciB0byBlbmZvcmNlIFdl YlJUQyB1c2FnZSBvZiBJQ0UsIEkgYmVsaWV2ZSBhIE1VU1QgcmVxdWlyZW1lbnQgdG8gdXNlIGFu IGF1dG8tZGlzY292ZXJlZCBUVVJOIHNlcnZlciBpbnN0ZWFkIG9mIFNUVU4sIHdvdWxkIHNvbHZl IHRoZSBzYW1lIHByb2JsZW0uIEhvd2V2ZXIsIHRoaW5raW5nIGZ1cnRoZXIgKGluIHJlbGF0aW9u DQogdG8geW91ciBuZXh0IHF1ZXN0aW9uIC0gJnF1b3Q7YW55b25lIGNvdWxkIHNldCB1cCBhIGJh ZGx5LW1haW50YWluZWQmcXVvdDsgLSBlbmZvcmNpbmcgc3VjaCBJQ0UgdXNhZ2UgbWF5IG5vdCBi ZSBnb29kLik8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KJmd0OyAt IDNecmQgVGhlIEFueWNhc3QgbWV0aG9kIGJlbG93IOKAkyBJIHNlZSBubyBwcm9ibGVtPGJyPg0K Jmd0Ozxicj4NCiZndDsgSXQgYWxzbyBoYXMgdGhlIGFkdmFudGFnZSBvZiBlbmNvdXJhZ2luZyAo YnV0IG5vdCByZXF1aXJpbmcpIHRoZTxicj4NCiZndDsgU1RVTi9UVVJOIHRvIGJlIGJ1aWx0IGlu IHRoZSBkZWZhdWx0IGdhdGV3YXkgb3IgTkFUL2ZpcmV3YWxsL2FjY2Vzczxicj4NCiZndDsgcm91 dGVyIGl0c2VsZiwgd2l0aCBhIHNlY29uZCBpbnRlcmZhY2UgdG8gYSBwdWJsaWMgSVAgYWRkcmVz cyBvbiB0aGU8YnI+DQomZ3Q7IFdBTiBzaWRlLiAoQ3VycmVudCB2b2x1bWUgZGVwbG95ZWQsIGxv dyBjb3N0IE5TUCB0cmlwbGUgcGxheSBtb2RlbXM8YnI+DQomZ3Q7IHVzdWFsbHkgaGF2ZSBhIHF1 YWxpdHkgYXNzdXJlZCBsZXZlbCAyIG9yIGxldmVsIDMgV0FOIHBpcGUgZm9yIGp1c3Q8YnI+DQom Z3Q7IHZvaWNlIChhbmQgYW5vdGhlciBmb3IgSVBUVikg4oCTIFRoZSBhbnljYXN0IGRpc2NvdmVy ZWQgVFVSTi1zZXJ2ZXIgY2FuPGJyPg0KJmd0OyBiZSB0aGUgYWNjZXNzIGdhdGV3YXkgdG8gc3Vj aCBxdWFsaXR5IHBpcGUgZm9yIFdlYlJUQyBtZWRpYSwgaW4gYTxicj4NCiZndDsgc2luZ2xlIE5T UCBwcm92aWRlZCBDUEUsIHNjYWxpbmcgZnJvbSByZXNpZGVudGlhbCBhbmQgdXAuKTxicj4NCjxi cj4NClN1cHBvc2Ugd2UgZGVmaW5lIHdlbGwta25vd24gYW55Y2FzdCBUVVJOIHNlcnZlciBhZGRy ZXNzZXMuIEhvdyB3b3VsZCB0aGlzIG5vdCBiZSBzdWJqZWN0IHRvIHRoZSBzYW1lIHNlcnZpY2Ug cXVhbGl0eSBpc3N1ZXMgdGhhdCBwbGFndWVkIDZ0bzQ/IFRoYXQgaXMsIGFueW9uZSBjb3VsZCBz ZXQgdXAgYSBiYWRseS1tYWludGFpbmVkLCB1bmRlci1wcm92aXNpb25lZCBUVVJOIHNlcnZlciBh bmQgYW5ub3VuY2UgaXQgb3ZlciBCR1AgdG8gdGhlIHdvcmxkLA0KIGFzIGl0IHdhcyBkb25lIGZv cjxicj4NCjZ0bzQgcmVsYXlzLiBPciBqdXN0IGJhZCBCR1Agb3V0Ym91bmQgZmlsdGVyIGNvbmZp Z3VyYXRpb24uIEFuZCBob3cgY2FuIHdlIHByZXZlbnQgdHJpYW5nbGUgcm91dGluZz8gVGhlcmUg aXMgbm90aGluZyBndWFyYW50ZWVpbmcgdGhhdCB0aGUgYW55Y2FzdCBzZXJ2ZXIgeW91IHNlZSBp cyBiZWluZyBwcm92aWRlZCB0byB5b3UgYnkgeW91ciBJU1AsIHJhdGhlciB0aGFuIGEgc2VydmVy IHNpdHRpbmcgb24gdGhlIG90aGVyIHNpZGUgb2YgdGhlIHBsYW5ldC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tLSBHb29kIHBvaW50IC0gbmVlZHMgdG8gYmUgcmVzb2x2 ZWQuIEZvciB0aGlzIEkgZG9uJ3QgaGF2ZSBhIHJlYWR5IGFuc3dlci4uLjxicj4NCkFuIGF1dG8t ZGlzY292ZXJlZCBUVVJOIHNlcnZlciBtdXN0IGJlIHRydXN0ZWQgKHdoYXRldmVyIG1ldGhvZCBp dCBpcyBkaXNjb3ZlcmVkIGJ5KS4gV2UgYXJlIHRydXN0aW5nIHRoZSBvbmUgcHJvdmlkaW5nIHVz IHdpdGggYW4gSVAgYWRkcmVzcyBhbmQgZGVmYXVsdCBnYXRld2F5IGFueXdheS4gSXQgd291bGQg YmUgZWFzeSBpZiB3ZSBjb3VsZCByZXVzZSB0aGF0IHRydXN0LCBpbnN0ZWFkIG9mIGFub3RoZXIg bWVjaGFuaXNtcy48YnI+DQo8YnI+DQpJcyB0aGVyZSBhIGdvb2Qgd2F5IGZvciB0aGUgYnJvd3Nl ciB0byBjaGVjayB0aGF0IHRoZSBhbnljYXN0IGFkZHJlc3MgaXMgbm90IGhhbmRsZWQgYmV5b25k IHRoZSBuZXR3b3JrIHNlcnZpY2UgcHJvdmlkZXIncyBkZWZhdWx0IGdhdGV3YXk/IElkZWFzPzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KPGJy Pg0KVGhhbmtzLDxicj4NClNpbW9uPGJyPg0KLS08YnI+DQpEVE4gbWFkZSBlYXN5LCBsZWFuLCBh bmQgc21hcnQgLS0mZ3Q7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9wb3N0ZWxsYXRpb24u dmlhZ2VuaWUuY2EvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPmh0dHA6Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUuY2E8L3NwYW4+PC9hPjxz cGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpOQVQ2NC9ETlM2NCBv cGVuLXNvdXJjZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstLSZndDsmbmJzcDs8L3NwYW4+ PGEgaHJlZj0iaHR0cDovL2VjZHlzaXMudmlhZ2VuaWUuY2EvIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHA6Ly9lY2R5c2lzLnZpYWdl bmllLmNhPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGJyPg0KU1RVTi9UVVJOIHNlcnZlciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgLS0mZ3Q7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9udW1iLnZp YWdlbmllLmNhLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5odHRwOi8vbnVtYi52aWFnZW5pZS5jYTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+ PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4N Cjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L3NwYW4+PC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1Yi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxh bmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5n PSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90cmFtPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJh bSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnRyYW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_9F33F40F6F2CD847824537F3C4E37DDF17CF5660MCHP04MSXglobal_-- From nobody Fri Feb 14 18:41:51 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F4B1A002B for ; Fri, 14 Feb 2014 18:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 uU02OPzj1Fl2 for ; Fri, 14 Feb 2014 18:41:47 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4791A0026 for ; Fri, 14 Feb 2014 18:41:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2616; q=dns/txt; s=iport; t=1392432106; x=1393641706; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=RkRMCmg9nn/XQxBp0bfzCpztGqOigqbAUPrxrqY9PW4=; b=d24OzQjhzGGN/VkA8O5iunZgZ9P5mQkYtBbTchiAhXdjDg/AChs6PA/D Ax4+/Zxp6YEGABFOSQxd6sVuOtaVA5rDTlU2/GmDwl7VHwn0V1KITs8f0 cI+Fhm3Hy95WHaWRto/5kLZc8ZYu0CQ7CH8MNHCLcIgM51vuHeXuWIk/G 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAEXT/lKtJXG//2dsb2JhbABZgwY4V4MCvDEYfxZ0giUBAQEEIxFDDgYBCBEEAQEDAgYdAwIEMBQBBgEBBQQBBBMIAYd8DZgIjxWhSBeBKY0hPoJpNYEUBJlekHGDLYFqJBw X-IronPort-AV: E=Sophos;i="4.95,849,1384300800"; d="scan'208";a="20650840" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-8.cisco.com with ESMTP; 15 Feb 2014 02:41:45 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1F2fjrb005816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 15 Feb 2014 02:41:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.86]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 20:41:45 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt Thread-Index: Ac8p93TnRnLO4JxhQX6++HalJQhbyg== Date: Sat, 15 Feb 2014 02:41:44 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242AE8E9@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.48.63] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/f_XP3G3TDi6E_dmIeT2b4q0Oly8 Subject: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 02:41:50 -0000 VGhpcyBkb2N1bWVudCBwcm9wb3NlcyB0aGUgdXNlIG9mIHRoaXJkIHBhcnR5IGF1dGhvcml6YXRp b24gdXNpbmcgT0F1dGggZm9yIFRVUk4uIENvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgd2Vs Y29tZS4NCg0KLVRpcnUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDE0LCAyMDE0IDE6NTkgUE0NClRvOiBSYW0gTW9oYW4gUiAo cm1vaGFucik7IFByYXNoYW50aCBQYXRpbCAocHJhc3BhdGkpOyBUaXJ1bWFsZXN3YXIgUmVkZHkg KHRpcmVkZHkpOyBQcmFzaGFudGggUGF0aWwgKHByYXNwYXRpKTsgSnVzdGluIFViZXJ0aTsgSnVz dGluIFViZXJ0aTsgVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgUmFtIE1vaGFuIFIgKHJt b2hhbnIpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXJlZGR5 LXRyYW0tdHVybi10aGlyZC1wYXJ0eS1hdXRoei0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9m IEktRCwgZHJhZnQtcmVkZHktdHJhbS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAwLnR4dA0KaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBUaXJ1bWFsZXN3YXIgUmVkZHkgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtcmVkZHktdHJhbS10 dXJuLXRoaXJkLXBhcnR5LWF1dGh6DQpSZXZpc2lvbjoJMDANClRpdGxlOgkJVFVSTiBFeHRlbnNp b24gZm9yIFRoaXJkIFBhcnR5IEF1dGhvcml6YXRpb24NCkRvY3VtZW50IGRhdGU6CTIwMTQtMDIt MTQNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTExDQpVUkw6ICAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcmVkZHktdHJh bS10dXJuLXRoaXJkLXBhcnR5LWF1dGh6LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlZGR5LXRyYW0tdHVybi10aGlyZC1wYXJ0 eS1hdXRoei8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1yZWRkeS10cmFtLXR1cm4tdGhpcmQtcGFydHktYXV0aHotMDANCg0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgdGhlIHVzZSBvZiBPQXV0aCB0byBvYnRhaW4gYW5kIHZh bGlkYXRlDQogICBlcGhlbWVyYWwgdG9rZW5zIHRoYXQgY2FuIGJlIHVzZWQgZm9yIFRVUk4gYXV0 aGVudGljYXRpb24uICBUaGUgdXNhZ2UNCiAgIG9mIGVwaGVtZXJhbCB0b2tlbnMgZW5zdXJlIHRo YXQgYWNjZXNzIHRvIGEgVFVSTiBzZXJ2ZXIgY2FuIGJlDQogICBjb250cm9sbGVkIGV2ZW4gaWYg dGhlIHRva2VucyBhcmUgY29tcHJvbWlzZWQsIGFzIGlzIHRoZSBjYXNlIGluDQogICBXZWJSVEMg d2hlcmUgVFVSTiBjcmVkZW50aWFscyBtdXN0IGJlIHNwZWNpZmllZCBpbiBKYXZhc2NyaXB0LiAg SXQNCiAgIGFsc28gYWRkcmVzc2VzIHRoZSBuZWVkIGZvciBzdHJvbmdlciBhdXRoZW50aWNhdGlv biBkZXNjcmliZWQgaW4NCiAgIFtJLUQucmVkZHktYmVoYXZlLXR1cm4tYXV0aF0uDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Sat Feb 15 21:00:50 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7101A0369 for ; Sat, 15 Feb 2014 21:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 wFgsZ8Vz6Zqz for ; Sat, 15 Feb 2014 21:00:46 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 97D001A0364 for ; Sat, 15 Feb 2014 21:00:46 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so13539707pde.34 for ; Sat, 15 Feb 2014 21:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wdjrISW0lDWZ6TkhhC+vM74gO+K2AyC8JerUpqw8ioU=; b=NQC4eJXCsZmZFP4qXFg+YcKW3pkpqbnVmsas4xgq8+0kcB9QvFBetvapRXODeU9QeC 1a2civQPhjA9YZ7oeQVDjL5JV0EXpZNgI+kU5EwG8kTa+t1MSUmBuC8pIEgWA6DxTnO4 BmFzcxbdmCbLrH+sTye7Ta2CuEtNov6uRL8rCex62lCJH4DsSovpfvLbpdTd452mFhRO CjFqzprllOjnC6dOZ30CCFCvNOfhewse9gzU62Frm6Ui0WlgnQgRftAljjrHBenf0ios C9j/Sci/Wh7GcCNZuH785GucctuvLn7xwBWU65xy8qgNB1Vanridvp6rYNNFb/uwbvC6 dMhw== MIME-Version: 1.0 X-Received: by 10.68.227.4 with SMTP id rw4mr10664782pbc.3.1392526844591; Sat, 15 Feb 2014 21:00:44 -0800 (PST) Received: by 10.68.147.131 with HTTP; Sat, 15 Feb 2014 21:00:44 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A242AE8E9@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242AE8E9@xmb-rcd-x10.cisco.com> Date: Sat, 15 Feb 2014 21:00:44 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b2e0903e9826204f27eeb1c Archived-At: http://mailarchive.ietf.org/arch/msg/tram/0cfm0NwGip4PDXyrkrILHnfSCtc Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 05:00:49 -0000 --047d7b2e0903e9826204f27eeb1c Content-Type: text/plain; charset=ISO-8859-1 Hi Tiru I have some comments: 1) Section 4. Obtaining a Token Using OAuth, figure 4 I believe that the sequence of messages is incorrect. The TURN server most probably will contact the Authorization server AFTER it gets the Allocate request. But on the figure 4, it looks like it somehow can predict the incoming request. The correct sequence must be, in the general case: Access Token Request (1) from client to Auth server Access Token + Session Key (2) from Auth server to client Allocate request from client to TURN server (3) Get Token from TURN Server to Auth server (4) Token metadata from Auth Server to TURN server (5) Allocate response from TURN server to the client (6) The sequence shown on the figure 4 is possible only is the Auth Server and TURN server are somehow closely integrated and that is unnecessary. 2) The document is saying that the client when communicating to the Auth Server uses HTTP requests with JSON (REST API ?). May be it would be helpful if the communication protocol between TURN server and Auth server would be mentioned, too. 3) Section 7.2: OAuth does not impose any limitation on the length of the access token but since STUN messages cannot exceed 548 bytes (Section 7.1 of [RFC5389]), access token length needs to be restricted to fit within the maximum STUN message size. I am not sure that the STUN (Binding ?) max message size is relevant here and worth mentioning at all - because this doc is about TURN, and the TURN messages are often much larger than 548 bytes (especially when carrying the video traffic). So I see no relevance of the 548 limit to the new authentication standard. And that limitation of 548 bytes is applicable only to the cases when we suspect that the path MTU is really really low and that is an extremely rare case. 4) Are we sure that we want to limit the OAuth applicability only to the long-term credentials mechanism ? I see no technical or philosophical reasons why not to use it for short-term credentials mechanism, too. It would be a more "symmetric" approach. 5) I'd put more definite wording how TURN server handles the token lifetime. What happens in the middle of the TURN session, is the auth token expires while the session is still active ? There may be two possible cases: - the token lifetime is applicable only to the session initiation procedure. When the TURN session has been already established, it can go indefinitely while the client is refreshing the session properly. - in second case when the token expires, the server rejects new requests from the client (in the same TURN session) until the client sends the new token data in re-authentication exchange. I'd suggest the first case as an eisier case for the implementation. Regards, Oleg On Fri, Feb 14, 2014 at 6:41 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > This document proposes the use of third party authorization using OAuth > for TURN. Comments and suggestions are welcome. > > -Tiru > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, February 14, 2014 1:59 PM > To: Ram Mohan R (rmohanr); Prashanth Patil (praspati); Tirumaleswar Reddy > (tireddy); Prashanth Patil (praspati); Justin Uberti; Justin Uberti; > Tirumaleswar Reddy (tireddy); Ram Mohan R (rmohanr) > Subject: New Version Notification for > draft-reddy-tram-turn-third-party-authz-00.txt > > > A new version of I-D, draft-reddy-tram-turn-third-party-authz-00.txt > has been successfully submitted by Tirumaleswar Reddy and posted to the > IETF repository. > > Name: draft-reddy-tram-turn-third-party-authz > Revision: 00 > Title: TURN Extension for Third Party Authorization > Document date: 2014-02-14 > Group: Individual Submission > Pages: 11 > URL: > http://www.ietf.org/internet-drafts/draft-reddy-tram-turn-third-party-authz-00.txt > Status: > https://datatracker.ietf.org/doc/draft-reddy-tram-turn-third-party-authz/ > Htmlized: > http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz-00 > > > Abstract: > This document proposes the use of OAuth to obtain and validate > ephemeral tokens that can be used for TURN authentication. The usage > of ephemeral tokens ensure that access to a TURN server can be > controlled even if the tokens are compromised, as is the case in > WebRTC where TURN credentials must be specified in Javascript. It > also addresses the need for stronger authentication described in > [I-D.reddy-behave-turn-auth]. > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b2e0903e9826204f27eeb1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tiru

I have some comments:
1) Section 4. Obtaining a Token Using OAuth, figure 4

=
I believe that the sequence of messages is incorrect. The TURN s= erver most probably will contact the Authorization server AFTER it gets the= Allocate request. But on the figure 4, it looks like it somehow can predic= t the incoming request. The correct sequence must be, in the general case:<= br>
=A0=A0 Access Token Request (1) from client to Auth server
=A0=A0 Access Token + Session Key (2) from Auth server to clie= nt
=A0=A0 Allocate request from client to TURN server (3)
=
=A0=A0 Get Token from TURN Server to Auth server (4)
=A0=A0 T= oken metadata from Auth Server to TURN server (5)
=A0=A0 Allo= cate response from TURN server to the client (6)

The sequ= ence shown on the figure 4 is possible only is the Auth Server and TURN ser= ver are somehow closely integrated and that is unnecessary.

2) The document is saying that the client when co= mmunicating to the Auth Server uses HTTP requests with JSON (REST API ?). M= ay be it would be helpful if the communication protocol between TURN server= and Auth server would be mentioned, too.

3) Section 7.2:

OAuth does not impose any limita=
tion on the length of the access token but since
   STUN messages cannot exceed 548 bytes (Section 7.1 of [RFC5389]),
   access token length needs to be restricted to fit within the maximum
   STUN message size.
I am not sure that the STUN (Binding ?) max mess= age size is relevant here and worth mentioning at all - because this doc is= about TURN, and the TURN messages are often much larger than 548 bytes (es= pecially when carrying the video traffic). So I see no relevance of the 548= limit to the new authentication standard. And that limitation of 548 bytes= is applicable only to the cases when we suspect that the path MTU is reall= y really low and that is an extremely rare case.

4) Are we sure that we want to limit the OAuth ap= plicability only to the long-term credentials mechanism ? I see no technica= l or philosophical reasons why not to use it for short-term credentials mec= hanism, too. It would be a more "symmetric" approach.

5) I'd put more definite wording how TURN server handles= the token lifetime. What happens in the middle of the TURN session, is the= auth token expires while the session is still active ? There may be two po= ssible cases:

=A0=A0 - the token lifetime is applicable only to the sessio= n initiation procedure. When the TURN session has been already established,= it can go indefinitely while the client is refreshing the session properly= .

=A0=A0 - in second case when the token expires, the server r= ejects new requests from the client (in the same TURN session) until the cl= ient sends the new token data in re-authentication exchange.

<= div> I'd suggest the first case as an eisier case for the implementation.

Regards,
Oleg






On Fri, Feb 14, 2014 at 6:41 PM, Tirumaleswar Reddy (tireddy) <tireddy@cis= co.com> wrote:
This document proposes the use of third party authorization using OAuth for= TURN. Comments and suggestions are welcome.

-Tiru

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Friday, February 14, 2014 1:59 PM
To: Ram Mohan R (rmohanr); Prashanth Patil (praspati); Tirumaleswar Reddy (= tireddy); Prashanth Patil (praspati); Justin Uberti; Justin Uberti; Tirumal= eswar Reddy (tireddy); Ram Mohan R (rmohanr)
Subject: New Version Notification for draft-reddy-tram-turn-third-party-aut= hz-00.txt


A new version of I-D, draft-reddy-tram-turn-third-party-authz-00.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-reddy-tram-turn-third-party-authz
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0TURN Extension for Third Party Authorization
Document date: =A02014-02-14
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A011
URL: =A0 =A0 =A0 =A0 =A0 =A0http://ww= w.ietf.org/internet-drafts/draft-reddy-tram-turn-third-party-authz-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ie= tf.org/doc/draft-reddy-tram-turn-third-party-authz/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/d= raft-reddy-tram-turn-third-party-authz-00


Abstract:
=A0 =A0This document proposes the use of OAuth to obtain and validate
=A0 =A0ephemeral tokens that can be used for TURN authentication. =A0The us= age
=A0 =A0of ephemeral tokens ensure that access to a TURN server can be
=A0 =A0controlled even if the tokens are compromised, as is the case in
=A0 =A0WebRTC where TURN credentials must be specified in Javascript. =A0It=
=A0 =A0also addresses the need for stronger authentication described in
=A0 =A0[I-D.reddy-behave-turn-auth].




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

The IETF Secretariat

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b2e0903e9826204f27eeb1c-- From nobody Mon Feb 17 02:06:50 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56B31A0478 for ; Mon, 17 Feb 2014 02:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ilAj6DMYpmcp for ; Mon, 17 Feb 2014 02:06:40 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D4D0C1A0465 for ; Mon, 17 Feb 2014 02:06:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=119370; q=dns/txt; s=iport; t=1392631597; x=1393841197; h=from:to:cc:subject:date:message-id:mime-version; bh=l3928rZbhD1OGHLEUnU59nMSLR4ekrgVapo/2xGm0sE=; b=MTzGqAK5I2UCw2MUkDyhSlGChVT20xU7/gOUvnjy0h1d6EEtwcl5kO1/ QcNJNKB69k8zX/C2OdR0OYuDcGXr6GBt0MT0ulRti0qP8KyYxhFCKQM8o yl1w5QjoK6VOTgabYNtMo1ng0wvDv6kT4fFeHv5GJTdXyzs08FuRSHynL Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwIAMneAVOtJXHB/2dsb2JhbABPCoJCRDhXgwKnV4wGiFUYgQQWdIIlAQEBAwEBAQEXAQgEBjoFAgQEAwUNAQgRBAEBCxYBBgMCBB8GCxQJCQEEDgUIEwSHUgMJCA2pdpksDYgPF4xngS4QBAodFhcEBgqCZjWBFASWQIMeiyyFRYFvgT6BaAkXIg X-IronPort-AV: E=Sophos;i="4.95,859,1384300800"; d="scan'208,217";a="304554233" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 17 Feb 2014 10:06:34 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1HA6Y7t031732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 10:06:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 04:06:34 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "Hutton, Andrew" Thread-Topic: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: Ac8rx+yHWoLNZ7jURQG92FGr00LVkQ== Date: Mon, 17 Feb 2014 10:06:33 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242AF2D6@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.107] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242AF2D6xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/jjSnPhOgzb8dKXFnQIDX_jEbKc0 Cc: "tram@ietf.org" Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 10:06:46 -0000 --_000_913383AAA69FF945B8F946018B75898A242AF2D6xmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzIHRoZSBiZWxvdyBkcmFmdCBzb2x2ZXMgdGhlIGF1dGhlbnRpY2F0aW9uIHByb2JsZW0gaWYg RW50ZXJwcmlzZSBoYXMgbXVsdGlwbGUgZG9tYWlucy4NCg0KQnV0IGhvdyB3aWxsIHRoYXQgaGVs cCB0aGUgRW50ZXJwcmlzZSBJLlQgaWRlbnRpZnkgaWYgdGhlIHRyYWZmaWMgZ29pbmcgdGhyb3Vn aCB0aGUgVFVSTiBzZXJ2ZXIgYXJlIFdlYlJUQyBtZWRpYSBzdHJlYW1zIGFuZCBub3Qgc29tZSBv dGhlciB0cmFmZmljLiAgTWF5IGJlIHdlIG5lZWQgdG8gdGFrZSBhIHN0ZXAgYmFjayBhbmQgbG9v ayBpbnRvIHRoZSBGaXJld2FsbCByZXF1aXJlbWVudHMgZm9yIEVudGVycHJpc2UgZGVwbG95bWVu dCB3aGljaCBhcmUgdHlwaWNhbGx5IHZlcnkgcmVzdHJpY3RpdmUgYW5kIGhhdmUgYSBuZWVkIHRv IGNsYXNzaWZ5IHRoZSB0cmFmZmljIHRvIGVuZm9yY2UgdmFyaW91cyBGaXJld2FsbCBhY3Rpb25z IGxpa2UgcGVybWl0LCBibG9jaywgZXRjLiAgRW50ZXJwcmlzZSBGaXJld2FsbHMgYXJlIHR5cGlj YWxseSBjb25maWd1cmF0aW9uIHRvIGJsb2NrIFAyUCB1ZHAgdHJhZmZpYyBhbmQgcGVyZm9ybSBT SVAgQUxHIHRvIHBlcm1pdCBtZWRpYSBzdHJlYW1zLiBCdXQgdGhpcyB3b27igJl0IHdvcmsgd2l0 aCBXZWJSVEMgYW5kIHdlIHdhbnQgYSB3YXkgdG8gbW92ZSBhd2F5IGZyb20gQUxHLg0KDQoxLiBJ cyBkZXBsb3lpbmcgVFVSTiBzZXJ2ZXIgaW4gRW50ZXJwcmlzZSBhbmQgbWFraW5nIHN1cmUgdGhh dCBVRFAgdHJhZmZpYyBnb2VzIHRocm91Z2ggaXQgc3VmZmljaWVudCA/DQoNCjIuIFRoZSBtb3Jl IGNvbXBlbGxpbmcgdXNlIGNhc2VzIGZvciBFbnRlcnByaXNlcyB3b3VsZCBiZSB0byBpZGVudGlm eSBpZiB0aGUgbWVkaWEgc3RyZWFtcyBhcmUgYXNzb2NpYXRlZCB3aXRoIGJ1c2luZXNzIGNhbGwg b3IgbWVkaWEgc3RyZWFtcyBpbml0aWF0ZWQgYmVjYXVzZSBvZiB1c2luZyBhIHNvY2lhbCBuZXR3 b3JraW5nIHNpdGUsIG1lZGlhIHN0cmVhbXMgYmVjYXVzZSBvZiBnYW1pbmcgZXRjLiBzbyB0aGF0 IHRoZXNlIG5vbi1idXNpbmVzcyBjYWxsIHJlbGF0ZWQgdHJhZmZpYyBjYW4gYmUgcmF0ZS1saW1p dGVkIG9yIHRyZWF0ZWQgZGlmZmVyZW50bHkgc28gYXMgdG8gbm90IGltcGFjdCB0aGUgYnVzaW5l c3MgY2FsbHMgLg0KDQotVGlydS4NCkZyb206IEh1dHRvbiwgQW5kcmV3IFttYWlsdG86YW5kcmV3 Lmh1dHRvbkB1bmlmeS5jb21dDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDE0LCAyMDE0IDEyOjU2 IEFNDQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KQ0KQ2M6IHRyYW1AaWV0Zi5vcmc8 bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3RyYW1dIE1pbGVzdG9uZSAzOiBU VVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElT UHMNCg0KT25lIHN1Y2ggZW5oYW5jZW1lbnQgaXMgZGVzY3JpYmVkIGluIGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWpvaG5zdG9uLXRyYW0tc3R1bi1vcmlnaW4tMDEuDQoNCkFuZHkN Cg0KDQoNCkZyb206IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgW21haWx0bzp0aXJlZGR5 QGNpc2NvLmNvbV0NClNlbnQ6IDEzIEZlYnJ1YXJ5IDIwMTQgMTU6MzQNClRvOiBIdXR0b24sIEFu ZHJldw0KQ2M6IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBS RTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5p c20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KSGkgQW5keSwNCg0KWWVzLCBXZWJSVEMgYnJv d3NlciB3aWxsIGhhdmUgdG8gYSBzdXBwb3J0IGEgbnVtYmVyIG9mIG1lY2hhbmlzbXMuIFRoaXMg d2FzIGRpc2N1c3NlZCBpbiBSVENXRUIgbWFpbGluZyBsaXN0IHNvbWV0aW1lIGJhY2sgYW5kIHNl Y3Rpb24gMy4zLjQuMSBpbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0 Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xNCBoYXMgYmVlbiB1cGRhdGVkIHRvIHJl ZmxlY3QgdGhpcyBwb2ludC4NCkNhbiB5b3UgcGxlYXNlIGNsYXJpZnkgdGhlIGVuaGFuY2VtZW50 cyBUVVJOIHNlcnZlciB5b3UgYXJlIGxvb2tpbmcgZm9yIGFuZCB3aGF0IHByb2JsZW1zIGRvZXMg aXQgc29sdmUgPw0KDQotVGlydS4NCkZyb206IEh1dHRvbiwgQW5kcmV3IFttYWlsdG86YW5kcmV3 Lmh1dHRvbkB1bmlmeS5jb21dDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgNDox OCBQTQ0KVG86IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkNCkNjOiB0cmFtQGlldGYub3Jn PG1haWx0bzp0cmFtQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFt0cmFtXSBNaWxlc3RvbmUgMzog VFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJ U1BzDQoNClRoZSBwcmltZSB1c2UgY2FzZSBmb3IgdGhpcyBpcyBkb2N1bWVudGVkIGluIGh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVx dWlyZW1lbnRzLTEyI3NlY3Rpb24tMy4zLjUuMSBhbmQgSSB0aGluayB0aGF0IFRSQU0gd2lsbCBw cm9iYWJseSBtYWtlIGVuaGFuY2VtZW50cyB0byBUVVJOIGVuYWJsaW5nIHN1Y2ggYW4g4oCcZW50 ZXJwcmlzZSBhdWRpdGluZyBUVVJOIHNlcnZlcuKAnSB0byBkbyBhbiBlZmZlY3RpdmUgam9iIG9m IG1hbmFnaW5nIFdlYlJUQyB0cmFmZmljIGluIGFuIGVudGVycHJpc2UuDQoNClRoZXJlIGFyZSBv ZiBjb3Vyc2UgbW9yZSB0aGFuIG9uZSBwcm9ibGVtIGFuZCBtYW55IHBvc3NpYmx5IHdheXMgdG8g c29sdmUgdGhlbSBhbmQgSSByZWNlbnRseSB1cGRhdGVkIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWh1dHRvbi1ydGN3ZWItbmF0LWZpcmV3YWxsLWNvbnNpZGVyYXRpb25zLTAzIHRv IGxpc3QgdGhlc2UgZm9yIGRpc2N1c3Npb24gaW5jbHVkaW5nIFBDUC4NCg0KVW5mb3J0dW5hdGVs eSBzb2x1dGlvbnMgYXJlIG5lZWRlZCB0b2RheSB3aXRoaW4gZXhpc3RpbmcgbmV0d29ya3MgYW5k IFBDUCBkb2VzIG5vdCBzZWVtIHNvIHVzZWZ1bCBoZXJlIHNvIHdlIGhhdmUgdG8gbG9vayBhdCBt dWx0aXBsZSBzb2x1dGlvbnMgYW5kIHByb2JhYmx5IFdlYlJUQyBicm93c2VycyBoYXZlIHRvIHN1 cHBvcnQgYSBudW1iZXIgb2YgbWVjaGFuaXNtcy4NCg0KUmVnYXJkcw0KQW5keQ0KDQoNCg0KRnJv bTogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSBbbWFpbHRvOnRpcmVkZHlAY2lzY28uY29t XQ0KU2VudDogMTMgRmVicnVhcnkgMjAxNCAwMzozNw0KVG86IEh1dHRvbiwgQW5kcmV3OyBKdXN0 aW4gVWJlcnRpOyBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KQ2M6IHRpcmVk ZHlAaWNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tPjsgU2ltb24gUGVycmVhdWx0 OyBPbGVnIE1vc2thbGVua287IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+OyBN YXJjIEJsYW5jaGV0OyBEYW4gV2luZyAoZHdpbmcpOyBLYXJsIFN0YWhsDQpTdWJqZWN0OiBSRTog W3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20g Zm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KSGkgQW5keSwNCg0KVGhlcmUgYXJlIG90aGVyIHdh eXMgdG8gc29sdmUgdGhlIHByb2JsZW0gZm9yIGV4YW1wbGUgdXNpbmcgUENQLiBDYW4geW91IGNs YXJpZnkgaG93IGRlcGxveWluZyBhIFRVUk4gc2VydmVyIGluIHRoZSBFbnRlcnByaXNlIHByb3Rl Y3RzIHRoZSB1c2VycyBhbmQgdGhlIG5ldHdvcmsgPw0KDQotVGlydS4NCkZyb206IHRyYW0gW21h aWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIdXR0b24sIEFuZHJldw0K U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE0IDE6MDAgQU0NClRvOiBKdXN0aW4gVWJl cnRpOyBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKQ0KQ2M6IHRpcmVkZHlAaWNp c2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tPjsgU2ltb24gUGVycmVhdWx0OyBPbGVn IE1vc2thbGVua287IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+OyBNYXJjIEJs YW5jaGV0OyBEYW4gV2luZyAoZHdpbmcpOyBLYXJsIFN0YWhsDQpTdWJqZWN0OiBSZTogW3RyYW1d IE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVu dGVycHJpc2UgYW5kIElTUHMNCg0KVGhlIGNhc2Ugd2hlcmUgdGhlIFRVUk4gc2VydmVyIGlzIHRo ZSBvbmx5IG9wdGlvbiBtYXkgYmVjb21lIGNvbW1vbiB3aXRoaW4gZW50ZXJwcmlzZSBuZXR3b3Jr cyBhbmQgdGhhdCBtaWdodCBiZSBkZWxpYmVyYXRlIGVudGVycHJpc2UgcG9saWN5IGJlY2F1c2Ug aXQgcHJvdmlkZXMgdGhlIGJldHRlciBwYXRoIChVRFAgdGhyb3VnaCB0aGUgRi9XKSBhbmQgcHJv dGVjdHMgdGhlIHVzZXJzIGFuZCB0aGUgbmV0d29yay4NCg0KQW5keQ0KDQoNCkZyb206IHRyYW0g W21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRp DQpTZW50OiAxMiBGZWJydWFyeSAyMDE0IDE3OjQ2DQpUbzogTXV0aHUgQXJ1bCBNb3poaSBQZXJ1 bWFsIChtcGVydW1hbCkNCkNjOiB0aXJlZGR5QGljaXNjby5jb208bWFpbHRvOnRpcmVkZHlAaWNp c2NvLmNvbT47IFNpbW9uIFBlcnJlYXVsdDsgT2xlZyBNb3NrYWxlbmtvOyB0cmFtQGlldGYub3Jn PG1haWx0bzp0cmFtQGlldGYub3JnPjsgTWFyYyBCbGFuY2hldDsgRGFuIFdpbmcgKGR3aW5nKTsg S2FybCBTdGFobA0KU3ViamVjdDogUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIg YXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNCkFncmVl LiBJZiBUVVJOIGlzIGluZGVlZCBiZWluZyBwcm92aWRlZCBmb3IgdGhlIHVzZXIncyBiZW5lZml0 LCB0aGUgY2xpZW50J3MgSUNFIGxvZ2ljIChiYXNlZCBvbiBSVFQgb3Igc2ltaWxhcikgc2hvdWxk IHJlc3VsdCBpbiBpdCBwcmVmZXJyaW5nIHRoZSBUVVJOIHBhdGguDQoNCk9uIFdlZCwgRmViIDEy LCAyMDE0IGF0IDE6MjcgQU0sIE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpIDxt cGVydW1hbEBjaXNjby5jb208bWFpbHRvOm1wZXJ1bWFsQGNpc2NvLmNvbT4+IHdyb3RlOg0KWWVz LCBJIGJlbGlldmUgdGhlIHNlY29uZCBjYXNlIGlzIHJhcmUsIGJ1dCB3b3VsZCBiZSBiZXR0ZXIg dGhhbiBhIHJhdCByYWNlIGIvdyBhZG1pbmlzdHJhdG9ycyB0cnlpbmcgdG8gYmxvY2sgcDJwIHRy YWZmaWMgYW5kIGZvcmNlIGl0IHRocm91Z2ggYSBUVVJOIHNlcnZlciBhbmQgYXBwcy9lbmRwb2lu dHMgZmluZGluZyBzbWFydGVyIHdheXMgdG8gYnlwYXNzIHRoZW0uDQoNCk11dGh1DQoNCkZyb206 IE9sZWcgTW9za2FsZW5rbyBbbWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb208bWFpbHRvOm1vbTA0 MDI2N0BnbWFpbC5jb20+XQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAxNCAxOjA3 IFBNDQpUbzogTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkNCkNjOiBKdXN0aW4g VWJlcnRpOyBLYXJsIFN0YWhsOyB0aXJlZGR5QGljaXNjby5jb208bWFpbHRvOnRpcmVkZHlAaWNp c2NvLmNvbT47IE1hcmMgQmxhbmNoZXQ7IHRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5v cmc+OyBEYW4gV2luZyAoZHdpbmcpOyBTaW1vbiBQZXJyZWF1bHQNCg0KU3ViamVjdDogUmU6IFt0 cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZv ciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNClRoZSBUVVJOIHNlcnZlciBoYXMgdG8gYmUgdXNlZCB3 aGVuIGl0IGlzIGVpdGhlciB0aGUgb25seSBvcHRpb24sIG9yIGlmIGl0IHByb3ZpZGVzIGEgYmV0 dGVyIHBhdGggKEkgZ3Vlc3MgdGhlIHNlY29uZCBjYXNlIGlzIHJhdGhlciByYXJlKS4NCg0KT24g VHVlLCBGZWIgMTEsIDIwMTQgYXQgMTE6MzIgUE0sIE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAo bXBlcnVtYWwpIDxtcGVydW1hbEBjaXNjby5jb208bWFpbHRvOm1wZXJ1bWFsQGNpc2NvLmNvbT4+ IHdyb3RlOg0KKzENCg0KRm9yY2luZyBhbGwgdHJhZmZpYyB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIg YW5kIGV4cGVjdGluZyBpdCB3b3VsZCBwcm92aWRlIHRoZSBiZXN0IHVzZXIgZXhwZXJpZW5jZSBk b2Vzbid0IGxvb2sgdGhlIHJpZ2h0IGFwcHJvYWNoLiBJbnN0ZWFkLCBpZiBhIHBhdGggdGhyb3Vn aCBhIFRVUk4gc2VydmVyIGV4aXN0cyBhbmQgZG9lcyBwcm92aWRlIGxvd2VyIFJUVCwgaml0dGVy IGV0YywgYmVpbmcgYWJsZSB0byBkZXRlY3QgYW5kIHVzZSAob3Igc3dpdGNoIHRvKSB0aGF0IHBh dGggbWlnaHQgYmUgZGVzaXJhYmxlLi4NCg0KTXV0aHUNCg0KRnJvbTogdHJhbSBbbWFpbHRvOnRy YW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVo YWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQg MTE6NDMgQU0NClRvOiBLYXJsIFN0YWhsDQpDYzogdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0 aXJlZGR5QGljaXNjby5jb20+OyBNYXJjIEJsYW5jaGV0OyB0cmFtQGlldGYub3JnPG1haWx0bzp0 cmFtQGlldGYub3JnPjsgRGFuIFdpbmcgKGR3aW5nKTsgU2ltb24gUGVycmVhdWx0DQpTdWJqZWN0 OiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNo YW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KSW5saW5lLg0KDQpPbiBUdWUsIEZlYiAx MSwgMjAxNCBhdCAyOjM3IFBNLCBLYXJsIFN0YWhsIDxrYXJsLnN0YWhsQGludGVydGV4LnNlPG1h aWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlPj4gd3JvdGU6DQpMaXN0ZW5pbmcgdG8gdGhpcyB0 aHJlYWQsIEkgYW0gYWZyYWlkIHdlIGFyZSBtaXNzaW5nIHRoZSB2ZXJ5IHBvaW50IGFuZCBuZWNl c3NpdHkgZm9yIHRoaXMgbWlsZXN0b25lIQ0KLSBUaGVyZSBhcmUgc2V2ZXJlIE5BVCB0cmF2ZXJz YWwgYW5kIHF1YWxpdHkgaXNzdWVzIHRoYXQgc2hvdWxkIGFuZCBjYW4gYmUgZGVhbHQgd2l0aCBi eSBhIGdvb2QgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGFuZCB0aGUgcmlnaHQgdXNhZ2UgYnkg dGhlIHR1cm4gY2xpZW50ICh0aGUgV2ViUlRDIGJyb3dzZXIpDQoNClRoZXJlIGFyZSB3YXlzLCBu b3Qgb25seTogRW50ZXJwcmlzZXMgb3IgSVNQcyB3aXNoaW5nIHRvIHByb3ZpZGUgdGhlaXIgb3du IFRVUk4gc2VydmVyLCBpbiBhbiBhdHRlbXB0IHRvIHJlZHVjZSBzby1jYWxsZWQgInRyaWFuZ2xl IHJvdXRpbmciLG5lZWQgYSBuZXcgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtDQpCdXQgYWxzbzog LSBOU1BzIChOZXR3b3JrIFNlcnZpY2UgUHJvdmlkZXJzKSB3YW50IHRvIHByb3ZpZGUgYSBwYXRo IHdoZXJlIHRoZSBiYW5kd2lkdGggb2YgV2ViUlRDIGlzIGJldHRlciBjb3BlZCB3aXRoLg0KLSBO U1BzIG9yIEVudGVycHJpc2VzIHdhbnQgdG8gb2ZmZXIgYW4gSW50ZXJuZXQgYWNjZXNzIHF1YWxp dHkgcGlwZSBmb3IgcHJpb3JpdGl6ZWQgUlRDIChSZWFsIFRpbWUgQ29tbXVuaWNhdGlvbikgdHJh ZmZpYy4NCi0gRW50ZXJwcmlzZXMgaGF2aW5nIHJlc3RyaWN0aXZlIGZpcmV3YWxscywgd2FudCB0 byBwcm92aWRlIGEgVURQLXBhdGggZm9yIFdlYlJUQyBhbmQgcG9zc2libHkgYWxzbyBmb3IgYmV0 dGVyIHF1YWxpdHkgd2hlcmUgUlRDIGRvIG5vdCBjb21wZXRlIHdpdGggZGF0YSB0cmFmZmljLg0K QWxzbyBjb25zaWRlcmluZw0KLSBNb2JpbGl0eTsgSXQgaXMgY29tbW9uIHRvIG1vdmUgZnJvbSBh IExBTiB0byBhY2Nlc3NpbmcgdmlhIFdpRmkgb3IgM0cvNEcgT1RUIGNoYW5uZWxzLCBhbGwgc2hv dWxkIGJlIGFibGUgdG8gYXV0b21hdGljYWxseSBvZmZlciB0aGVpciBvd24gb3B0aW1hbCBUVVJO IHNlcnZlcg0KDQpUaGlzIGxlYWRzIHVzIGludG8gIOKAnFRVUk7igKZ0byBpZGVudGlmeSBXZWJS VEMgZmxvd3PigJ0gZXRjISBJdCBpcyBub3QgYSBtaXN0YWtlLCBidXQgdGhlIHZlcnkgbmVlZCBm b3IgdGhpcyBtaWxlc3RvbmUhDQoNCkFnYWluLCBpdCBoYXMgbm90IGJlZW4gZGVtb25zdHJhdGVk IHdoeSBUVVJOIGlzIHRoZSByaWdodCB0ZWNobm9sb2d5IGhlcmUsIGNvbXBhcmVkIHRvIGEgbW9y ZSB0cmFuc3BhcmVudCBmbG93IGlkZW50aWZpY2F0aW9uIHRvb2wgbGlrZSBNQUxJQ0UuIFdlIGRv bid0IGZvcmNlIGFsbCBIVFRQIHJlcXVlc3RzIHRvIGxvY2F0ZSBhIEhUVFAgcHJveHkgdmlhIGFu eWNhc3QsIEkgZG9uJ3Qgc2VlIHdoeSB3ZSBuZWVkIHRvIGRvIHRoZSBzYW1lIGZvciBXZWJSVEMu DQoNCldoYXQgYXJlIHRoZSBoZXNpdGF0aW9ucyByYWlzZWQgaGVyZT8NCj4gVFVSTiBwcmltYXJp bHkgdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dzLCBhcyBvcHBvc2VkIHRvIHVzaW5nIGl0IGFzIGEg TkFUIHRyYXZlcnNhbCB0b29sLiBUaGlzIG1ha2VzIG1lIGNvbmNlcm5lZCB0aGF0IHdlIG1heSBi ZSB1c2luZyB0aGUgd3JvbmcgdGVjaG5vbG9neSB0byBzb2x2ZSB0aGUgcHJvYmxlbQ0KSXQgaXMg Y29ycmVjdCB0aGF0IElDRS9TVFVOL1RVUk4gd2FzIGRlc2lnbmVkIHRvIGFkZHJlc3MgdGhlIE5B VC9GaXJld2FsbCB0cmF2ZXJzYWwgcHJvYmxlbSBhc3NvY2lhdGVkIHdpdGggcmVhbC10aW1lIGNv bW11bmljYXRpb24gKFNJUCBhdCB0aGF0IHRpbWUpLiBIb3dldmVyLCBpdHMgbGFyZ2VzdCBmbGF3 L3Byb2JsZW0gaXMgdGhhdCBxdWFsaXR5IHRoaW5ncyB3ZXJlIG5vdCAoY291bGQgbm90IGJlPykg Y29uc2lkZXJlZC4gVGhlIG1ldGhvZOKAmXMgdmVyeSBpZGVhIChsaWtlIGFsbCBzaW1pbGFyIG1l dGhvZHMgZm9yIGdldHRpbmcgUlRDIHRocm91Z2ggb3JkaW5hcnkgTkFUL0ZpcmV3YWxscykgaXMg dG8gZm9vbCB0aGUgbWVkaWEgdGhyb3VnaCBhIE5BVC9GaXJld2FsbCB0aGF0IGlzIHVuYXdhcmUg b2Ygd2hhdCBpcyBoYXBwZW5pbmcuIFRodXMsIHRoaXMgaXMgcm9vdCBvZiBxdWFsaXR5IGlzc3Vl cyAoYW5kIGJhbmR3aWR0aCBhbGxvY2F0aW9uIG9wdGltaXphdGlvbikgdGhhdCBuZWVkcyB0byBi ZSBkZWFsdCB3aXRoOiBSZWFsLXRpbWUgdHJhZmZpYyBmaWdodGluZyB3aXRoIGEgZGF0YSB0cmFm ZmljIGNyb3dkZWQgY29uZ2VzdGlvbiBwb2ludC4NCg0KSSB0aGluayB0aGF0ICJmb29saW5nIiBp cyBhbiBpbmNvcnJlY3QgZGVzY3JpcHRpb24uIFRoZSBOQVQgaXMgc3VwcG9zZWQgdG8gYmUgdHJh bnNwYXJlbnQgdG8gdGhlIGNsaWVudC4NCg0KQnV0LCBhIEJMRVNTSU5HIG9mIElDRS9TVFVOL1RV Uk4gaXMgdGhhdCBpdCBjYW4gYmUgc2VlbiBhcyBhIGxlZ2l0aW1hdGUgcmVxdWVzdCBmb3IgYSBz dWl0YWJsZSBwaXBlIGZvciBxdWFsaXR5IGRlbWFuZGluZyByZWFsIHRpbWUgdHJhZmZpYy4g4pi6 DQpJQ0UgaXMgYSBwcmUtcHJvdG9jb2wgeW91IHVzZSBiZWNhdXNlIHlvdSB3YW50IGEgcGF0aCBm b3IgcmVhbC10aW1lIG1lZGlhIGJldHdlZW4gcGFydGllcy4gSGVyZTogVGhlIGJyb3dzZXIgc2F5 cyBrbm9jayBrbm9jaywgSSB3YW50IHRvIGdldCBtZWRpYSB0aHJvdWdoIChhbmQgb2YgY291cnNl IHdpdGggYXMgZ29vZCBxdWFsaXR5IGFzIHJlcXVpcmVkIGFuZCBwb3NzaWJsZSkuDQoNCklmIHRo ZSBOQVQvRmlyZXdhbGwgb3duZXIgYW5kIG5ldHdvcmsgb3duZXIgYXJlIGFsbG93ZWQgdG8gc2Vl IHRoZXNlIHJlcXVlc3RzLCB0aGV5IGNhbiBoZWxwL2Fzc2lzdCBpbiBhY2hpZXZpbmcgdGhlIGdv b2QgbWVkaWEgcGF0aC4gSWYgdGhleSBhcmUgbm90IGF3YXJlLCB0aGV5IGNhbm5vdCBoZWxwIQ0K DQpIb3BlIHRoaXMgbWFkZSBpdCB1bmRlcnN0YW5kYWJsZSBvbiBhbiBvdmVydmlldyBsZXZlbCBo b3cgdGhpcyBjYW4gYmVjb21lIOKAnFRVUk7igKZ0byBpZGVudGlmeSBXZWJSVEMgZmxvd3PigJ0N Ckl0IGlzIGFsc28gdGhlIE9OTFkgd2F5IEkgY2FuIHNlZSB0byBhY2hpZXZlIHdoYXQgd2Ugd2Fu dCB0byBhY2hpZXZlIGFuZCBzaG91bGQgYmUgdGhlIGFpbSBhbmQgcmVxdWlyZW1lbnQgb2YgdGhp cyBtaWxlc3RvbmUuDQoNCkkgYW0gdGFsa2luZyBhYm91dCBnZW5lcmFsIHVzYWdlIG9mIFdlYlJU QyBvdmVyIEludGVybmV0L21vYmlsZSBPVFQgKG5vdCBmZWVkaW5nIFdlYlJUQyBpbnRvIGFwcGxp Y2F0aW9uIHNwZWNpZmljIG5ldHdvcmtzIGxpa2UgSU1TIHdoZXJlIG90aGVyIG1ldGhvZHMgbWF5 IGV4aXN0KS4NCg0KVGhpcyBpcyBnb29kLCBub3QgZXZpbCENCg0KSWYgdGhlIGhlc2l0YXRpb25z IGFyZSByYWlzZWQgYmVjYXVzZSBvZiBhIGJlbGllZi9ob3BlL3dpc2ggdGhhdCB0aGVyZSBhcmUg bm8gb3Igd2lsbCBub3QgYmUgc2V2ZXJlIHF1YWxpdHkgaXNzdWVzIOKAnGJlY2F1c2UgaXQgaXMg YWxsIGFib3V0IGJhbmR3aWR0aOKAnSwg4oCcaXQgd2lsbCByZXNvbHZlIGl0c2VsZiB3aXRoIHRp bWXigJ0gZXRjLiwgSSBzdHJvbmdseSBvYmplY3QhIFRoYXQgaXMgd3JvbmcgYW5kIHdpbGwgYmUg dmVyeSBkZXRyaW1lbnRhbCBmb3IgV2ViUlRDIHVzYWdlLiBXZSBhbHJlYWR5IHNlZSBpdCBhbmQg SSBjYW4gZ2l2ZSBudW1lcm91cyBleGFtcGxlcyBvZiBob3cgbXVjaCBsZXNzIHF1YWxpdHkgZGVt YW5kaW5nIFZvSVAgaXMvaXMgbm90IGhhbmRsZWQgcXVhbGl0eSB3aXNlIGFuZCB0aGF0IGl0IG1h dHRlcnMuIEFuZCwgd2hhdCB3b3VsZCBiZSBiYWQgY29uc2lkZXJpbmcgcXVhbGl0eSBpc3N1ZXMg YW5kIGFsbG93aW5nL2VuY291cmFnaW5nIG1ldGhvZHMgdG8gZGVhbCB3aXRoIHRoZW0/DQoNCklm IHRoZSBoZXNpdGF0aW9ucyBhcmUgcmFpc2VkLCBiZWNhdXNlIG9mIHN1c3BpY2lvbiB0aGF0IHRo ZSBtZXRob2RzIHdlIG1heSByZWNvbW1lbmQgbWF5IGJlIG1pc3VzZWQgdG8gc3RvcC9ibG9jay9k ZXN0cm95IFdlYlJUQyB1c2FnZSAoZS5nLiB0byBwcm90ZWN0IGluY29tZSBmcm9tIGNhcnJpZXIg dGVsZXBob255IHRyYWZmaWMpLCBJIGNvdWxkIHVuZGVyc3RhbmQgYW5kIHdvdWxkIGZpZ2h0IHRo ZSBzYW1lIGJhdHRsZS4gQnV0IGhvcGVmdWxseSwgdGhvc2UgZGF5cyBhcmUgKHNvb24pIG92ZXIg 4oCTIEF0IGxlYXN0IGZvcndhcmQgdGhpbmtpbmcgY2FycmllcuKAmXMgcmVhbGl6ZSB0aGF0IGFs cmVhZHkuIFdlYiBSVEMgd2lsbCBoYXBwZW4uIFdoaWNoIGN1c3RvbWVycyB3YW50IHRvIHBheSBm b3IgYW4gYWNjZXNzIHdpdGggYmxvY2tlZCBXZWJSVEM/IFRoZSBjYXJyaWVy4oCZcyBvZmZlcmlu Zy9hc3N1cmluZyBnb29kIFdlYlJUQyB3aWxsIHJhdGhlciBnZXQgdGhlIGN1c3RvbWVycyBhbmQg aW5jb21lIOKYui4gKE1heWJlIHRoZSBXZWIgYnJvd3NlciBjYW4gZGV0ZWN0IGFuZCBlbmNvdXJh Z2UgdGhpc+KApikNCg0KSWYgdGhlcmUgYXJlIHRlY2huaWNhbCBjb25jZXJucyBvZiBiYWQgcmVz dWx0LCBvciBiZXR0ZXIgbWV0aG9kcyBhbGxvd2luZyBuZXR3b3JrIHByb3ZpZGVycyBhbmQgTEFO IG1hbmFnZXJzIHRvIG9mZmVyIGFuZCBpbmZvcm0gdGhlIGJyb3dzZXIgdGhhdCB0aGVyZSBhcmUg Z29vZCBtZWRpYSBwYXRocyB0byBiZSB1c2VkLCBhbmQgdGhhdCB0aGUgd2ViIGJyb3dzZXIgYXV0 b21hdGljYWxseSBjYW4gY2hvc2UgdGhvc2UsIHRoZW4gbGV0IHVzIGFsbCB1bmRlcnN0YW5kIHRo b3NlLCBzbyB3ZSBjYW4gYWNoaWV2ZSB3aGF0IHNob3VsZCBiZSBhY2hpZXZlZCBieSB0aGlzIG1p bGVzdG9uZS4NCg0KU2t5cGUsIEhhbmdvdXRzLCBGYWNldGltZSBhcmUgZG9pbmcgYmlsbGlvbnMg b2YgbWludXRlcyBwZXIgd2VlayBhbmQgdGhlIEludGVybmV0IGhhcyBub3QgbWVsdGVkIHlldC4g SWYgd2UgbmVlZCB0byBkbyBmbG93IGlkZW50aWZpY2F0aW9uIHRvIGFsbG93IHRyYWZmaWMgdG8g YmUgcHJpb3JpdGl6ZWQsIGZpbmUgKHNlZSBhYm92ZSByZWdhcmRpbmcgbXkgcHJlZmVycmVkIGFw cHJvYWNoKSwgYnV0IGZvcmNpbmcgYWxsIFdlYlJUQyB0cmFmZmljIHRocm91Z2ggYSBNSVRNIChU VVJOIHNlcnZlcikgaXMgYSBtdWNoIGJpZ2dlciBqdW1wIHRoYXQgSSBkb24ndCB5ZXQgc2VlIHRo ZSBqdXN0aWZpY2F0aW9uIGZvci4NCg0KSW4gc2hvcnQ6IFRVUk4gaXMgYSB0ZWNobm9sb2d5IHRo YXQgaXMgc3VwcG9zZWQgdG8gZmFkZSBhd2F5IHdpdGggdGhlIG1vdmUgdG8gSVB2Ni4gSSBkb24n dCB0aGluayB3ZSB3YW50IHRvIG1ha2UgaXQgYSBjcml0aWNhbCBlbGVtZW50IG9mIFdlYlJUQy4N Cg0KL0thcmwNCg0KDQpGcsOlbjogRGFuIFdpbmcgW21haWx0bzpkd2luZ0BjaXNjby5jb208bWFp bHRvOmR3aW5nQGNpc2NvLmNvbT5dDQpTa2lja2F0OiBkZW4gMTEgZmVicnVhcmkgMjAxNCAxODoy NQ0KVGlsbDogTWFyYyBCbGFuY2hldA0KS29waWE6IEp1c3RpbiBVYmVydGk7IHRpcmVkZHlAaWNp c2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tPjsgS2FybCBTdGFobDsgdHJhbUBpZXRm Lm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IFNpbW9uIFBlcnJlYXVsdA0KDQrDhG1uZTogUmU6 IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNt IGZvciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNCg0KT24gRmViIDExLCAyMDE0LCBhdCA5OjA4IEFN LCBNYXJjIEJsYW5jaGV0IDxtYXJjLmJsYW5jaGV0QHZpYWdlbmllLmNhPG1haWx0bzptYXJjLmJs YW5jaGV0QHZpYWdlbmllLmNhPj4gd3JvdGU6DQoNCkxlIDIwMTQtMDItMTEgw6AgMDA6MzksIERh biBXaW5nIDxkd2luZ0BjaXNjby5jb208bWFpbHRvOmR3aW5nQGNpc2NvLmNvbT4+IGEgw6ljcml0 IDoNCg0KDQpPbiBGZWIgMTAsIDIwMTQsIGF0IDU6MzAgUE0sIEp1c3RpbiBVYmVydGkgPGp1YmVy dGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29nbGUuY29tPj4gd3JvdGU6DQoNCkdvb2Qg dG8gc2VlIHRoZXJlIGlzIGEgbG90IG9mIGludGVyZXN0IGZvciB0aGlzIG1pbGVzdG9uZS4gQnV0 IGJhc2VkIG9uIHRoZSBkZXNjcmlwdGlvbiBoZXJlLCBpdCBzZWVtcyBsaWtlIHdlIHdhbnQgdG8g dXNlIFRVUk4gcHJpbWFyaWx5IHRvIGlkZW50aWZ5IFdlYlJUQyBmbG93cywgYXMgb3Bwb3NlZCB0 byB1c2luZyBpdCBhcyBhIE5BVCB0cmF2ZXJzYWwgdG9vbC4gVGhpcyBtYWtlcyBtZSBjb25jZXJu ZWQgdGhhdCB3ZSBtYXkgYmUgdXNpbmcgdGhlIHdyb25nIHRlY2hub2xvZ3kgdG8gc29sdmUgdGhl IHByb2JsZW0uDQoNCisxLg0KDQpJIHdvdWxkIHByZWZlciBhbGxvd2luZyBmbG93cyB0byBlc3Rh Ymxpc2ggdGhlbXNlbHZlcyB1c2luZyB0aGVpciAnYmVzdCcgcGF0aCwgYW5kIHRoZSBiZXN0IHBh dGggaXMgc2VsZG9tIHRocm91Z2ggYSBUVVJOIHNlcnZlci4gIFdoZW4gd2UgaW1hZ2luZSBJUHY2 IGluIG91ciBmdXR1cmUsIHdlIGRvbid0IHdhbnQgdG8gZm9yY2UgYW4gYXBwbGljYXRpb24tbGV2 ZWwgcHJveHkgKFRVUk4pIHNlcnZlciBvbiB0aGUgcGF0aCBzb2xlbHkgZm9yIHRyYXZlcnNpbmcg YW4gSVB2NiBmaXJld2FsbC4NCg0KDQpJdCBzZWVtcyB0aGlzIHRocmVhZCBpcyBjb25mbGF0aW5n IGFsbCB0aGUgcG9zc2libGUgcmVhc29ucyAvIGp1c3RpZmljYXRpb25zIGZvciBUVVJOOg0KICAq IG1vYmlsaXR5DQogICogTkFUIHRyYXZlcnNhbCAoYm90aCBlbmRwb2ludHMgYXJlIGJlaGluZCBl bmRwb2ludC1kZXBlbmRlbnQgbWFwcGluZyBOQVRzKQ0KICAqIGZpcmV3YWxsIHRyYXZlcnNhbCAo ZmlyZXdhbGwgYmxvY2tzIFVEUCkNCiAgKiBlbmhhbmNpbmcgcHJpdmFjeQ0KDQpVbmZvcnR1bmF0 ZWx5IHRoZSBUVVJOIHNlcnZlciBub3IgdGhlIGVuZHBvaW50IHJlYWxseSBrbm93IHdoaWNoIG9m IHRob3NlIHVzZS1jYXNlcyBpcyBkZXNpcmVkIChieSB0aGUgdXNlciBvciBieSB0aGUgSVQgbmV0 d29yayBhZG1pbmlzdHJhdG9yKSBvciBuZWNlc3NhcnkgKGZvciB0aGUgY2FsbCB0byB3b3JrIGF0 IGFsbCkuDQoNCkRhbiwgd2hpbGUgSSBhZ3JlZSBpbiBwcmluY2lwbGUsIEkgZG91YnQgdGhhdCBh IHVzZXIgY291bGQgZXZlciBzYXkgIkkgd2FudCBtb2JpbGl0eSBvciBJIHdhbnQgTkFUIHRyYXZl cnNhbCIuIEkgdGhpbmsgdGhlIHVzZXIgb25seSB3YW50IHRoZSBjYWxsIHRvIHN1Y2NlZWQsIHdo YXRldmVyIHRoZSBwcm9wZXJ0aWVzIG9mIGl0cyBuZXR3b3JrIHBvaW50IG9mIGF0dGFjaG1lbnQg YXJlLg0KDQpTbyB3aGF0IGNhbiB3ZSBkbz8gIFNob3VsZCB0aGUgVFVSTiBzZXJ2ZXIgcHJvdmlk ZSBhbnkgYW5kIGFsbCBzZXJ2aWNlcyB0aGUgVFVSTiBjbGllbnQgbWlnaHQgcG9zc2libHkgd2Fu dCwgYXMgdGhhdCBpcyB3aGF0IGEgcm9idXN0IFRVUk4gc2VydmVyIHdpbGwgZG8sIGFuZCB0aGUg ZW5kcG9pbnQgc2hvdWxkIHByZWZlciBUVVJOIGNhbmRpZGF0ZXMgb3ZlciBhbGwgb3RoZXJzIGJl Y2F1c2UgdGhlcmUgbWlnaHQgYmUgc29tZSBmdW5jdGlvbmFsaXR5IC8gdXNlZnVsbmVzcyBvZiBU VVJOIHRoYXQgdGhlIHVzZXIgbWlnaHQgZ2FpbiB0aHJvdWdoIFRVUk4gKGUuZy4sIGVuaGFuY2Vk IHByaXZhY3kpPw0KDQotZA0KDQoNCg0KIFRoaXMgc2VlbXMgcHJvYmxlbWF0aWMuICBQZXJoYXBz IHdlIG5lZWQgYSB3YXkgdG8gc2lnbmFsIHRoZSBkZXNpcmVkIHVzZS1jYXNlICgidHJhaXQiKSwg b3IgYXMgSnVzdGluIHN1Z2dlc3RzLCB1c2luZyBhIGRpZmZlcmVudCB0ZWNobm9sb2d5IGZvciBz b21lIG9mIHRoZXNlIHVzZS1jYXNlcy4NCg0KLWQNCg0KDQoNCg0KT24gTW9uLCBGZWIgMTAsIDIw MTQgYXQgMzoxOCBQTSwgS2FybCBTdGFobCA8a2FybC5zdGFobEBpbnRlcnRleC5zZTxtYWlsdG86 a2FybC5zdGFobEBpbnRlcnRleC5zZT4+IHdyb3RlOg0KU2ltb24sDQoNCkdvb2QgcXVlc3Rpb25z IC0gc2VlIGlubGluZSBiZWxvdyAtLT4gLg0KU29tZSBtb3JlIHRob3VnaHQgaXMgcmVxdWlyZWQh DQoNCi9LYXJsDQoNCi0tLS0tVXJzcHJ1bmdsaWd0IG1lZGRlbGFuZGUtLS0tLQ0KRnLDpW46IHRy YW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRm Lm9yZz5dIEbDtnIgU2ltb24gUGVycmVhdWx0DQpTa2lja2F0OiBkZW4gMTAgZmVicnVhcmkgMjAx NCAxNToxNg0KVGlsbDogS2FybCBTdGFobDsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRm Lm9yZz47IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tPg0Kw4Rt bmU6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1l Y2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpLYXJsLA0KDQpJdCBpcyBncmVhdCB0 byBzZWUgc3VjaCBlbnRodXNpYXNtISBUaGFua3MhDQoNCkkgaGF2ZSBhIGNvdXBsZSB0ZWNobmlj YWwgcXVlc3Rpb25zLi4uDQoNCkxlIDIwMTQtMDItMDggMDg6MTEsIEthcmwgU3RhaGwgYSDDqWNy aXQgOg0KPiAtIE5vdGUgdGhhdCB0byBhY2hpZXZlIHNvbWUgb2YgdGhlIGFib3ZlIHBvaW50cywg VFVSTiBtdXN0IGJlIGZhdm9yZWQNCj4gb3ZlciBTVFVOIHRvIGVuZm9yY2UgdGhhdCB0aGUgVFVS Ti1wYXRoIGFjdHVhbGx5IGlzIHVzZWQuIChUaGUgQW55Y2FzdA0KPiBtZXRob2Qgc3VnZ2VzdGVk IGJlbG93LCDigJxhdXRvbWF0aWNhbGx54oCdIGRvZXMgdGhpcy4pDQoNCkkgdW5kZXJzdGFuZCB0 aGUgU1RVTiB2cyBUVVJOIHByaW9yaXR5IGlzc3VlLiBCdXQgSSBkb24ndCBzZWUgaG93IGFueWNh c3QgYWZmZWN0cyBpdCBpbiBhbnkgd2F5LiBDYW4geW91IHBsZWFzZSBleHBsYWluPw0KLS0tIEdv b2QgcG9pbnQgLSBJIHdhcyBhIGJpdCBxdWljayBoZXJlIChtYXliZSB0b28gcXVpY2spDQpXZSBo YXZlIGdpdmVuIHRoaXMgcXVpdGUgYml0IG9mIHRob3VnaHQsIHNpbmNlIGV2ZW4gaWYgYSBUVVJO IHNlcnZlciBpcyBwcm92aWRlZCBhbmQgZGlzY292ZXJlZCwgQ1VSUkVOVCB1c2FnZSBvZiBJQ0Ug bWF5IHN1Z2dlc3QgYSBjYW5kaWRhdGUgZnJvbSB0aGUgcmVtb3RlIHBhcnR5IHRoYXQgd2lsbCBt YWtlIGEgY29ubmVjdGlvbiB3aXRob3V0IHRoZSBuZWVkL3VzYWdlIG9mIHRoZSBUVVJOIHNlcnZl ciAodGhhdCB3ZSB3YW50ZWQgdG8gYmUgdXNlZCBmb3IgdGhlIGdvb2QgcHVycG9zZXMgbGlzdGVk KS4NCg0KVGhlIG9ubHkgd2F5IHdlIGZvdW5kIGFyb3VuZCB0aGlzLCB3YXMgdG8gc3RvcCBTVFVO IHRocm91Z2ggdGhlIElQIGRlZmF1bHQgZ2F0ZXdheSAobGlrZSBhIHJlc3RyaWN0aXZlIEVudGVy cHJpc2UgZmlyZXdhbGwgZG9lcyBpbmhpYml0aW5nIElDRSBjb25uZWN0aXZpdHksIHdoaWNoIG90 aGVycyBhcmUgY29uY2VybmVkIGFib3V0Li4uKS4gU2luY2UgdGhlIHByb3Zpc2lvbmluZyBvZiBh dXRvLWRpc2NvdmVyeSB1c2luZyB0aGUgYW55Y2FzdCBtZWNoYW5pc20sIHdvdWxkIGJlIGFkZGlu ZyBhIHJvdXRlIGluIGEgZGVmYXVsdCBnYXRld2F5LCBhZGRpbmcgYSBmaXJld2FsbCBydWxlIHRv IGVhdCBTVFVOIHBhY2tldHMgd291bGQgYXNzdXJlIHRoYXQgdGhlIHByb3Zpc2lvbmVkIFRVUk4g c2VydmVyIGFjdHVhbGx5IGJlY29tZXMgdXNlZCAoYW5kIG5vdCBieXBhc3NlZCAiYnkgYWNjaWRl bnQiKS4gKFRoYXQgd2FzIHRoZSB0aG91Z2h0IGJlaGluZCB0aGUg4oCcYXV0b21hdGljYWxseeKA nSB3aXRoaW4gcXVvdGVzLikNCg0KQlVULCBzaW5jZSB5b3UgYnJvdWdodCB1cCB0aGUgcXVlc3Rp b24sIGFzc3VtaW5nIHRoYXQgd2UgaGF2ZSB0aGUgcG93ZXIgdG8gZW5mb3JjZSBXZWJSVEMgdXNh Z2Ugb2YgSUNFLCBJIGJlbGlldmUgYSBNVVNUIHJlcXVpcmVtZW50IHRvIHVzZSBhbiBhdXRvLWRp c2NvdmVyZWQgVFVSTiBzZXJ2ZXIgaW5zdGVhZCBvZiBTVFVOLCB3b3VsZCBzb2x2ZSB0aGUgc2Ft ZSBwcm9ibGVtLiBIb3dldmVyLCB0aGlua2luZyBmdXJ0aGVyIChpbiByZWxhdGlvbiB0byB5b3Vy IG5leHQgcXVlc3Rpb24gLSAiYW55b25lIGNvdWxkIHNldCB1cCBhIGJhZGx5LW1haW50YWluZWQi IC0gZW5mb3JjaW5nIHN1Y2ggSUNFIHVzYWdlIG1heSBub3QgYmUgZ29vZC4pDQoNCg0KPiAtIDNe cmQgVGhlIEFueWNhc3QgbWV0aG9kIGJlbG93IOKAkyBJIHNlZSBubyBwcm9ibGVtDQo+DQo+IEl0 IGFsc28gaGFzIHRoZSBhZHZhbnRhZ2Ugb2YgZW5jb3VyYWdpbmcgKGJ1dCBub3QgcmVxdWlyaW5n KSB0aGUNCj4gU1RVTi9UVVJOIHRvIGJlIGJ1aWx0IGluIHRoZSBkZWZhdWx0IGdhdGV3YXkgb3Ig TkFUL2ZpcmV3YWxsL2FjY2Vzcw0KPiByb3V0ZXIgaXRzZWxmLCB3aXRoIGEgc2Vjb25kIGludGVy ZmFjZSB0byBhIHB1YmxpYyBJUCBhZGRyZXNzIG9uIHRoZQ0KPiBXQU4gc2lkZS4gKEN1cnJlbnQg dm9sdW1lIGRlcGxveWVkLCBsb3cgY29zdCBOU1AgdHJpcGxlIHBsYXkgbW9kZW1zDQo+IHVzdWFs bHkgaGF2ZSBhIHF1YWxpdHkgYXNzdXJlZCBsZXZlbCAyIG9yIGxldmVsIDMgV0FOIHBpcGUgZm9y IGp1c3QNCj4gdm9pY2UgKGFuZCBhbm90aGVyIGZvciBJUFRWKSDigJMgVGhlIGFueWNhc3QgZGlz Y292ZXJlZCBUVVJOLXNlcnZlciBjYW4NCj4gYmUgdGhlIGFjY2VzcyBnYXRld2F5IHRvIHN1Y2gg cXVhbGl0eSBwaXBlIGZvciBXZWJSVEMgbWVkaWEsIGluIGENCj4gc2luZ2xlIE5TUCBwcm92aWRl ZCBDUEUsIHNjYWxpbmcgZnJvbSByZXNpZGVudGlhbCBhbmQgdXAuKQ0KDQpTdXBwb3NlIHdlIGRl ZmluZSB3ZWxsLWtub3duIGFueWNhc3QgVFVSTiBzZXJ2ZXIgYWRkcmVzc2VzLiBIb3cgd291bGQg dGhpcyBub3QgYmUgc3ViamVjdCB0byB0aGUgc2FtZSBzZXJ2aWNlIHF1YWxpdHkgaXNzdWVzIHRo YXQgcGxhZ3VlZCA2dG80PyBUaGF0IGlzLCBhbnlvbmUgY291bGQgc2V0IHVwIGEgYmFkbHktbWFp bnRhaW5lZCwgdW5kZXItcHJvdmlzaW9uZWQgVFVSTiBzZXJ2ZXIgYW5kIGFubm91bmNlIGl0IG92 ZXIgQkdQIHRvIHRoZSB3b3JsZCwgYXMgaXQgd2FzIGRvbmUgZm9yDQo2dG80IHJlbGF5cy4gT3Ig anVzdCBiYWQgQkdQIG91dGJvdW5kIGZpbHRlciBjb25maWd1cmF0aW9uLiBBbmQgaG93IGNhbiB3 ZSBwcmV2ZW50IHRyaWFuZ2xlIHJvdXRpbmc/IFRoZXJlIGlzIG5vdGhpbmcgZ3VhcmFudGVlaW5n IHRoYXQgdGhlIGFueWNhc3Qgc2VydmVyIHlvdSBzZWUgaXMgYmVpbmcgcHJvdmlkZWQgdG8geW91 IGJ5IHlvdXIgSVNQLCByYXRoZXIgdGhhbiBhIHNlcnZlciBzaXR0aW5nIG9uIHRoZSBvdGhlciBz aWRlIG9mIHRoZSBwbGFuZXQuDQotLS0gR29vZCBwb2ludCAtIG5lZWRzIHRvIGJlIHJlc29sdmVk LiBGb3IgdGhpcyBJIGRvbid0IGhhdmUgYSByZWFkeSBhbnN3ZXIuLi4NCkFuIGF1dG8tZGlzY292 ZXJlZCBUVVJOIHNlcnZlciBtdXN0IGJlIHRydXN0ZWQgKHdoYXRldmVyIG1ldGhvZCBpdCBpcyBk aXNjb3ZlcmVkIGJ5KS4gV2UgYXJlIHRydXN0aW5nIHRoZSBvbmUgcHJvdmlkaW5nIHVzIHdpdGgg YW4gSVAgYWRkcmVzcyBhbmQgZGVmYXVsdCBnYXRld2F5IGFueXdheS4gSXQgd291bGQgYmUgZWFz eSBpZiB3ZSBjb3VsZCByZXVzZSB0aGF0IHRydXN0LCBpbnN0ZWFkIG9mIGFub3RoZXIgbWVjaGFu aXNtcy4NCg0KSXMgdGhlcmUgYSBnb29kIHdheSBmb3IgdGhlIGJyb3dzZXIgdG8gY2hlY2sgdGhh dCB0aGUgYW55Y2FzdCBhZGRyZXNzIGlzIG5vdCBoYW5kbGVkIGJleW9uZCB0aGUgbmV0d29yayBz ZXJ2aWNlIHByb3ZpZGVyJ3MgZGVmYXVsdCBnYXRld2F5PyBJZGVhcz8NCg0KDQoNClRoYW5rcywN ClNpbW9uDQotLQ0KRFROIG1hZGUgZWFzeSwgbGVhbiwgYW5kIHNtYXJ0IC0tPiBodHRwOi8vcG9z dGVsbGF0aW9uLnZpYWdlbmllLmNhPGh0dHA6Ly9wb3N0ZWxsYXRpb24udmlhZ2VuaWUuY2EvPg0K TkFUNjQvRE5TNjQgb3Blbi1zb3VyY2UgICAgICAgIC0tPiBodHRwOi8vZWNkeXNpcy52aWFnZW5p ZS5jYTxodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYS8+DQpTVFVOL1RVUk4gc2VydmVyICAgICAg ICAgICAgICAgLS0+IGh0dHA6Ly9udW1iLnZpYWdlbmllLmNhPGh0dHA6Ly9udW1iLnZpYWdlbmll LmNhLz4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0 cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRy YW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0DQp0cmFtQGlldGYub3JnPG1haWx0bzp0 cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFt DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp0cmFt IG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbQ0KDQoNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdHJhbSBtYWlsaW5nIGxpc3QN CnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KDQo= --_000_913383AAA69FF945B8F946018B75898A242AF2D6xmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYu TXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDow aW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVm dDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+WWVzIHRoZSBiZWxvdyBkcmFmdCBzb2x2ZXMgdGhlIGF1dGhlbnRp Y2F0aW9uIHByb2JsZW0gaWYgRW50ZXJwcmlzZSBoYXMgbXVsdGlwbGUgZG9tYWlucy4mbmJzcDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QnV0IGhvdyB3aWxsIHRoYXQgaGVscCB0aGUgRW50ZXJwcmlzZSBJLlQgaWRl bnRpZnkgaWYgdGhlIHRyYWZmaWMgZ29pbmcgdGhyb3VnaCB0aGUgVFVSTiBzZXJ2ZXIgYXJlIFdl YlJUQyBtZWRpYSBzdHJlYW1zIGFuZCBub3Qgc29tZSBvdGhlciB0cmFmZmljLiZuYnNwOyBNYXkg YmUNCiB3ZSBuZWVkIHRvIHRha2UgYSBzdGVwIGJhY2sgYW5kIGxvb2sgaW50byB0aGUgRmlyZXdh bGwgcmVxdWlyZW1lbnRzIGZvciBFbnRlcnByaXNlIGRlcGxveW1lbnQgd2hpY2ggYXJlIHR5cGlj YWxseSB2ZXJ5IHJlc3RyaWN0aXZlIGFuZCBoYXZlIGEgbmVlZCB0byBjbGFzc2lmeSB0aGUgdHJh ZmZpYyB0byBlbmZvcmNlIHZhcmlvdXMgRmlyZXdhbGwgYWN0aW9ucyBsaWtlIHBlcm1pdCwgYmxv Y2ssIGV0Yy4mbmJzcDsgRW50ZXJwcmlzZSBGaXJld2FsbHMgYXJlDQogdHlwaWNhbGx5IGNvbmZp Z3VyYXRpb24gdG8gYmxvY2sgUDJQIHVkcCB0cmFmZmljIGFuZCBwZXJmb3JtIFNJUCBBTEcgdG8g cGVybWl0IG1lZGlhIHN0cmVhbXMuIEJ1dCB0aGlzIHdvbuKAmXQgd29yayB3aXRoIFdlYlJUQyBh bmQgd2Ugd2FudCBhIHdheSB0byBtb3ZlIGF3YXkgZnJvbSBBTEcuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4xLiBJcyBk ZXBsb3lpbmcgVFVSTiBzZXJ2ZXIgaW4gRW50ZXJwcmlzZSBhbmQgbWFraW5nIHN1cmUgdGhhdCBV RFAgdHJhZmZpYyBnb2VzIHRocm91Z2ggaXQgc3VmZmljaWVudCA/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4yLiBUaGUg bW9yZSBjb21wZWxsaW5nIHVzZSBjYXNlcyBmb3IgRW50ZXJwcmlzZXMgd291bGQgYmUgdG8gaWRl bnRpZnkgaWYgdGhlIG1lZGlhIHN0cmVhbXMgYXJlIGFzc29jaWF0ZWQgd2l0aCBidXNpbmVzcyBj YWxsIG9yIG1lZGlhIHN0cmVhbXMgaW5pdGlhdGVkIGJlY2F1c2UNCiBvZiB1c2luZyBhIHNvY2lh bCBuZXR3b3JraW5nIHNpdGUsIG1lZGlhIHN0cmVhbXMgYmVjYXVzZSBvZiBnYW1pbmcgZXRjLiBz byB0aGF0IHRoZXNlIG5vbi1idXNpbmVzcyBjYWxsIHJlbGF0ZWQgdHJhZmZpYyBjYW4gYmUgcmF0 ZS1saW1pdGVkIG9yIHRyZWF0ZWQgZGlmZmVyZW50bHkgc28gYXMgdG8gbm90IGltcGFjdCB0aGUg YnVzaW5lc3MgY2FsbHMgLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBIdXR0b24sIEFuZHJl dyBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzphbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPm1haWx0bzphbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbTwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBG cmlkYXksIEZlYnJ1YXJ5IDE0LCAyMDE0IDEyOjU2IEFNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFs ZXN3YXIgUmVkZHkgKHRpcmVkZHkpPGJyPg0KPGI+Q2M6PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOnRyYW1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYu b3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJFOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5 IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5PbmUgc3VjaCBlbmhhbmNlbWVudCBpcyBkZXNjcmliZWQgaW4NCjwvc3Bhbj48 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb2huc3Rvbi10cmFtLXN0 dW4tb3JpZ2luLTAxIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb2huc3Rvbi10 cmFtLXN0dW4tb3JpZ2luLTAxPC9hPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5keTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGly ZWRkeUBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86dGlyZWRk eUBjaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gMTMgRmVicnVhcnkgMjAxNCAxNTozNDxicj4NCjxiPlRvOjwvYj4gSHV0 dG9uLCBBbmRyZXc8YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNt IGZvciBlbnRlcnByaXNlIGFuZCBJU1BzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkhpIEFuZHksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5ZZXMsIFdlYlJUQyBicm93c2VyIHdpbGwgaGF2ZSB0byBhIHN1 cHBvcnQgYSBudW1iZXIgb2YgbWVjaGFuaXNtcy4gVGhpcyB3YXMgZGlzY3Vzc2VkIGluIFJUQ1dF QiBtYWlsaW5nIGxpc3Qgc29tZXRpbWUgYmFjayBhbmQgc2VjdGlvbiAzLjMuNC4xIGluDQo8L3Nw YW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWIt dXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2Vz LWFuZC1yZXF1aXJlbWVudHMtMTQ8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4NCiBoYXMgYmVlbiB1cGRhdGVkIHRvIHJlZmxlY3QgdGhpcyBwb2lu dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB0 aGUgZW5oYW5jZW1lbnRzIFRVUk4gc2VydmVyIHlvdSBhcmUgbG9va2luZyBmb3IgYW5kIHdoYXQg cHJvYmxlbXMgZG9lcyBpdCBzb2x2ZSA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBIdXR0b24s IEFuZHJldyBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzphbmRyZXcuaHV0dG9uQHVuaWZ5LmNvbSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1haWx0bzphbmRyZXcuaHV0dG9uQHVuaWZ5LmNv bTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgNDoxOCBQTTxicj4NCjxiPlRvOjwvYj4g VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJh bUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSRTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRp c2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhlIHByaW1lIHVzZSBjYXNlIGZvciB0aGlzIGlzIGRvY3VtZW50 ZWQgaW4NCjwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xMiNzZWN0aW9uLTMuMy41LjEi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTIjc2VjdGlvbi0z LjMuNS4xPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+DQogYW5kIEkgdGhpbmsgdGhhdCBUUkFNIHdpbGwgcHJvYmFibHkgbWFrZSBlbmhhbmNlbWVu dHMgdG8gVFVSTiBlbmFibGluZyBzdWNoIGFuIOKAnGVudGVycHJpc2UgYXVkaXRpbmcgVFVSTiBz ZXJ2ZXLigJ0gdG8gZG8gYW4gZWZmZWN0aXZlIGpvYiBvZiBtYW5hZ2luZyBXZWJSVEMgdHJhZmZp YyBpbiBhbiBlbnRlcnByaXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIG9mIGNvdXJzZSBtb3JlIHRo YW4gb25lIHByb2JsZW0gYW5kIG1hbnkgcG9zc2libHkgd2F5cyB0byBzb2x2ZSB0aGVtIGFuZCBJ IHJlY2VudGx5IHVwZGF0ZWQNCjwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1odXR0b24tcnRjd2ViLW5hdC1maXJld2FsbC1jb25zaWRlcmF0aW9ucy0wMyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1odXR0b24tcnRjd2ViLW5hdC1maXJld2FsbC1jb25zaWRlcmF0aW9ucy0wMzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPg0KIHRvIGxpc3Qg dGhlc2UgZm9yIGRpc2N1c3Npb24gaW5jbHVkaW5nIFBDUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlVuZm9ydHVuYXRl bHkgc29sdXRpb25zIGFyZSBuZWVkZWQgdG9kYXkgd2l0aGluIGV4aXN0aW5nIG5ldHdvcmtzIGFu ZCBQQ1AgZG9lcyBub3Qgc2VlbSBzbyB1c2VmdWwgaGVyZSBzbyB3ZSBoYXZlIHRvIGxvb2sgYXQg bXVsdGlwbGUgc29sdXRpb25zIGFuZCBwcm9iYWJseQ0KIFdlYlJUQyBicm93c2VycyBoYXZlIHRv IHN1cHBvcnQgYSBudW1iZXIgb2YgbWVjaGFuaXNtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRpcnVtYWxlc3dhciBSZWRkeSAodGly ZWRkeSkgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86dGlyZWRkeUBjaXNjby5jb208L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMTMgRmVicnVh cnkgMjAxNCAwMzozNzxicj4NCjxiPlRvOjwvYj4gSHV0dG9uLCBBbmRyZXc7IEp1c3RpbiBVYmVy dGk7IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpPGJyPg0KPGI+Q2M6PC9iPiA8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPnRpcmVkZHlAaWNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjsgU2ltb24gUGVycmVhdWx0OyBPbGVnIE1vc2thbGVua287DQo8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBN YXJjIEJsYW5jaGV0OyBEYW4gV2luZyAoZHdpbmcpOyBLYXJsIFN0YWhsPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJFOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5 IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIG90aGVyIHdheXMgdG8gc29s dmUgdGhlIHByb2JsZW0gZm9yIGV4YW1wbGUgdXNpbmcgUENQLiBDYW4geW91IGNsYXJpZnkgaG93 IGRlcGxveWluZyBhIFRVUk4gc2VydmVyIGluIHRoZSBFbnRlcnByaXNlIHByb3RlY3RzIHRoZSB1 c2VycyBhbmQgdGhlIG5ldHdvcmsNCiA/IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LVRpcnUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gdHJhbSBb PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5IdXR0b24s IEFuZHJldzxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgMTow MCBBTTxicj4NCjxiPlRvOjwvYj4gSnVzdGluIFViZXJ0aTsgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1 bWFsIChtcGVydW1hbCk8YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGly ZWRkeUBpY2lzY28uY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dGlyZWRkeUBpY2lz Y28uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBTaW1vbiBQZXJy ZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47IE1hcmMgQmxhbmNoZXQ7IERhbiBXaW5nIChk d2luZyk7IEthcmwgU3RhaGw8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBNaWxlc3Rv bmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNl IGFuZCBJU1BzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBjYXNlIHdoZXJl IHRoZSBUVVJOIHNlcnZlciBpcyB0aGUgb25seSBvcHRpb24gbWF5IGJlY29tZSBjb21tb24gd2l0 aGluIGVudGVycHJpc2UgbmV0d29ya3MgYW5kIHRoYXQgbWlnaHQgYmUgZGVsaWJlcmF0ZSBlbnRl cnByaXNlIHBvbGljeSBiZWNhdXNlIGl0IHByb3ZpZGVzDQogdGhlIGJldHRlciBwYXRoIChVRFAg dGhyb3VnaCB0aGUgRi9XKSBhbmQgcHJvdGVjdHMgdGhlIHVzZXJzIGFuZCB0aGUgbmV0d29yay48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRyYW0gWzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4N CjxiPlNlbnQ6PC9iPiAxMiBGZWJydWFyeSAyMDE0IDE3OjQ2PGJyPg0KPGI+VG86PC9iPiBNdXRo dSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKTxicj4NCjxiPkNjOjwvYj4gPC9zcGFuPjxh IGhyZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij50aXJlZGR5QGljaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij47IFNpbW9uIFBlcnJlYXVsdDsgT2xlZyBNb3NrYWxlbmtvOw0KPC9zcGFuPjxhIGhyZWY9 Im1haWx0bzp0cmFtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBp ZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgTWFyYyBCbGFu Y2hldDsgRGFuIFdpbmcgKGR3aW5nKTsgS2FybCBTdGFobDxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5p c20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWUuIElmIFRVUk4gaXMgaW5kZWVkIGJlaW5nIHBy b3ZpZGVkIGZvciB0aGUgdXNlcidzIGJlbmVmaXQsIHRoZSBjbGllbnQncyBJQ0UgbG9naWMgKGJh c2VkIG9uIFJUVCBvciBzaW1pbGFyKSBzaG91bGQgcmVzdWx0IGluIGl0IHByZWZlcnJpbmcgdGhl IFRVUk4gcGF0aC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgMTIsIDIwMTQgYXQgMToy NyBBTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgJmx0OzxhIGhyZWY9Im1h aWx0bzptcGVydW1hbEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tcGVydW1hbEBjaXNjby5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+WWVzLCBJIGJlbGlldmUgdGhlIHNlY29uZCBjYXNlIGlz IHJhcmUsIGJ1dCB3b3VsZCBiZSBiZXR0ZXIgdGhhbiBhIHJhdCByYWNlIGIvdyBhZG1pbmlzdHJh dG9ycyB0cnlpbmcgdG8gYmxvY2sgcDJwIHRyYWZmaWMNCiBhbmQgZm9yY2UgaXQgdGhyb3VnaCBh IFRVUk4gc2VydmVyIGFuZCBhcHBzL2VuZHBvaW50cyBmaW5kaW5nIHNtYXJ0ZXIgd2F5cyB0byBi eXBhc3MgdGhlbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij5NdXRodTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gT2xlZyBNb3NrYWxlbmtvIFtt YWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptb20wNDAyNjdAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1vbTA0MDI2N0BnbWFpbC5jb208 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBGZWJydWFyeSAxMiwgMjAxNCAxOjA3IFBNPGJyPg0KPGI+VG86PC9iPiBN dXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKTxicj4NCjxiPkNjOjwvYj4gSnVzdGlu IFViZXJ0aTsgS2FybCBTdGFobDsgPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGljaXNj by5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dGlyZWRk eUBpY2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ow0KIE1h cmMgQmxhbmNoZXQ7IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBEYW4gV2luZyAoZHdpbmcpOyBTaW1v biBQZXJyZWF1bHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3RyYW1dIE1pbGVzdG9uZSAz OiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5k IElTUHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIFRVUk4gc2VydmVyIGhhcyB0byBiZSB1 c2VkIHdoZW4gaXQgaXMgZWl0aGVyIHRoZSBvbmx5IG9wdGlvbiwgb3IgaWYgaXQgcHJvdmlkZXMg YSBiZXR0ZXIgcGF0aCAoSSBndWVzcyB0aGUgc2Vjb25kIGNhc2UgaXMgcmF0aGVyIHJhcmUpLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEZlYiAxMSwgMjAxNCBh dCAxMTozMiBQTSwgTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkgJmx0OzxhIGhy ZWY9Im1haWx0bzptcGVydW1hbEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tcGVydW1hbEBj aXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+JiM0MzsxPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Rm9yY2luZyBhbGwgdHJh ZmZpYyB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgYW5kIGV4cGVjdGluZyBpdCB3b3VsZCBwcm92aWRl IHRoZSBiZXN0IHVzZXIgZXhwZXJpZW5jZSBkb2Vzbid0IGxvb2sgdGhlIHJpZ2h0DQogYXBwcm9h Y2guIEluc3RlYWQsIGlmIGEgcGF0aCB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgZXhpc3RzIGFuZCBk b2VzIHByb3ZpZGUgbG93ZXIgUlRULCBqaXR0ZXIgZXRjLCBiZWluZyBhYmxlIHRvIGRldGVjdCBh bmQgdXNlIChvciBzd2l0Y2ggdG8pIHRoYXQgcGF0aCBtaWdodCBiZSBkZXNpcmFibGUuLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pk11dGh1PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0cmFtIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+dHJhbS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KdXN0aW4gVWJlcnRpPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgMTIsIDIwMTQgMTE6NDMgQU08YnI+DQo8 Yj5Ubzo8L2I+IEthcmwgU3RhaGw8YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48YSBocmVmPSJtYWls dG86dGlyZWRkeUBpY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPnRpcmVkZHlAaWNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjsgTWFyYyBCbGFuY2hldDsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFt QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBEYW4gV2lu ZyAoZHdpbmcpOyBTaW1vbiBQZXJyZWF1bHQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFt XSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBl bnRlcnByaXNlIGFuZCBJU1BzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklubGluZS48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBGZWIgMTEsIDIwMTQgYXQgMjozNyBQ TSwgS2FybCBTdGFobCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmthcmwuc3RhaGxAaW50ZXJ0ZXguc2Ui IHRhcmdldD0iX2JsYW5rIj5rYXJsLnN0YWhsQGludGVydGV4LnNlPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5MaXN0ZW5pbmcgdG8gdGhpcyB0aHJlYWQs IEkgYW0gYWZyYWlkIHdlIGFyZSBtaXNzaW5nIHRoZSB2ZXJ5IHBvaW50IGFuZCBuZWNlc3NpdHkg Zm9yIHRoaXMgbWlsZXN0b25lITwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIFRoZXJlIGFy ZSBzZXZlcmUgTkFUIHRyYXZlcnNhbCBhbmQgcXVhbGl0eSBpc3N1ZXMgdGhhdCBzaG91bGQgYW5k IGNhbiBiZSBkZWFsdCB3aXRoIGJ5IGEgZ29vZCBhdXRvLWRpc2NvdmVyeQ0KIG1lY2hhbmlzbSBh bmQgdGhlIHJpZ2h0IHVzYWdlIGJ5IHRoZSB0dXJuIGNsaWVudCAodGhlIFdlYlJUQyBicm93c2Vy KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+VGhlcmUgYXJlIHdheXMsIG5vdCBvbmx5Og0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5FbnRlcnBy aXNlcyBvciBJU1BzIHdpc2hpbmcgdG8gcHJvdmlkZSB0aGVpciBvd24gVFVSTiBzZXJ2ZXIsIGlu IGFuIGF0dGVtcHQgdG8gcmVkdWNlIHNvLWNhbGxlZCAmcXVvdDt0cmlhbmdsZSByb3V0aW5nJnF1 b3Q7LG5lZWQgYSBuZXcgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPkJ1dCBhbHNvOiAtIE5TUHMgKE5ldHdvcmsgU2VydmljZSBQcm92aWRlcnMpIHdh bnQgdG8gcHJvdmlkZSBhIHBhdGggd2hlcmUgdGhlIGJhbmR3aWR0aCBvZiBXZWJSVEMgaXMgYmV0 dGVyDQogY29wZWQgd2l0aC48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0gTlNQ cyBvciBFbnRlcnByaXNlcyB3YW50IHRvIG9mZmVyIGFuIEludGVybmV0IGFjY2VzcyBxdWFsaXR5 IHBpcGUgZm9yIHByaW9yaXRpemVkIFJUQyAoUmVhbCBUaW1lIENvbW11bmljYXRpb24pDQogdHJh ZmZpYy4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0gRW50ZXJwcmlzZXMgaGF2aW5nIHJl c3RyaWN0aXZlIGZpcmV3YWxscywgd2FudCB0byBwcm92aWRlIGEgVURQLXBhdGggZm9yIFdlYlJU QyBhbmQgcG9zc2libHkgYWxzbyBmb3INCiBiZXR0ZXIgcXVhbGl0eSB3aGVyZSBSVEMgZG8gbm90 IGNvbXBldGUgd2l0aCBkYXRhIHRyYWZmaWMuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPkFsc28gY29uc2lkZXJpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi Pi0gTW9iaWxpdHk7IEl0IGlzIGNvbW1vbiB0byBtb3ZlIGZyb20gYSBMQU4gdG8gYWNjZXNzaW5n IHZpYSBXaUZpIG9yIDNHLzRHIE9UVCBjaGFubmVscywgYWxsIHNob3VsZCBiZQ0KIGFibGUgdG8g YXV0b21hdGljYWxseSBvZmZlciB0aGVpciBvd24gb3B0aW1hbCBUVVJOIHNlcnZlcjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj5UaGlzIGxlYWRzIHVzIGludG8NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDvigJxUVVJO4oCmdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dz4oCdDQo8c3BhbiBz dHlsZT0iY29sb3I6Ymx1ZSI+ZXRjISBJdCBpcyBub3QgYSBtaXN0YWtlLCBidXQgdGhlIHZlcnkg bmVlZCBmb3IgdGhpcyBtaWxlc3RvbmUhPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWdhaW4sIGl0 IGhhcyBub3QgYmVlbiBkZW1vbnN0cmF0ZWQgd2h5IFRVUk4gaXMgdGhlIHJpZ2h0IHRlY2hub2xv Z3kgaGVyZSwgY29tcGFyZWQgdG8gYSBtb3JlIHRyYW5zcGFyZW50IGZsb3cgaWRlbnRpZmljYXRp b24gdG9vbCBsaWtlIE1BTElDRS4gV2UgZG9uJ3QgZm9yY2UgYWxsIEhUVFAgcmVxdWVzdHMNCiB0 byBsb2NhdGUgYSBIVFRQIHByb3h5IHZpYSBhbnljYXN0LCBJIGRvbid0IHNlZSB3aHkgd2UgbmVl ZCB0byBkbyB0aGUgc2FtZSBmb3IgV2ViUlRDLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5XaGF0IGFyZSB0 aGUgaGVzaXRhdGlvbnMgcmFpc2VkIGhlcmU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0 OyBUVVJOIHByaW1hcmlseSB0byBpZGVudGlmeSBXZWJSVEMgZmxvd3MsIGFzIG9wcG9zZWQgdG8g dXNpbmcgaXQgYXMgYSBOQVQgdHJhdmVyc2FsIHRvb2wuIFRoaXMgbWFrZXMgbWUgY29uY2VybmVk DQogdGhhdCB3ZSBtYXkgYmUgdXNpbmcgdGhlIHdyb25nIHRlY2hub2xvZ3kgdG8gc29sdmUgdGhl IHByb2JsZW08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JdCBpcyBjb3JyZWN0 IHRoYXQgSUNFL1NUVU4vVFVSTiB3YXMgZGVzaWduZWQgdG8gYWRkcmVzcyB0aGUgTkFUL0ZpcmV3 YWxsIHRyYXZlcnNhbCBwcm9ibGVtIGFzc29jaWF0ZWQNCiB3aXRoIHJlYWwtdGltZSBjb21tdW5p Y2F0aW9uIChTSVAgYXQgdGhhdCB0aW1lKS4gSG93ZXZlciwgaXRzIGxhcmdlc3QgZmxhdy9wcm9i bGVtIGlzIHRoYXQgcXVhbGl0eSB0aGluZ3Mgd2VyZSBub3QgKGNvdWxkIG5vdCBiZT8pIGNvbnNp ZGVyZWQuIFRoZSBtZXRob2TigJlzIHZlcnkgaWRlYSAobGlrZSBhbGwgc2ltaWxhciBtZXRob2Rz IGZvciBnZXR0aW5nIFJUQyB0aHJvdWdoIG9yZGluYXJ5IE5BVC9GaXJld2FsbHMpIGlzIHRvIGZv b2wgdGhlIG1lZGlhDQogdGhyb3VnaCBhIE5BVC9GaXJld2FsbCB0aGF0IGlzIHVuYXdhcmUgb2Yg d2hhdCBpcyBoYXBwZW5pbmcuIFRodXMsIHRoaXMgaXMgcm9vdCBvZiBxdWFsaXR5IGlzc3VlcyAo YW5kIGJhbmR3aWR0aCBhbGxvY2F0aW9uIG9wdGltaXphdGlvbikgdGhhdCBuZWVkcyB0byBiZSBk ZWFsdCB3aXRoOiBSZWFsLXRpbWUgdHJhZmZpYyBmaWdodGluZyB3aXRoIGEgZGF0YSB0cmFmZmlj IGNyb3dkZWQgY29uZ2VzdGlvbiBwb2ludC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkkgdGhpbmsgdGhhdCAmcXVvdDtmb29saW5nJnF1b3Q7IGlzIGFuIGluY29ycmVjdCBkZXNjcmlw dGlvbi4gVGhlIE5BVCBpcyBzdXBwb3NlZCB0byBiZSB0cmFuc3BhcmVudCB0byB0aGUgY2xpZW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj5CdXQsIGEgQkxFU1NJTkcgb2YgSUNFL1NUVU4vVFVSTiBpcyB0aGF0IGl0 IGNhbiBiZSBzZWVuIGFzIGEgbGVnaXRpbWF0ZSByZXF1ZXN0IGZvciBhIHN1aXRhYmxlIHBpcGUg Zm9yDQogcXVhbGl0eSBkZW1hbmRpbmcgcmVhbCB0aW1lIHRyYWZmaWMuIDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6Ymx1ZSI+ Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPg0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPklDRSBpcyBhIHByZS1wcm90b2NvbCB5b3UgdXNlIGJlY2F1c2Ug eW91IHdhbnQgYSBwYXRoIGZvciByZWFsLXRpbWUgbWVkaWEgYmV0d2VlbiBwYXJ0aWVzLiBIZXJl OiBUaGUgYnJvd3Nlcg0KIHNheXMga25vY2sga25vY2ssIEkgd2FudCB0byBnZXQgbWVkaWEgdGhy b3VnaCAoYW5kIG9mIGNvdXJzZSB3aXRoIGFzIGdvb2QgcXVhbGl0eSBhcyByZXF1aXJlZCBhbmQg cG9zc2libGUpLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibHVlIj5JZiB0aGUgTkFUL0ZpcmV3YWxsIG93bmVyIGFuZCBuZXR3b3JrIG93 bmVyIGFyZSBhbGxvd2VkIHRvIHNlZSB0aGVzZSByZXF1ZXN0cywgdGhleSBjYW4gaGVscC9hc3Np c3QgaW4NCiBhY2hpZXZpbmcgdGhlIGdvb2QgbWVkaWEgcGF0aC4gSWYgdGhleSBhcmUgbm90IGF3 YXJlLCB0aGV5IGNhbm5vdCBoZWxwITwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj5Ib3BlIHRoaXMgbWFkZSBpdCB1bmRlcnN0YW5kYWJsZSBvbiBhbiBvdmVydmlldyBs ZXZlbCBob3cgdGhpcyBjYW4gYmVjb21lPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPg0KIOKAnFRVUk7igKZ0byBpZGVudGlmeSBXZWJSVEMgZmxvd3PigJ08L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6Ymx1ZSI+SXQgaXMgYWxzbyB0aGUgT05MWSB3YXkgSSBjYW4gc2VlIHRvIGFjaGll dmUgd2hhdCB3ZSB3YW50IHRvIGFjaGlldmUgYW5kIHNob3VsZCBiZSB0aGUgYWltIGFuZCByZXF1 aXJlbWVudA0KIG9mIHRoaXMgbWlsZXN0b25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SSBhbSB0YWxraW5nIGFib3V0IGdlbmVy YWwgdXNhZ2Ugb2YgV2ViUlRDIG92ZXIgSW50ZXJuZXQvbW9iaWxlIE9UVCAobm90IGZlZWRpbmcg V2ViUlRDIGludG8gYXBwbGljYXRpb24NCiBzcGVjaWZpYyBuZXR3b3JrcyBsaWtlIElNUyB3aGVy ZSBvdGhlciBtZXRob2RzIG1heSBleGlzdCkuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhpcyBpcyBnb29kLCBub3QgZXZpbCE8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs dWUiPklmIHRoZSBoZXNpdGF0aW9ucyBhcmUgcmFpc2VkIGJlY2F1c2Ugb2YgYSBiZWxpZWYvaG9w ZS93aXNoIHRoYXQgdGhlcmUgYXJlIG5vIG9yIHdpbGwgbm90IGJlIHNldmVyZSBxdWFsaXR5DQog aXNzdWVzIOKAnGJlY2F1c2UgaXQgaXMgYWxsIGFib3V0IGJhbmR3aWR0aOKAnSwg4oCcaXQgd2ls bCByZXNvbHZlIGl0c2VsZiB3aXRoIHRpbWXigJ0gZXRjLiwgSSBzdHJvbmdseSBvYmplY3QhIFRo YXQgaXMgd3JvbmcgYW5kIHdpbGwgYmUgdmVyeSBkZXRyaW1lbnRhbCBmb3IgV2ViUlRDIHVzYWdl LiBXZSBhbHJlYWR5IHNlZSBpdCBhbmQgSSBjYW4gZ2l2ZSBudW1lcm91cyBleGFtcGxlcyBvZiBo b3cgbXVjaCBsZXNzIHF1YWxpdHkgZGVtYW5kaW5nIFZvSVANCiBpcy9pcyBub3QgaGFuZGxlZCBx dWFsaXR5IHdpc2UgYW5kIHRoYXQgaXQgbWF0dGVycy4gQW5kLCB3aGF0IHdvdWxkIGJlIGJhZCBj b25zaWRlcmluZyBxdWFsaXR5IGlzc3VlcyBhbmQgYWxsb3dpbmcvZW5jb3VyYWdpbmcgbWV0aG9k cyB0byBkZWFsIHdpdGggdGhlbT88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+SWYgdGhlIGhlc2l0YXRpb25zIGFyZSByYWlzZWQsIGJlY2F1c2Ugb2Ygc3VzcGljaW9u IHRoYXQgdGhlIG1ldGhvZHMgd2UgbWF5IHJlY29tbWVuZCBtYXkgYmUgbWlzdXNlZCB0bw0KIHN0 b3AvYmxvY2svZGVzdHJveSBXZWJSVEMgdXNhZ2UgKGUuZy4gdG8gcHJvdGVjdCBpbmNvbWUgZnJv bSBjYXJyaWVyIHRlbGVwaG9ueSB0cmFmZmljKSwgSSBjb3VsZCB1bmRlcnN0YW5kIGFuZCB3b3Vs ZCBmaWdodCB0aGUgc2FtZSBiYXR0bGUuIEJ1dCBob3BlZnVsbHksIHRob3NlIGRheXMgYXJlIChz b29uKSBvdmVyIOKAkyBBdCBsZWFzdCBmb3J3YXJkIHRoaW5raW5nIGNhcnJpZXLigJlzIHJlYWxp emUgdGhhdCBhbHJlYWR5LiBXZWIgUlRDIHdpbGwNCiBoYXBwZW4uIFdoaWNoIGN1c3RvbWVycyB3 YW50IHRvIHBheSBmb3IgYW4gYWNjZXNzIHdpdGggYmxvY2tlZCBXZWJSVEM/IFRoZSBjYXJyaWVy 4oCZcyBvZmZlcmluZy9hc3N1cmluZyBnb29kIFdlYlJUQyB3aWxsIHJhdGhlciBnZXQgdGhlIGN1 c3RvbWVycyBhbmQgaW5jb21lDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOmJsdWUiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj4uIChNYXliZSB0aGUgV2ViIGJyb3dzZXIgY2FuIGRldGVj dCBhbmQgZW5jb3VyYWdlIHRoaXPigKYpPC9zcGFuPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SWYgdGhlcmUgYXJlIHRlY2hu aWNhbCBjb25jZXJucyBvZiBiYWQgcmVzdWx0LCBvciBiZXR0ZXIgbWV0aG9kcyBhbGxvd2luZyBu ZXR3b3JrIHByb3ZpZGVycyBhbmQgTEFOIG1hbmFnZXJzDQogdG8gb2ZmZXIgYW5kIGluZm9ybSB0 aGUgYnJvd3NlciB0aGF0IHRoZXJlIGFyZSBnb29kIG1lZGlhIHBhdGhzIHRvIGJlIHVzZWQsIGFu ZCB0aGF0IHRoZSB3ZWIgYnJvd3NlciBhdXRvbWF0aWNhbGx5IGNhbiBjaG9zZSB0aG9zZSwgdGhl biBsZXQgdXMgYWxsIHVuZGVyc3RhbmQgdGhvc2UsIHNvIHdlIGNhbiBhY2hpZXZlIHdoYXQgc2hv dWxkIGJlIGFjaGlldmVkIGJ5IHRoaXMgbWlsZXN0b25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+U2t5cGUsIEhhbmdvdXRzLCBGYWNldGltZSBhcmUgZG9pbmcgYmlsbGlvbnMgb2Yg bWludXRlcyBwZXIgd2VlayBhbmQgdGhlIEludGVybmV0IGhhcyBub3QgbWVsdGVkIHlldC4gSWYg d2UgbmVlZCB0byBkbyBmbG93IGlkZW50aWZpY2F0aW9uIHRvIGFsbG93IHRyYWZmaWMgdG8gYmUg cHJpb3JpdGl6ZWQsIGZpbmUNCiAoc2VlIGFib3ZlIHJlZ2FyZGluZyBteSBwcmVmZXJyZWQgYXBw cm9hY2gpLCBidXQgZm9yY2luZyBhbGwgV2ViUlRDIHRyYWZmaWMgdGhyb3VnaCBhIE1JVE0gKFRV Uk4gc2VydmVyKSBpcyBhIG11Y2ggYmlnZ2VyIGp1bXAgdGhhdCBJIGRvbid0IHlldCBzZWUgdGhl IGp1c3RpZmljYXRpb24gZm9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gc2hvcnQ6IFRVUk4gaXMgYSB0ZWNobm9sb2d5IHRoYXQg aXMgc3VwcG9zZWQgdG8gZmFkZSBhd2F5IHdpdGggdGhlIG1vdmUgdG8gSVB2Ni4gSSBkb24ndCB0 aGluayB3ZSB3YW50IHRvIG1ha2UgaXQgYSBjcml0aWNhbCBlbGVtZW50IG9mIFdlYlJUQy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6Ymx1ZSI+L0thcmw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5GcsOlbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gRGFuIFdpbmcgW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmR3aW5n QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5k d2luZ0BjaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8 YnI+DQo8Yj5Ta2lja2F0OjwvYj4gZGVuIDExIGZlYnJ1YXJpIDIwMTQgMTg6MjU8YnI+DQo8Yj5U aWxsOjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+TWFy YyBCbGFuY2hldDxicj4NCjxiPktvcGlhOjwvYj4gSnVzdGluIFViZXJ0aTsgPC9zcGFuPjxhIGhy ZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5n PSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRpcmVkZHlAaWNpc2NvLmNvbTwvc3Bhbj48L2E+ PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47DQogS2FybCBTdGFobDsgPC9z cGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgU2ltb24gUGVycmVhdWx0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IlNWIj48YnI+DQo8Yj7DhG1uZTo8L2I+IFJlOiBbdHJhbV0gTWlsZXN0b25l IDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBh bmQgSVNQczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNW Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPk9uIEZlYiAxMSwgMjAxNCwg YXQgOTowOCBBTSwgTWFyYyBCbGFuY2hldCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYXJj LmJsYW5jaGV0QHZpYWdlbmllLmNhIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiPm1h cmMuYmxhbmNoZXRAdmlhZ2VuaWUuY2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIj4mZ3Q7DQog d3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxz cGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+TGUgMjAxNC0wMi0xMSDDoCAwMDozOSwg RGFuIFdpbmcgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZHdpbmdAY2lzY28uY29tIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiPmR3aW5nQGNpc2NvLmNvbTwvc3Bhbj48L2E+PHNw YW4gbGFuZz0iU1YiPiZndDsgYSDDqWNyaXQgOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCk9uIEZlYiAxMCwgMjAxNCwgYXQgNToz MCBQTSwgSnVzdGluIFViZXJ0aSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpqdWJlcnRpQGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+anViZXJ0aUBnb29nbGUuY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0Ow0KIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkdvb2QgdG8gc2VlIHRoZXJlIGlzIGEgbG90IG9m IGludGVyZXN0IGZvciB0aGlzIG1pbGVzdG9uZS4gQnV0IGJhc2VkIG9uIHRoZSBkZXNjcmlwdGlv biBoZXJlLCBpdCBzZWVtcw0KIGxpa2Ugd2Ugd2FudCB0byB1c2UgVFVSTiBwcmltYXJpbHkgdG8g aWRlbnRpZnkgV2ViUlRDIGZsb3dzLCBhcyBvcHBvc2VkIHRvIHVzaW5nIGl0IGFzIGEgTkFUIHRy YXZlcnNhbCB0b29sLiBUaGlzIG1ha2VzIG1lIGNvbmNlcm5lZCB0aGF0IHdlIG1heSBiZSB1c2lu ZyB0aGUgd3JvbmcgdGVjaG5vbG9neSB0byBzb2x2ZSB0aGUgcHJvYmxlbS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mIzQzOzEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+SSB3b3VsZCBwcmVmZXIgYWxsb3dpbmcgZmxvd3MgdG8gZXN0YWJsaXNo IHRoZW1zZWx2ZXMgdXNpbmcgdGhlaXIgJ2Jlc3QnIHBhdGgsIGFuZCB0aGUgYmVzdCBwYXRoIGlz DQogc2VsZG9tIHRocm91Z2ggYSBUVVJOIHNlcnZlci4gJm5ic3A7V2hlbiB3ZSBpbWFnaW5lIElQ djYgaW4gb3VyIGZ1dHVyZSwgd2UgZG9uJ3Qgd2FudCB0byBmb3JjZSBhbiBhcHBsaWNhdGlvbi1s ZXZlbCBwcm94eSAoVFVSTikgc2VydmVyIG9uIHRoZSBwYXRoIHNvbGVseSBmb3IgdHJhdmVyc2lu ZyBhbiBJUHY2IGZpcmV3YWxsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkl0IHNl ZW1zIHRoaXMgdGhyZWFkIGlzIGNvbmZsYXRpbmcgYWxsIHRoZSBwb3NzaWJsZSByZWFzb25zIC8g anVzdGlmaWNhdGlvbnMgZm9yIFRVUk46PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7ICogbW9iaWxpdHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDsgKiBOQVQgdHJhdmVyc2FsIChib3RoIGVuZHBvaW50cyBh cmUgYmVoaW5kIGVuZHBvaW50LWRlcGVuZGVudCBtYXBwaW5nIE5BVHMpPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7ICombmJzcDtmaXJld2FsbCB0cmF2 ZXJzYWwgKGZpcmV3YWxsIGJsb2NrcyBVRFApPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7ICogZW5oYW5jaW5nIHByaXZhY3k8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5VbmZvcnR1bmF0ZWx5IHRoZSBUVVJOIHNlcnZlciBub3Ig dGhlIGVuZHBvaW50IHJlYWxseSBrbm93IHdoaWNoIG9mIHRob3NlIHVzZS1jYXNlcyBpcyBkZXNp cmVkIChieSB0aGUNCiB1c2VyIG9yIGJ5IHRoZSBJVCBuZXR3b3JrIGFkbWluaXN0cmF0b3IpIG9y IG5lY2Vzc2FyeSAoZm9yIHRoZSBjYWxsIHRvIHdvcmsgYXQgYWxsKS4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+RGFuLCB3aGlsZSBJIGFn cmVlIGluIHByaW5jaXBsZSwgSSBkb3VidCB0aGF0IGEgdXNlciBjb3VsZCBldmVyIHNheSAmcXVv dDtJIHdhbnQgbW9iaWxpdHkgb3IgSSB3YW50IE5BVCB0cmF2ZXJzYWwmcXVvdDsuIEkgdGhpbmsg dGhlIHVzZXIgb25seSB3YW50IHRoZSBjYWxsIHRvIHN1Y2NlZWQsIHdoYXRldmVyDQogdGhlIHBy b3BlcnRpZXMgb2YgaXRzIG5ldHdvcmsgcG9pbnQgb2YgYXR0YWNobWVudCBhcmUuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPlNv IHdoYXQgY2FuIHdlIGRvPyAmbmJzcDtTaG91bGQgdGhlIFRVUk4gc2VydmVyIHByb3ZpZGUgYW55 IGFuZCBhbGwgc2VydmljZXMgdGhlIFRVUk4gY2xpZW50IG1pZ2h0IHBvc3NpYmx5IHdhbnQsIGFz IHRoYXQgaXMgd2hhdCBhIHJvYnVzdCBUVVJOIHNlcnZlciB3aWxsIGRvLCBhbmQgdGhlDQogZW5k cG9pbnQgc2hvdWxkIHByZWZlciBUVVJOIGNhbmRpZGF0ZXMgb3ZlciBhbGwgb3RoZXJzIGJlY2F1 c2UgdGhlcmUgbWlnaHQgYmUgc29tZSBmdW5jdGlvbmFsaXR5IC8gdXNlZnVsbmVzcyBvZiBUVVJO IHRoYXQgdGhlIHVzZXIgbWlnaHQgZ2FpbiB0aHJvdWdoIFRVUk4gKGUuZy4sIGVuaGFuY2VkIHBy aXZhY3kpPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPi1k PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDtUaGlzIHNlZW1zIHByb2JsZW1hdGljLiAmbmJzcDtQZXJoYXBz IHdlIG5lZWQgYSB3YXkgdG8gc2lnbmFsIHRoZSBkZXNpcmVkIHVzZS1jYXNlICgmcXVvdDt0cmFp dCZxdW90OyksIG9yIGFzIEp1c3Rpbg0KIHN1Z2dlc3RzLCB1c2luZyBhIGRpZmZlcmVudCB0ZWNo bm9sb2d5IGZvciBzb21lIG9mIHRoZXNlIHVzZS1jYXNlcy48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4tZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiBNb24sIEZlYiAxMCwgMjAx NCBhdCAzOjE4IFBNLCBLYXJsIFN0YWhsJm5ic3A7Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86 a2FybC5zdGFobEBpbnRlcnRleC5zZSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5rYXJsLnN0YWhsQGludGVydGV4LnNlPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyZuYnNwO3dyb3RlOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlNpbW9uLDxicj4NCjxicj4NCkdvb2QgcXVlc3Rp b25zIC0gc2VlIGlubGluZSBiZWxvdyAtLSZndDsgLjxicj4NClNvbWUgbW9yZSB0aG91Z2h0IGlz IHJlcXVpcmVkITxicj4NCjxicj4NCi9LYXJsPGJyPg0KPGJyPg0KLS0tLS1VcnNwcnVuZ2xpZ3Qg bWVkZGVsYW5kZS0tLS0tPGJyPg0KRnLDpW46IHRyYW0gW21haWx0bzo8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+ PC9hPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQogRsO2ciBTaW1v biBQZXJyZWF1bHQ8YnI+DQpTa2lja2F0OiBkZW4gMTAgZmVicnVhcmkgMjAxNCAxNToxNjxicj4N ClRpbGw6IEthcmwgU3RhaGw7Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij47Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGljaXNjby5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+dGlyZWRkeUBpY2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PGJyPg0Kw4RtbmU6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4g c2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQczwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpLYXJsLDxicj4NCjxicj4NCkl0IGlz IGdyZWF0IHRvIHNlZSBzdWNoIGVudGh1c2lhc20hIFRoYW5rcyE8YnI+DQo8YnI+DQpJIGhhdmUg YSBjb3VwbGUgdGVjaG5pY2FsIHF1ZXN0aW9ucy4uLjxicj4NCjxicj4NCkxlIDIwMTQtMDItMDgg MDg6MTEsIEthcmwgU3RhaGwgYSDDqWNyaXQgOjxicj4NCiZndDsgLSBOb3RlIHRoYXQgdG8gYWNo aWV2ZSBzb21lIG9mIHRoZSBhYm92ZSBwb2ludHMsIFRVUk4gbXVzdCBiZSBmYXZvcmVkPGJyPg0K Jmd0OyBvdmVyIFNUVU4gdG8gZW5mb3JjZSB0aGF0IHRoZSBUVVJOLXBhdGggYWN0dWFsbHkgaXMg dXNlZC4gKFRoZSBBbnljYXN0PGJyPg0KJmd0OyBtZXRob2Qgc3VnZ2VzdGVkIGJlbG93LCDigJxh dXRvbWF0aWNhbGx54oCdIGRvZXMgdGhpcy4pPGJyPg0KPGJyPg0KSSB1bmRlcnN0YW5kIHRoZSBT VFVOIHZzIFRVUk4gcHJpb3JpdHkgaXNzdWUuIEJ1dCBJIGRvbid0IHNlZSBob3cgYW55Y2FzdCBh ZmZlY3RzIGl0IGluIGFueSB3YXkuIENhbiB5b3UgcGxlYXNlIGV4cGxhaW4/PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLS0gR29vZCBwb2ludCAtIEkgd2FzIGEgYml0IHF1 aWNrIGhlcmUgKG1heWJlIHRvbyBxdWljayk8YnI+DQpXZSBoYXZlIGdpdmVuIHRoaXMgcXVpdGUg Yml0IG9mIHRob3VnaHQsIHNpbmNlIGV2ZW4gaWYgYSBUVVJOIHNlcnZlciBpcyBwcm92aWRlZCBh bmQgZGlzY292ZXJlZCwgQ1VSUkVOVCB1c2FnZSBvZiBJQ0UgbWF5IHN1Z2dlc3QgYSBjYW5kaWRh dGUgZnJvbSB0aGUgcmVtb3RlIHBhcnR5IHRoYXQgd2lsbCBtYWtlIGEgY29ubmVjdGlvbiB3aXRo b3V0IHRoZSBuZWVkL3VzYWdlIG9mIHRoZSBUVVJOIHNlcnZlciAodGhhdCB3ZSB3YW50ZWQgdG8g YmUgdXNlZA0KIGZvciB0aGUgZ29vZCBwdXJwb3NlcyBsaXN0ZWQpLjxicj4NCjxicj4NClRoZSBv bmx5IHdheSB3ZSBmb3VuZCBhcm91bmQgdGhpcywgd2FzIHRvIHN0b3AgU1RVTiB0aHJvdWdoIHRo ZSBJUCBkZWZhdWx0IGdhdGV3YXkgKGxpa2UgYSByZXN0cmljdGl2ZSBFbnRlcnByaXNlIGZpcmV3 YWxsIGRvZXMgaW5oaWJpdGluZyBJQ0UgY29ubmVjdGl2aXR5LCB3aGljaCBvdGhlcnMgYXJlIGNv bmNlcm5lZCBhYm91dC4uLikuIFNpbmNlIHRoZSBwcm92aXNpb25pbmcgb2YgYXV0by1kaXNjb3Zl cnkgdXNpbmcgdGhlIGFueWNhc3QgbWVjaGFuaXNtLA0KIHdvdWxkIGJlIGFkZGluZyBhIHJvdXRl IGluIGEgZGVmYXVsdCBnYXRld2F5LCBhZGRpbmcgYSBmaXJld2FsbCBydWxlIHRvIGVhdCBTVFVO IHBhY2tldHMgd291bGQgYXNzdXJlIHRoYXQgdGhlIHByb3Zpc2lvbmVkIFRVUk4gc2VydmVyIGFj dHVhbGx5IGJlY29tZXMgdXNlZCAoYW5kIG5vdCBieXBhc3NlZCAmcXVvdDtieSBhY2NpZGVudCZx dW90OykuIChUaGF0IHdhcyB0aGUgdGhvdWdodCBiZWhpbmQgdGhlIOKAnGF1dG9tYXRpY2FsbHni gJ0gd2l0aGluIHF1b3Rlcy4pPGJyPg0KPGJyPg0KQlVULCBzaW5jZSB5b3UgYnJvdWdodCB1cCB0 aGUgcXVlc3Rpb24sIGFzc3VtaW5nIHRoYXQgd2UgaGF2ZSB0aGUgcG93ZXIgdG8gZW5mb3JjZSBX ZWJSVEMgdXNhZ2Ugb2YgSUNFLCBJIGJlbGlldmUgYSBNVVNUIHJlcXVpcmVtZW50IHRvIHVzZSBh biBhdXRvLWRpc2NvdmVyZWQgVFVSTiBzZXJ2ZXIgaW5zdGVhZCBvZiBTVFVOLCB3b3VsZCBzb2x2 ZSB0aGUgc2FtZSBwcm9ibGVtLiBIb3dldmVyLCB0aGlua2luZyBmdXJ0aGVyIChpbiByZWxhdGlv bg0KIHRvIHlvdXIgbmV4dCBxdWVzdGlvbiAtICZxdW90O2FueW9uZSBjb3VsZCBzZXQgdXAgYSBi YWRseS1tYWludGFpbmVkJnF1b3Q7IC0gZW5mb3JjaW5nIHN1Y2ggSUNFIHVzYWdlIG1heSBub3Qg YmUgZ29vZC4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCiZndDsg LSAzXnJkIFRoZSBBbnljYXN0IG1ldGhvZCBiZWxvdyDigJMgSSBzZWUgbm8gcHJvYmxlbTxicj4N CiZndDs8YnI+DQomZ3Q7IEl0IGFsc28gaGFzIHRoZSBhZHZhbnRhZ2Ugb2YgZW5jb3VyYWdpbmcg KGJ1dCBub3QgcmVxdWlyaW5nKSB0aGU8YnI+DQomZ3Q7IFNUVU4vVFVSTiB0byBiZSBidWlsdCBp biB0aGUgZGVmYXVsdCBnYXRld2F5IG9yIE5BVC9maXJld2FsbC9hY2Nlc3M8YnI+DQomZ3Q7IHJv dXRlciBpdHNlbGYsIHdpdGggYSBzZWNvbmQgaW50ZXJmYWNlIHRvIGEgcHVibGljIElQIGFkZHJl c3Mgb24gdGhlPGJyPg0KJmd0OyBXQU4gc2lkZS4gKEN1cnJlbnQgdm9sdW1lIGRlcGxveWVkLCBs b3cgY29zdCBOU1AgdHJpcGxlIHBsYXkgbW9kZW1zPGJyPg0KJmd0OyB1c3VhbGx5IGhhdmUgYSBx dWFsaXR5IGFzc3VyZWQgbGV2ZWwgMiBvciBsZXZlbCAzIFdBTiBwaXBlIGZvciBqdXN0PGJyPg0K Jmd0OyB2b2ljZSAoYW5kIGFub3RoZXIgZm9yIElQVFYpIOKAkyBUaGUgYW55Y2FzdCBkaXNjb3Zl cmVkIFRVUk4tc2VydmVyIGNhbjxicj4NCiZndDsgYmUgdGhlIGFjY2VzcyBnYXRld2F5IHRvIHN1 Y2ggcXVhbGl0eSBwaXBlIGZvciBXZWJSVEMgbWVkaWEsIGluIGE8YnI+DQomZ3Q7IHNpbmdsZSBO U1AgcHJvdmlkZWQgQ1BFLCBzY2FsaW5nIGZyb20gcmVzaWRlbnRpYWwgYW5kIHVwLik8YnI+DQo8 YnI+DQpTdXBwb3NlIHdlIGRlZmluZSB3ZWxsLWtub3duIGFueWNhc3QgVFVSTiBzZXJ2ZXIgYWRk cmVzc2VzLiBIb3cgd291bGQgdGhpcyBub3QgYmUgc3ViamVjdCB0byB0aGUgc2FtZSBzZXJ2aWNl IHF1YWxpdHkgaXNzdWVzIHRoYXQgcGxhZ3VlZCA2dG80PyBUaGF0IGlzLCBhbnlvbmUgY291bGQg c2V0IHVwIGEgYmFkbHktbWFpbnRhaW5lZCwgdW5kZXItcHJvdmlzaW9uZWQgVFVSTiBzZXJ2ZXIg YW5kIGFubm91bmNlIGl0IG92ZXIgQkdQIHRvIHRoZSB3b3JsZCwNCiBhcyBpdCB3YXMgZG9uZSBm b3I8YnI+DQo2dG80IHJlbGF5cy4gT3IganVzdCBiYWQgQkdQIG91dGJvdW5kIGZpbHRlciBjb25m aWd1cmF0aW9uLiBBbmQgaG93IGNhbiB3ZSBwcmV2ZW50IHRyaWFuZ2xlIHJvdXRpbmc/IFRoZXJl IGlzIG5vdGhpbmcgZ3VhcmFudGVlaW5nIHRoYXQgdGhlIGFueWNhc3Qgc2VydmVyIHlvdSBzZWUg aXMgYmVpbmcgcHJvdmlkZWQgdG8geW91IGJ5IHlvdXIgSVNQLCByYXRoZXIgdGhhbiBhIHNlcnZl ciBzaXR0aW5nIG9uIHRoZSBvdGhlciBzaWRlIG9mIHRoZSBwbGFuZXQuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLS0gR29vZCBwb2ludCAtIG5lZWRzIHRvIGJlIHJlc29s dmVkLiBGb3IgdGhpcyBJIGRvbid0IGhhdmUgYSByZWFkeSBhbnN3ZXIuLi48YnI+DQpBbiBhdXRv LWRpc2NvdmVyZWQgVFVSTiBzZXJ2ZXIgbXVzdCBiZSB0cnVzdGVkICh3aGF0ZXZlciBtZXRob2Qg aXQgaXMgZGlzY292ZXJlZCBieSkuIFdlIGFyZSB0cnVzdGluZyB0aGUgb25lIHByb3ZpZGluZyB1 cyB3aXRoIGFuIElQIGFkZHJlc3MgYW5kIGRlZmF1bHQgZ2F0ZXdheSBhbnl3YXkuIEl0IHdvdWxk IGJlIGVhc3kgaWYgd2UgY291bGQgcmV1c2UgdGhhdCB0cnVzdCwgaW5zdGVhZCBvZiBhbm90aGVy IG1lY2hhbmlzbXMuPGJyPg0KPGJyPg0KSXMgdGhlcmUgYSBnb29kIHdheSBmb3IgdGhlIGJyb3dz ZXIgdG8gY2hlY2sgdGhhdCB0aGUgYW55Y2FzdCBhZGRyZXNzIGlzIG5vdCBoYW5kbGVkIGJleW9u ZCB0aGUgbmV0d29yayBzZXJ2aWNlIHByb3ZpZGVyJ3MgZGVmYXVsdCBnYXRld2F5PyBJZGVhcz88 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCjxi cj4NClRoYW5rcyw8YnI+DQpTaW1vbjxicj4NCi0tPGJyPg0KRFROIG1hZGUgZWFzeSwgbGVhbiwg YW5kIHNtYXJ0IC0tJmd0OyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vcG9zdGVsbGF0aW9u LnZpYWdlbmllLmNhLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5odHRwOi8vcG9zdGVsbGF0aW9uLnZpYWdlbmllLmNhPC9zcGFuPjwvYT48 c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KTkFUNjQvRE5TNjQg b3Blbi1zb3VyY2UgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LS0mZ3Q7Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Imh0dHA6Ly9lY2R5c2lzLnZpYWdlbmllLmNhLyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwOi8vZWNkeXNpcy52aWFn ZW5pZS5jYTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pjxicj4NClNUVU4vVFVSTiBzZXJ2ZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IC0tJmd0OyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vbnVtYi52 aWFnZW5pZS5jYS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+aHR0cDovL251bWIudmlhZ2VuaWUuY2E8L3NwYW4+PC9hPjxzcGFuIGxhbmc9 IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPC9z cGFuPjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g bGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i U1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+ DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bh bj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJT ViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBo cmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0 bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFu Zz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdHJhbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRy YW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj50cmFtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A242AF2D6xmbrcdx10ciscoc_-- From nobody Mon Feb 17 03:10:37 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4C71A0481 for ; Mon, 17 Feb 2014 03:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 eS_22kReiqal for ; Mon, 17 Feb 2014 03:10:33 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF491A0489 for ; Mon, 17 Feb 2014 03:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7272; q=dns/txt; s=iport; t=1392635430; x=1393845030; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=D7Y2a3ZRXPcsM0JD0AAxKUEE4X1fJ8aAcIXLw+GC4gk=; b=EY2UuWjT850XCf34qieRjF/zQUqSFjQULbrulfGMN9qe63k48Y9Hs0ko i64GoHs5dEFlHN0cWFo/gtvH6e7l9yt8u4WLIHTotWCyDeEf5oHmcISsy Ylcl0seZeGMO8Y036pzIpq/yU7aztjPpmSMQGZ29BLvQS7BmLSJ7lsh4s Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAJLtAVOtJV2b/2dsb2JhbABZgwY4V780gR4WdIIlAQEBBAEBAWsJAgwGAQgOAwQBAQsdKAYLFAgBCQEEDgUIAYdoAxENwx4NiA8XjGeBQwYBAR4LJgILgx6BFASJEI0wgx6LLIVFgW+BPoFpAQcXBhw X-IronPort-AV: E=Sophos;i="4.95,859,1384300800"; d="scan'208";a="20995198" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 17 Feb 2014 11:10:26 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1HBAPW5000857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 11:10:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 05:10:25 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt Thread-Index: Ac8r0NgRqrA6RMrjS1qsrfIex+lw1w== Date: Mon, 17 Feb 2014 11:10:24 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242AF33F@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.107] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/VC0gXg4l8L2B8-7dJVp1xpWQdWo Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 11:10:36 -0000 Hi Oleg, Thanks for the review. Please see inline [TR] From: Oleg Moskalenko [mailto:mom040267@gmail.com]=20 Sent: Sunday, February 16, 2014 10:31 AM To: Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-= third-party-authz-00.txt Hi Tiru I have some comments: 1) Section 4. Obtaining a Token Using OAuth, figure 4 I believe that the sequence of messages is incorrect. The TURN server most = probably will contact the Authorization server AFTER it gets the Allocate r= equest. But on the figure 4, it looks like it somehow can predict the incom= ing request. The correct sequence must be, in the general case: =A0=A0 Access Token Request (1) from client to Auth server =A0=A0 Access Token + Session Key (2) from Auth server to client =A0=A0 Allocate request from client to TURN server (3) =A0=A0 Get Token from TURN Server to Auth server (4) =A0=A0 Token metadata from Auth Server to TURN server (5) =A0=A0 Allocate response from TURN server to the client (6) [TR] Good catch, fixed it. It got messed when we were changing from self-co= ntained to handle token. =20 The sequence shown on the figure 4 is possible only is the Auth Server and = TURN server are somehow closely integrated and that is unnecessary. [TR] Yes, the AS and TURN server have to be integrated. There may be ways t= o standardize this, but this is not in the scope of this doc right away. 2) The document is saying that the client when communicating to the Auth Se= rver uses HTTP requests with JSON (REST API ?). May be it would be helpful = if the communication protocol between TURN server and Auth server would be = mentioned, too. [TR] Drafts in OAuth WG like https://tools.ietf.org/html/draft-richer-oauth= -introspection-04 discuss the communication mechanism b/w Resource Server a= nd Authorization server. You may also want to look into http://www.ietf.or= g/mail-archive/web/oauth/current/msg08607.html which discusses such communi= cation mechanism already implemented but for a different purpose. I guess i= t all worked because Resource server and Authorization server are developed= by the same company but with this use case we may have to discuss if stand= ardization is required for the communication mechanism. 3) Section 7.2: OAuth does not impose any limitation on the length of the access token b= ut since STUN messages cannot exceed 548 bytes (Section 7.1 of [RFC5389]), access token length needs to be restricted to fit within the maximum STUN message size. I am not sure that the STUN (Binding ?) max message size is relevant here a= nd worth mentioning at all - because this doc is about TURN, and the TURN m= essages are often much larger than 548 bytes (especially when carrying the = video traffic). So I see no relevance of the 548 limit to the new authentic= ation standard. And that limitation of 548 bytes is applicable only to the = cases when we suspect that the path MTU is really really low and that is an= extremely rare case. [TR] Good point. But RFC 5766 recommends to restrict the size (Section 2.7 = Avoiding Fragmentation) As a guideline, sending a maximum of 500 bytes of application data in a single TURN message (by the client on the client-to-server leg) or a UDP datagram (by the peer on the peer-to-server leg) will generally avoid IP fragmentation. 4) Are we sure that we want to limit the OAuth applicability only to the lo= ng-term credentials mechanism ? I see no technical or philosophical reasons= why not to use it for short-term credentials mechanism, too. It would be a= more "symmetric" approach. [TR] what is the use case for short-term credential mechanism with TURN ? 5) I'd put more definite wording how TURN server handles the token lifetime= . What happens in the middle of the TURN session, is the auth token expires= while the session is still active ? There may be two possible cases: =A0=A0 - the token lifetime is applicable only to the session initiation pr= ocedure. When the TURN session has been already established, it can go inde= finitely while the client is refreshing the session properly. =A0=A0 - in second case when the token expires, the server rejects new requ= ests from the client (in the same TURN session) until the client sends the = new token data in re-authentication exchange. I'd suggest the first case as an eisier case for the implementation. [TR] The client MUST obtain a new token after the previously used one expir= es. As you point out an already established TURN session can continue, the = new token is applicable for new requests. If the client uses the token aft= er its lifetime then the TURN server MUST return error that the token is in= valid which is in line with the steps defined in http://tools.ietf.org/html= /rfc6749#section-1.5=20 We will update these details next revision. Cheers, -Tiru. Regards, Oleg On Fri, Feb 14, 2014 at 6:41 PM, Tirumaleswar Reddy (tireddy) wrote: This document proposes the use of third party authorization using OAuth for= TURN. Comments and suggestions are welcome. -Tiru -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Friday, February 14, 2014 1:59 PM To: Ram Mohan R (rmohanr); Prashanth Patil (praspati); Tirumaleswar Reddy (= tireddy); Prashanth Patil (praspati); Justin Uberti; Justin Uberti; Tirumal= eswar Reddy (tireddy); Ram Mohan R (rmohanr) Subject: New Version Notification for draft-reddy-tram-turn-third-party-aut= hz-00.txt A new version of I-D, draft-reddy-tram-turn-third-party-authz-00.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IET= F repository. Name: =A0 =A0 =A0 =A0 =A0 draft-reddy-tram-turn-third-party-authz Revision: =A0 =A0 =A0 00 Title: =A0 =A0 =A0 =A0 =A0TURN Extension for Third Party Authorization Document date: =A02014-02-14 Group: =A0 =A0 =A0 =A0 =A0Individual Submission Pages: =A0 =A0 =A0 =A0 =A011 URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/internet-drafts/draft-reddy= -tram-turn-third-party-authz-00.txt Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/doc/draft-reddy-tram-t= urn-third-party-authz/ Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-reddy-tram-turn-thir= d-party-authz-00 Abstract: =A0 =A0This document proposes the use of OAuth to obtain and validate =A0 =A0ephemeral tokens that can be used for TURN authentication. =A0The us= age =A0 =A0of ephemeral tokens ensure that access to a TURN server can be =A0 =A0controlled even if the tokens are compromised, as is the case in =A0 =A0WebRTC where TURN credentials must be specified in Javascript. =A0It =A0 =A0also addresses the need for stronger authentication described in =A0 =A0[I-D.reddy-behave-turn-auth]. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Mon Feb 17 03:51:53 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8212F1A047A for ; Mon, 17 Feb 2014 03:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MSGID_MULTIPLE_AT=1] autolearn=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 x94SfJz9gx2j for ; Mon, 17 Feb 2014 03:51:48 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id E5EF91A0493 for ; Mon, 17 Feb 2014 03:51:44 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402171251392493; Mon, 17 Feb 2014 12:51:39 +0100 From: "Karl Stahl" To: "'Pal Martinsen \(palmarti\)'" , References: <9F33F40F6F2CD847824537F3C4E37DDF17CC3AFB@MCHP04MSX.global-ad.net> <52F8DF21.2080303@viagenie.ca> <52f95e41.89fb420a.24a8.5a07SMTPIN_ADDED_BROKEN@mx.google.com> <41A536B1-DDCC-4D6A-9764-6842CB4187E6@cisco.com> <283E6481-73BB-48CA-8BD7-8B4903C8A450@viagenie.ca> <93531CB5-C41D-4FA2-9972-2AF195A30572@cisco.com> <52faa614.0602980a.0752.7852SMTPIN_ADDED_BROKEN@mx.google.com> <9F33F40F6F2CD847824537F3C4E37DDF17CF2EDD@MCHP04MSX.global-ad.net> <913383AAA69FF945B8F946018B75898A242AD1F4@xmb-rcd-x10.cisco.com> <52FCD3E3.5060301@viagenie.ca> <54984825-37D2-4C21-A0CF-F03C6D30162D@cisco. com> In-Reply-To: <54984825-37D2-4C21-A0CF-F03C6D30162D@cisco.com> Date: Mon, 17 Feb 2014 12:51:39 +0100 Message-ID: <03c401cf2bd6$9e5e9c70$db1bd550$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPJ7mlTNEKdEV/S06oVknK3f+v9pqxnjCAgAABbgCAAB7xgIAAizSAgAAdCoCAAIjhgIAAsgGAgAAGhYCABacXgA== Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/6gIY-3jerW0F8DRWyvKcdEfuOE8 Cc: 'Simon Perreault' Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 11:51:51 -0000 Interesting thoughts, inline comments below --> -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Pal Martinsen = (palmarti) Skickat: den 13 februari 2014 15:40 Till: tram@ietf.org Kopia: Simon Perreault =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs On 13 Feb 2014, at 15:17 pm, Simon Perreault = wrote: > Le 2014-02-12 22:40, Tirumaleswar Reddy (tireddy) a =E9crit : >> There are other ways to solve the problem for example using PCP. >=20 > True. >=20 >> Can you clarify how deploying a TURN server in the Enterprise=20 >> protects the users and the network ? >=20 > IMHO that's not the right question to ask. It is pretty clear to me=20 > that, technically, TURN does indeed have the potential to solve the=20 > problem identified by Karl. (I understand the problem to be: "ISP=20 > wants to provide enhanced QoS to WebRTC.") >=20 > I have two questions in my mind: >=20 > a) Is this a real problem that is worth fixing? Yes.. But not just QoS. There should be some kind fairness and =93share = the resources=94 so everyone can get the best result. If the link is getting crowed it would be nice of the endpoint than can would for example = reduce its bandwidth by dropping from 1080p to 720p. Tis have some impact on = user experience, but uses half the bandwidth.=20 [Karl] Have you noticed that Google does this in Chrome/VP8 already? = When getting bad network conditions (you see disturbances in the video), the video screen shrinks to reduce bandwidth usage. That is "some kind = fairness and share the resources" intent, but unfortunately not very effective, = since the bandwidth reduction in practice is given back to TCP (non-real time traffic) streams filling the pipe. That is the way TCP (data) vs. UDP (media) today share the Internet pipes (UDP makes TCP streams reduce = their bandwidth usage at congestion time - and that is also reversed when = reducing UDP) by backing off TCP. That is why we need to be able to apply = "traffic shaping" at lower network levels.=20 I would like us to move away from hard reservations as that does not = give us the best usage of a scarce resource (bandwidth) as video codecs are very elastic in its nature and it would be hard to know how much bandwidth to allocate for a video stream.=20 [Karl] True! But i might be dreaming. [Karl] Are you? :) I will comment further/elsewhere on the DISCUSS/MALICE draft, which I = see related to this > b) Is TURN the best, most appropriate solution? >=20 Probably a part of the solution, It is a nice way of =93forcing=94 media = through a certain path. But I think that path only should be chosen by the = endpoint if that is the best(*1) path. (*1) For certain values of best.. [Karl] Agree, but the path to be chosen by the endpoint, can only be advised/offered by the ISP/NSP if it is within their network the quality fixes have to be done. I have been planning to write a draft: POLICE, Path Optimisation done Locally with ICE. But that probably belongs to MMUSIC. But to get that = of the ground we need to figure out how to get more information from the network regarding bandwidth, cost and other decisions that might = influence the path selection. (RTT we get from the connectivity checks). That = would be something for the TRAM WG to figure out.. (And maybe the PCP WG) [Karl] Yes, and I see DISCUSS/MALICE (that has been mentioned by Justin = and others here) as one step to do this. Another thing to remember is that webRTC is probably going to use Trickle-ICE. In clear that means the host candidates will be tested as = soon as they are ready. The rest of the candidate discovery might happen in parallel or after. This might affect how we discover the available TURN servers. [Karl] There must be some recommendation of such ICE usage, to ensure = that the quality path (if available) is chosen - Yes!=20 Due to security concerns the webRTC also severely limits the speed the connectivity checks happen. So unless Trickle ICE is in use it is good = to keep the number o candidates to a minimum. =20 [Karl] Enforcing a specific TURN-path, will reduce the number of = candidates, so maybe Tickle-ICE does not even have to be used, when there are a an ISP/NSP adviced/offered TURN servers to use .-. P=E5l-Erik > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Mon Feb 17 05:10:54 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D791A01DA for ; Mon, 17 Feb 2014 05:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MSGID_MULTIPLE_AT=1] autolearn=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 UTdflagZ-cfn for ; Mon, 17 Feb 2014 05:10:43 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 73E2C1A03DE for ; Mon, 17 Feb 2014 05:10:40 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402171410342023; Mon, 17 Feb 2014 14:10:34 +0100 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Dan Wing \(dwing\)'" , =?utf-8?Q?'P=C3=A5l_Martinsen'?= References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> <006701cf28af$9c2a27f0$d47e77d0$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A242AD996@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242AD996@xmb-rcd-x10.cisco.com> Date: Mon, 17 Feb 2014 14:10:34 +0100 Message-ID: <03d901cf2be1$a4b78400$ee268c00$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03DA_01CF2BEA.067BEC00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8obNsCBHZfUz6PQqmEmyo5gqkf2AAIL2iQABMqz8AAbsGa4A== Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/XHYl9dX1Dd4Zjni3X8JCRouy5vw Cc: tram@ietf.org Subject: [tram] QoS for RTC over the Internet, DISCUSS: Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 13:10:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_03DA_01CF2BEA.067BEC00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Tiru > I did not did not understand how TURN server will identify if = it=E2=80=99s WebRTC media streams or gaming traffic or some other data = traffic relayed through it to set the diffserv bits correctly ! --- I think you do understand=E2=80=A6 =E2=80=93 but I will spell out = that DISCUSS/MALICE does it better and with useful detail J =20 P=C3=A5l, Tiru, Dan and you other thinking about these things: =20 What has been discussed by me here so far, to give us quality of = real-time traffic over the Internet (not a small task) is: =20 1) To direct the real-time traffic to where the network can handle such = traffic (using a network offered TURN servers) (which is not within the = scope of DISCUSS) =20 2) When such a TURN server flow is allocated, it can ASSUME that it is = going to used for real-time traffic and instruct the network (e g via = setting diffserve bits) to prioritize the assumed real-time traffic. = (Giving the same prioritization to all TURN traffic works quite well. = =E2=80=93 Only if we fill the whole pipe with prioritized traffic (best = effort totally pushed off) is it important that e.g. voice if = prioritized higher than video). =20 3) When the TURN server sees the flow coming in (Note: in both = directions) it can do smarter guesswork of what traffic it is (like a = DPI-box), e.g. what is RTP and what is data channel to instruct the = network better. =20 Now after browsing = http://tools.ietf.org/html/draft-martinsen-tram-discuss-00=20 =20 4) DISCUSS transfers information directly from the application to the = network at the time of setup of the STUN or TURN(?) server, which it = therefore can do with better detail and prediction. This is valuable, = also for reserving bandwidth in non diffserve networks like Cable and = Mobile where one reserves bandwidth rather than use diffserve for QoS. =20 5) Isn=E2=80=99t DISCUSS usable with TURN? Maybe even better! And it can = be used with 1) above J You can transfer the same information in the TURN allocate request as in = the STUN binding request, can=E2=80=99t you?. I searched for = =E2=80=9CTURN=E2=80=9D in the DISCUSS draft, but could not see it = spelled out. TURN is an extension to STUN, so maybe it is just obvious? = =E2=80=93 I have not checked details in the specs so P=C3=A5l, Tiru or = Dan knowing better, please confirm or correct! =20 Some observations: =20 a. In DISCUSS using STUN, the network element doing the diffserv or = reservation settings WOULD be in the default gateway. b. In DISCUSS using TURN, the TURN server doing the diffserv or = reservation settings COULD be in the default gateway. (The = auto-discovery of the TURN server would simply point out the default = gateway.) =20 Sound very similar: Could not DISCUSS over TURN always be used? =20 c. With DISCUSS using TURN, the application would directly talk to the = network device doing the diffserve settings etc. (instead of through it, = where typically the default gateway would snope that talk). Would that = not easy some of the concerns in the draft left for further discussion?=20 =20 d. Can we add info in the response? E.g. if the network device is only = willing to give 1 Mbps instead of needed 3 Mbps, so the application can = be informed to reduce his video resolution? Would be a nice mechanism = when RTC alone starts filling our pipes. (I saw a similar idea by = P=C3=A5l in the previous email I just commented.) =20 =20 6) Please add to the DISCUSS draft that it also could reserve bandwidth = in bandwidth reservation type of networks like Cable and Mobile = networks! =20 =20 A few more things are needed for the ultimate goal, bringing end-to-end = QoS or QoE for real-time communication to Best Effort Internet (which = does not seem impossible, but quite doable now J ) remains though. = I=E2=80=99ll come back to those.=20 =20 It will e.g. relate to how to do with INCOMING traffic, especially in = reservation type of networks, and the wild changing/stripping of = diffserve bits between ISPs. =20 You may want to check this old discussion to see if this useful: http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html=20 =20 /Karl =20 =20 Fr=C3=A5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Skickat: den 13 februari 2014 17:47 Till: Karl Stahl Kopia: tram@ietf.org =C3=84mne: RE: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and ISPs =20 Hi Karl, =20 I did not understand how TURN server will identify if it=E2=80=99s = WebRTC media streams or gaming traffic or some other data traffic = relayed through it to set the diffserv bits correctly ! =20 -Tiru. From: Karl Stahl [mailto:karl.stahl@intertex.se]=20 Sent: Thursday, February 13, 2014 5:05 PM To: Tirumaleswar Reddy (tireddy); 'Hutton, Andrew'; 'Justin Uberti'; = Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; 'Simon Perreault'; 'Oleg Moskalenko'; = tram@ietf.org; 'Marc Blanchet'; Dan Wing (dwing) Subject: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and ISPs =20 On the side of this TRAM-list, I also got this question: > Regarding the enterprise case, I am not sure I follow your argument. > Do you mean that by setting up an enterprise TURN server, and open the = firewall for media over UDP from/to TURN server be the solution? ---- As we all realize, that would of course not help or improve things =20 The intended solution in the enterprise case has not yet been spelled = out in this TRAM-list discussion, so for better understanding, let me = copy a few things from the discussion in September/October on the = RTCWEB-list and what is (since long) spelled out in the = draft-ietf-rtcweb-use-cases-and-requirements. =20 For better understanding, I also want to point out that a TURN can have = two interfaces (acting like a router for media between different = networks). This allows to easier understand that can TURN servers can = direct a best media path (rather than just thinking that a TURN service = is a device which media just bounces against at one interface).=20 =20 And, we can also hope for that a TURN server becomes a (common) = component of a firewall, which would allow the firewall to understand = that the media directed to it is RTC and should be prioritized whereby = the firewall can traffic shaped (back-off data traffic that may be = filling its Internet pipe) as well as e.g. set diffserve bits or take = other measures to assist proper quality handling thought the network. = (These are common mechanisms available and used in firewalls/NATs/access = routers, but TURN servers are not yet included such devices.) The same = goes for access routers/default gateways, DPIs in the transport network = itself =E2=80=93 TURN servers included in such points were media can = pass and quality measures applied may/will be very useful to get us = WebRTC media with through networks without quality destruction. =20 >From the RTCWEB mailing list September 20th (by me): An enterprise network that want to keep a restrictive firewall not = allowing UDP traffic, could provide a real-time path using a TURN server = paralleling the firewall, instead of tunneling RTP through always open = http or https ports resulting in RTP media over TCP =E2=80=93 with = severe quality problems from TCP retransmissions of dropped packets. The = TURN server address is most easily provided in the same way as the IP = address and DNS address. (That would also put the right party in control = =E2=80=93 The network provider (here the enterprise) decides what is = allowed on his network.) =20 The browser should select which available TURN server address to use in = the following priority order, where ICE could be used to try several: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used) 2) TURN server address configured by the network administrator via an = =E2=80=9Cadmin policy template=E2=80=9D 3) TURN server address supplied by DHCP or similar automatic network = method 4) TURN server address being supplied by the web application" =20 =20 And from yesterdays(!) = http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1= 4 these enterprise things and necessity are spelled out in: =20 F19 The browser must be able to use several STUN and TURN servers ---------------------------------------------------------------- =20 A22 = 3.3.5. Simple Video Communication Service, enterprise = aspects = 3.3.5.1. Description This use-case is similar to the Simple Video Communication Service use-case (Section 3.3.1 = ). =20 What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use-case. =20 An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application sessions used from inside the company towards any external peer. To be able to do this they deploy a TURN server that straddles the boundary between the internal and the external network. =20 The firewall will block all attempts to use STUN with an external destination unless they go to the enterprise auditing TURN server. In cases where employees are using RTCWEB applications provided by an external service provider they still want the traffic to stay inside their internal network and in addition not load the straddling TURN server, thus they deploy a STUN server allowing the RTCWEB client to determine its server reflexive address on the internal side. Thus enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possible to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to achieve by auto-configuration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. = 3.3.5.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F20 The browser must support the use of STUN and TURN servers that are supplied by entities other than the web application (i.e. the network provider). ---------------------------------------------------------------- =20 There are further requirement listed, helping us to understand the need = for auto discovery and a network provided TURN-server should be used to = ENFORCE that media takes that path (and thus, other paths e.g. suggested = by the remote MUST not happen to be used). This is related to the = mobility aspect (valid even without the roaming idea): = 3.3.6. Simple Video Communication Service, access = change = 3.3.6.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.3.1 = ). The difference is that the user changes network access during the session. =20 The communication device used by one of the users has several network adapters (Ethernet, WiFi, Cellular). The communication device is accessing the Internet using Ethernet, but the user has to start a trip during the session. The communication device automatically changes to use WiFi when the Ethernet cable is removed and then moves to cellular access to the Internet when moving out of WiFi coverage. The session continues even though the access method changes. = 3.3.6.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- = 3.3.7. Simple Video Communication Service, QoS = 3.3.7.1. Description This use-case is almost identical to the Simple Video Communication Service, access change use-case (Section 3.3.6 = ). The use of Quality of Service (QoS) capabilities = is added: =20 The user in the previous use case that starts a trip is behind a common residential router that supports prioritization of traffic. In addition, the user's provider of cellular access has QoS support enabled. The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular. = 3.3.7.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- F22 The browser must be able to receive streams and data from multiple peers concurrently. ---------------------------------------------------------------- =20 Further from the RTCWEB mailing list September 20th (by me): =20 There are several reasons for a network service provider to supply a = TURN server as part of his offered access: - to keep media paths short, specifically not sending media outside its = own network to some distant application provided TURN server - to support mobility, i.e. you may want to move from a LAN with a = configured TURN server to accessing via WiFi or 3G/4G OTT channels - to offer a media path with better quality (than best effort data = traffic). Getting =E2=80=9CWebRTC-ready=E2=80=9D access and we look forward to = telepresence for everyone. =20 =20 I hope this (a bit lengthy) summary of already thought-out and discussed = aspects/requirements will help us understand that the auto-discovered = TURN server is an ORDER from the enterprise and/or the NSP/ISP to send = the media through this TURN path, and that other media paths that may = exist MUST NOT BE USED. (That is why we especially have to watch/advice = that workable media paths proposed by the remote party not becomes used = =E2=80=9Cby accident=E2=80=9D. =20 /Karl =20 =20 Fr=C3=A5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Skickat: den 13 februari 2014 04:37 Till: Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Kopia: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; = tram@ietf.org; Marc Blanchet; Dan Wing (dwing); Karl Stahl =C3=84mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Hi Andy, =20 There are other ways to solve the problem for example using PCP. Can you = clarify how deploying a TURN server in the Enterprise protects the users = and the network ?=20 =20 -Tiru. From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Thursday, February 13, 2014 1:00 AM To: Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org; = Marc Blanchet; Dan Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The case where the TURN server is the only option may become common = within enterprise networks and that might be deliberate enterprise = policy because it provides the better path (UDP through the F/W) and = protects the users and the network. =20 Andy =20 =20 From: tram [ = mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 12 February 2014 17:46 To: Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ietf.org; Marc Blanchet; = Dan Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Agree. If TURN is indeed being provided for the user's benefit, the = client's ICE logic (based on RTT or similar) should result in it = preferring the TURN path. =20 On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) = wrote: Yes, I believe the second case is rare, but would be better than a rat = race b/w administrators trying to block p2p traffic and force it through = a TURN server and apps/endpoints finding smarter ways to bypass them. =20 Muthu =20 From: Oleg Moskalenko [mailto: = mom040267@gmail.com]=20 Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; = tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The TURN server has to be used when it is either the only option, or if = it provides a better path (I guess the second case is rather rare). =20 On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) = wrote: +1 =20 Forcing all traffic through a TURN server and expecting it would provide = the best user experience doesn't look the right approach. Instead, if a = path through a TURN server exists and does provide lower RTT, jitter = etc, being able to detect and use (or switch to) that path might be = desirable.. =20 Muthu =20 From: tram [mailto: = tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and = necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by = the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle = routing",need a new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D etc! It is not a mistake, but the very need for this = milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like = MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the = wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication = (SIP at that time). However, its largest flaw/problem is that quality = things were not (could not be?) considered. The method=E2=80=99s very = idea (like all similar methods for getting RTC through ordinary = NAT/Firewalls) is to fool the media through a NAT/Firewall that is = unaware of what is happening. Thus, this is root of quality issues (and = bandwidth allocation optimization) that needs to be dealt with: = Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get = media through (and of course with as good quality as required and = possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D It is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =E2=80=9Cbecause it is all = about bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with = time=E2=80=9D etc., I strongly object! That is wrong and will be very = detrimental for WebRTC usage. We already see it and I can give numerous = examples of how much less quality demanding VoIP is/is not handled = quality wise and that it matters. And, what would be bad considering = quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. (Maybe the Web browser can = detect and encourage this=E2=80=A6)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the = browser that there are good media paths to be used, and that the web = browser automatically can chose those, then let us all understand those, = so we can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the = Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) = is a much bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of = WebRTC. =20 /Karl =20 =20 Fr=C3=A5n: Dan Wing [mailto: dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; = Karl Stahl; tram@ietf.org; Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet < = marc.blanchet@viagenie.ca> wrote: =20 Le 2014-02-11 =C3=A0 00:39, Dan Wing < = dwing@cisco.com> a =C3=A9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti < = juberti@google.com> wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' = path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN = server will do, and the endpoint should prefer TURN candidates over all = others because there might be some functionality / usefulness of TURN = that the user might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl < = karl.stahl@intertex.se> wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto: = tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; = tireddy@icisco.com =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =E2=80=9Cautomatically=E2=80=9D within quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) > - 3^rd The Anycast method below =E2=80=93 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready = answer... An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> = http://postellation.viagenie.ca NAT64/DNS64 open-source --> = http://ecdysis.viagenie.ca STUN/TURN server --> = http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_03DA_01CF2BEA.067BEC00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Tiru > I did not did not understand how TURN server will identify = if it=E2=80=99s WebRTC media streams or gaming traffic or some other = data traffic relayed through it to set the diffserv bits correctly = !

--= - I think you do understand=E2=80=A6 =E2=80=93 but I will spell out that = DISCUSS/MALICE does it better and with useful detail J

 

P=C3= =A5l, Tiru, Dan and you other thinking about these = things:

 

Wh= at has been discussed by me here so far, to give us quality of real-time = traffic over the Internet (not a small task) is:

 

1)= To direct the real-time traffic to where the network can handle such = traffic (using a network offered TURN servers) (which is not within the = scope of DISCUSS)

 

2)= When such a TURN server flow is allocated, it can ASSUME that it is = going to used for real-time traffic and instruct the network (e g via = setting diffserve bits) to prioritize the assumed real-time traffic. = (Giving the same prioritization to all TURN traffic works quite well. = =E2=80=93 Only if we fill the whole pipe with prioritized traffic (best = effort totally pushed off) is it important that e.g. voice if = prioritized higher than video).

 

3)= When the TURN server sees the flow coming in (Note: in both directions) = it can do smarter guesswork of what traffic it is (like a DPI-box), e.g. = what is RTP and what is data channel to instruct the network = better.

 

No= w after browsing http:= //tools.ietf.org/html/draft-martinsen-tram-discuss-00 =

 

4)= DISCUSS transfers information directly from the application to the = network at the time of setup of the STUN or TURN(?) server, which it = therefore can do with better detail and prediction. This is valuable, = also for reserving bandwidth in non diffserve networks like Cable and = =C2=A0Mobile where one reserves bandwidth rather than use diffserve for = QoS.

 

5)= Isn=E2=80=99t DISCUSS usable with TURN? Maybe even better! And it can = be used with 1) above J

Yo= u can transfer the same information in the TURN allocate request as in = the STUN binding request, can=E2=80=99t you?. I searched for = =E2=80=9CTURN=E2=80=9D in the DISCUSS draft, but could not see it = spelled out. TURN is an extension to STUN, so maybe it is just obvious? = =E2=80=93 I have not checked details in the specs so P=C3=A5l, Tiru or = Dan knowing better, please confirm or correct!

 

So= me observations:

 

a.= In DISCUSS using STUN, the network element doing the diffserv or = reservation settings WOULD be in the default = gateway.

b.= In DISCUSS using TURN, the TURN server doing the diffserv or = reservation settings COULD be in the default gateway. (The = auto-discovery of the TURN server would simply point out the default = gateway.)

 

So= und very similar: Could not DISCUSS over TURN always be = used?

 

c.= With DISCUSS using TURN, the application would directly talk to the = network device doing the diffserve settings etc. (instead of through it, = where typically the default gateway would snope that talk). Would that = not easy some of the concerns in the draft left for further discussion? =

 

d.= Can we add info in the response? E.g. if the network device is only = willing to give 1 Mbps instead of needed 3 Mbps, so the application can = be informed to reduce his video resolution? Would be a nice mechanism = when RTC alone starts filling our pipes. (I saw a similar idea by = P=C3=A5l in the previous email I just = commented.)

 

 

6)= Please add to the DISCUSS draft that it also could reserve bandwidth in = bandwidth reservation type of networks like Cable and =C2=A0Mobile = networks!

 

 

A = few more things are needed for the ultimate goal, = bringing end-to-end QoS or QoE for real-time communication to Best = Effort Internet (which does not seem impossible, but quite doable now = J = ) remains though. I=E2=80=99ll come back to those. =

 

It= will e.g. relate to how to do with INCOMING traffic, especially in = reservation type of networks, and the wild changing/stripping of = diffserve bits between ISPs.

 

Yo= u may want to check this old discussion to see if this = useful:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html =

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =

 

/K= arl

 

 

Fr=C3=A5n: = Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] =
Skickat: den 13 februari 2014 = 17:47
Till: Karl Stahl
Kopia: = tram@ietf.org
=C3=84mne: RE: IMPORTANT CLARIFICATIONS: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs

 

Hi Karl,

 

I did not understand how TURN server will identify if it=E2=80=99s = WebRTC media streams or gaming traffic or some other data traffic = relayed through it to set the diffserv bits correctly = !

 

-Tiru.

From:= Karl Stahl = [mailto:karl.stahl@intertex.se]=
Sent: Thursday, February 13, 2014 5:05 PM
To: = Tirumaleswar Reddy (tireddy); 'Hutton, Andrew'; 'Justin Uberti'; Muthu = Arul Mozhi Perumal (mperumal)
Cc: tireddy@icisco.com; 'Simon = Perreault'; 'Oleg Moskalenko'; tram@ietf.org; 'Marc Blanchet'; Dan = Wing (dwing)
Subject: IMPORTANT CLARIFICATIONS: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs

 

On= the side of this TRAM-list, I also got this = question:

> Regarding the enterprise case, I am not = sure I follow your argument.

> Do you = mean that by setting up an enterprise TURN server, and open the firewall = for media over UDP from/to TURN server be the = solution?

--= -- As we all realize, that would of course not help or improve = things

 

Th= e intended solution in the enterprise case has not yet been spelled out = in this TRAM-list discussion, so for better understanding, let me copy a = few things from the discussion in September/October on the RTCWEB-list = and what is (since long) spelled out in the = draft-ietf-rtcweb-use-cases-and-requirements.

 

Fo= r better understanding, I also want to point out that a TURN can have = two interfaces (acting like a router for media between different = networks). This allows to easier understand that can TURN servers can = direct a best media path (rather than just thinking that a TURN service = is a device which media just bounces against at one interface). =

 

An= d, we can also hope for that a TURN server becomes a (common) component = of a firewall, which would allow the firewall to understand that the = media directed to it is RTC and should be prioritized whereby the = firewall can traffic shaped (back-off data traffic that may be filling = its Internet pipe) as well as e.g. set diffserve bits or take other = measures to assist proper quality handling thought the network. (These = are common mechanisms available and used in firewalls/NATs/access = routers, but TURN servers are not yet included such devices.) The same = goes for access routers/default gateways, DPIs in the transport network = itself =E2=80=93 TURN servers included in such points were media can = pass and quality measures applied may/will be very useful to get us = WebRTC media with through networks without quality = destruction.

 

Fr= om the RTCWEB mailing list September 20th (by = me):

An enterprise network = that want to keep a restrictive firewall not allowing UDP traffic, could = provide a real-time path using a TURN server paralleling the firewall, = instead of tunneling RTP through always open http or https ports = resulting in RTP media over TCP =E2=80=93 with severe quality problems = from TCP retransmissions of dropped packets. The TURN server address is = most easily provided in the same way as the IP address and DNS address. = (That would also put the right party in control =E2=80=93 The network = provider (here the enterprise) decides what is allowed on his = network.)

 <= /p>

The browser should = select which available TURN server address to use in the following = priority order, where ICE could be used to try = several:

 <= /p>

1) TURN server address = configured in the browser by the user (special cases, normally not = used)

2) TURN server address = configured by the network administrator via an =E2=80=9Cadmin policy = template=E2=80=9D

3) TURN = server address supplied by DHCP or similar automatic network = method

4) TURN server address = being supplied by the web application"

 

 

An= d from yesterdays(!) http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-req= uirements-14 these enterprise things and necessity are spelled out = in:

 

F19     The = browser must be able to use several STUN and TURN = servers

   = ----------------------------------------------------------------

 

A22

3.3.5.  Simple Video Communication = Service, enterprise aspects

3.3.5.1.  = Description

   This use-case is = similar to the Simple Video Communication = Service

   use-case (Section 3.3.1).

 

   What is added is = aspects when using the service in enterprises.  = ICE

   is assumed in the = further description of this use-case.

 

   An enterprise that uses = a RTCWEB based web application for

   communication desires = to audit all RTCWEB based application sessions

   used from inside the = company towards any external peer.  To be = able

   to do this they deploy = a TURN server that straddles the boundary

   between the internal = and the external network.

 

   The firewall will block = all attempts to use STUN with an external

   destination unless they = go to the enterprise auditing TURN server.

   In cases where = employees are using RTCWEB applications provided by = an

   external service = provider they still want the traffic to stay = inside

   their internal network = and in addition not load the straddling TURN

   server, thus they = deploy a STUN server allowing the RTCWEB client = to

   determine its server = reflexive address on the internal side.  = Thus

   enabling cases where = peers are both on the internal side to connect

   without the traffic = leaving the internal network.  It must be

   possible to configure = the browsers used in the enterprise with

   network specific STUN = and TURN servers.  This should be possible = to

  achieve by = auto-configuration methods.  The RTCWEB functionality = will

   need to utilize both = network specific STUN and TURN resources and

   STUN and TURN servers = provisioned by the web application.

3.3.5.2.  Additional = Requirements

   = ----------------------------------------------------------------

   = REQ-ID      DESCRIPTION

   = ----------------------------------------------------------------

   = F20     The browser must support the use of STUN and = TURN

           = servers that are supplied by entities other than

           the = web application (i.e. the network provider).

   = ----------------------------------------------------------------

 

Th= ere are further requirement listed, helping us to understand the need = for auto discovery and a network provided TURN-server should be used to = ENFORCE that media takes that path (and thus, other paths e.g. suggested = by the remote MUST not happen to be used). This is related to the = mobility aspect (valid even without the roaming = idea):

3.3.6= .  Simple Video = Communication Service, access change

3.3.6.1<= b>.  = Description
   This use-case is almost =
identical to the
   Simple Video =
Communication Service use-case (Section 3.3.1).  =
The
   difference is =
that the user changes network access during =
the
   =
session.
 
   The communication =
device used by one of the users has several =
network
   adapters (Ethernet, =
WiFi, Cellular).  The communication device =
is
   accessing the =
Internet using Ethernet, but the user has to start =
a
   trip during =
the session.  The communication device =
automatically
   changes to use WiFi =
when the Ethernet cable is removed and then =
moves
   to cellular access to =
the Internet when moving out of WiFi =
coverage.
   The session continues =
even though the access method changes.
3.3.6.2<= b>.  Additional = Requirements
   =
----------------------------------------------------------------
   =
REQ-ID      =
DESCRIPTION
   =
----------------------------------------------------------------
   =
F17     The communication session must survive =
across a
           =
change of the network interface used by the
           =
session
   =
----------------------------------------------------------------

3.3.7= .  Simple Video = Communication Service, QoS

3.3.7.1<= b>.  = Description
   This use-case is almost =
identical to the
   Simple Video =
Communication Service, access change =
use-case
   (Section 3.3.6).  The use of Quality of =
Service (QoS) capabilities is
   =
added:
 
   The user in the =
previous use case that starts a trip is behind =
a
   common =
residential router that supports prioritization of =
traffic.
   In addition, the user's =
provider of cellular access has QoS support
   enabled.  The user =
is able to take advantage of the QoS support =
both
   when accessing via the =
residential router and when using cellular.
3.3.7.2<= b>.  Additional = Requirements
   =
----------------------------------------------------------------
   =
REQ-ID      =
DESCRIPTION
   =
----------------------------------------------------------------
   =
F17     The communication session must survive =
across a
  =
         change of the =
network interface used by the
           =
session
   =
----------------------------------------------------------------
   =
F22     The browser must be able to receive streams =
and
           data =
from multiple peers concurrently.
   =
----------------------------------------------------------------

 

Fu= rther from the RTCWEB mailing list September 20th (by = me):

 

There are several = reasons for a network service provider to supply a TURN server as part = of his offered access:

- to keep media paths = short, specifically not sending media outside its own network to some = distant application provided TURN server

- to support mobility, = i.e. you may want to move from a LAN with a configured TURN server to = accessing via WiFi or 3G/4G OTT channels

- to offer a media path = with better quality (than best effort data = traffic).

Getting = =E2=80=9CWebRTC-ready=E2=80=9D access and we look forward to = telepresence for everyone.

 

 

I = hope this (a bit lengthy) summary of already thought-out and discussed = aspects/requirements will help us understand that the auto-discovered = TURN server is an ORDER from the enterprise and/or the NSP/ISP  to = send the media through this TURN path, and that other media paths that = may exist MUST NOT BE USED. (That is why we especially have to = watch/advice that workable media paths proposed by the remote party not = becomes used =E2=80=9Cby accident=E2=80=9D.

 

/K= arl

 

 

Fr=C3=A5n: = Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] =
Skickat: den 13 februari 2014 04:37
Till: Hutton, = Andrew; Justin Uberti; Muthu Arul Mozhi Perumal = (mperumal)
Kopia: tireddy@icisco.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing = (dwing); Karl Stahl
=C3=84mne: RE: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

Hi Andy,

 

There are other ways to solve the problem for example using PCP. Can = you clarify how deploying a TURN server in the Enterprise protects the = users and the network ?

 

-Tiru.

From:= tram [mailto:tram-bounces@ietf.org] = On Behalf Of Hutton, Andrew
Sent: Thursday, February = 13, 2014 1:00 AM
To: Justin Uberti; Muthu Arul Mozhi Perumal = (mperumal)
Cc: tireddy@icisco.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing = (dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

The case where the TURN server is the only option may become common = within enterprise networks and that might be deliberate enterprise = policy because it provides the better path (UDP through the F/W) and = protects the users and the network.

 

Andy

 

 

From:= tram = [mailto:tram-= bounces@ietf.org] On = Behalf Of Justin Uberti
Sent: 12 February 2014 = 17:46
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: = tireddy@icis= co.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.or= g; Marc = Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs

 

Agree. If TURN is indeed being provided for the user's = benefit, the client's ICE logic (based on RTT or similar) should result = in it preferring the TURN path.

 

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

Yes, I = believe the second case is rare, but would be better than a rat race b/w = administrators trying to block p2p traffic and force it through a TURN = server and apps/endpoints finding smarter ways to bypass = them.

 

Muthu

 

From:= Oleg = Moskalenko [mailto:mom040267@gm= ail.com] =
Sent: Wednesday, February 12, 2014 1:07 PM
To: = Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl = Stahl; tireddy@icis= co.com; Marc = Blanchet; tram@ietf.or= g; Dan Wing = (dwing); Simon Perreault


Subject: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

The TURN server has to be used when it is either the only = option, or if it provides a better path (I guess the second case is = rather rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would = provide the best user experience doesn't look the right approach. = Instead, if a path through a TURN server exists and does provide lower = RTT, jitter etc, being able to detect and use (or switch to) that path = might be desirable..

 

Muthu

 

From:= tram = [mailto:tram-bounces= @ietf.org] On = Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 = 11:43 AM
To: Karl Stahl
Cc: tireddy@icis= co.com; Marc = Blanchet; tram@ietf.or= g; Dan Wing = (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the right = technology here, compared to a more transparent flow identification tool = like MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for = WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method=E2=80=99s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion point.

 

I think that "fooling" is an incorrect = description. The NAT is supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues =E2=80=9Cbecause it is all about = bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D = etc., I strongly object! That is wrong and will be very detrimental for = WebRTC usage. We already see it and I can give numerous examples of how = much less quality demanding VoIP is/is not handled quality wise and that = it matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this=E2=80=A6) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone.

 

Skype, Hangouts, Facetime are doing billions of minutes per = week and the Internet has not melted yet. If we need to do flow = identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to fade = away with the move to IPv6. I don't think we want to make it a critical = element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=C3=A5n: Dan Wing = [mailto:dwing@cisco.= com] =
Skickat: den 11 februari 2014 18:25
Till: = Marc = Blanchet
Kopia: Justin Uberti; tireddy@icis= co.com; Karl = Stahl; tram@ietf.or= g; Simon = Perreault


=C3=84= mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs

 

 

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

 

Le = 2014-02-11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit :

 


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@go= ogle.com> = wrote:

 

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all).

 

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced privacy)?

 

-d

 

 

 

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these use-cases.

 

-d<= span lang=3DEN-US>

 

 

 

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl= @intertex.se> = wrote:

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounc= es@ietf.org] = F=C3=B6r Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: = Karl Stahl; tram@ietf.= org; tireddy@ic= isco.com
=C3=84= mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =C3=A9crit :
> - Note that to achieve some of the above points, = TURN must be favored
> over STUN to enforce that the TURN-path = actually is used. (The Anycast
> method suggested below, = =E2=80=9Cautomatically=E2=80=9D does this.)

I understand the STUN = vs TURN priority issue. But I don't see how anycast affects it in any = way. Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the =E2=80=9Cautomatically=E2=80=9D within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below =E2=80=93 I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) =E2=80=93 The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://pos= tellation.viagenie.ca
NAT64/= DNS64 open-source        --> http://ecd= ysis.viagenie.ca
STUN/T= URN server               = --> http://num= b.viagenie.ca
______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

__= _____________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

 

<= /div>

 


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

 

 

------=_NextPart_000_03DA_01CF2BEA.067BEC00-- From nobody Mon Feb 17 05:56:04 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79DA1A04EA for ; Mon, 17 Feb 2014 05:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 AjttLWUdcgb2 for ; Mon, 17 Feb 2014 05:55:59 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 06B521A04E9 for ; Mon, 17 Feb 2014 05:55:59 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 45CE940447 for ; Mon, 17 Feb 2014 08:55:56 -0500 (EST) Message-ID: <530214EB.5030303@viagenie.ca> Date: Mon, 17 Feb 2014 08:55:55 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> <006701cf28af$9c2a27f0$d47e77d0$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A242AD996@xmb-rcd-x10.cisco.com> <03d901cf2be1$a4b78400$ee268c00$@stahl@intertex.se> In-Reply-To: <03d901cf2be1$a4b78400$ee268c00$@stahl@intertex.se> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RIf0cOVjxzF0BvoFCsAYP1b_oCo Subject: Re: [tram] QoS for RTC over the Internet, DISCUSS: Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 13:56:03 -0000 Le 2014-02-17 08:10, Karl Stahl a écrit : > 2) When such a TURN server flow is allocated, it can ASSUME that it is > going to used for real-time traffic and instruct the network (e g via > setting diffserve bits) to prioritize the assumed real-time traffic. > (Giving the same prioritization to all TURN traffic works quite well. – > Only if we fill the whole pipe with prioritized traffic (best effort > totally pushed off) is it important that e.g. voice if prioritized > higher than video). What happens if subscribers start using the TURN server for BitTorrent traffic? (It can and it will happen if an ISP offers significant QoS enhancements to TURN traffic. It takes just one person to implement it in Transmission and then overnight the TURN server becomes saturated.) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Mon Feb 17 06:15:53 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796281A04E6 for ; Mon, 17 Feb 2014 06:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 TDYkjuUh7lx6 for ; Mon, 17 Feb 2014 06:15:49 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3329E1A04E1 for ; Mon, 17 Feb 2014 06:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2581; q=dns/txt; s=iport; t=1392646547; x=1393856147; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=QUqDb0XcDjFmT/4jO7bE0oTUxWhRAyqsJWIXKxy77Do=; b=QeZ+KW/vtYqKWUL9oz5pqUuMyN6bKcWKO3PDmCQTiNOITd2/25Ru48xZ 7EyqdwgEskR1EFKt4LB7UP7ZMjelE3HPiJrz7f65d+9ClzFMC++DCGsd5 jE+bRqzoMKLcczKGxb0dZy9w5JbrIhXXEGS2glsmYgVrKKpf19z+PLx9Y 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFACUZAlOtJV2a/2dsb2JhbABZgwY4V784gR8WdIIlAQEBBAEBATc0CQ4EAgEIEQQBAQsUCQcnCxQHAQEFAwIEEwgBEodqDctYF45QOAaDHoEUBJlekHGDLYIq X-IronPort-AV: E=Sophos;i="4.95,860,1384300800"; d="scan'208";a="103586133" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by mtv-iport-3.cisco.com with ESMTP; 17 Feb 2014 14:15:46 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1HEFjxw026955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Feb 2014 14:15:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 08:15:45 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "tram@ietf.org" Thread-Topic: New Version Notification for draft-eckel-aeon-problem-statement-00.txt Thread-Index: AQHPKbEy9vpA+EhFF0mHdOTwvhnzX5q1dmWAgAQGmXA= Date: Mon, 17 Feb 2014 14:15:44 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242AF566@xmb-rcd-x10.cisco.com> References: <20140214181840.14035.86856.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/G-B0CrF69f19nw9NMgSfhkcDKl4 Subject: [tram] FW: New Version Notification for draft-eckel-aeon-problem-statement-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 14:15:51 -0000 This draft may be of interest to the WG. It discusses the problems of appli= cation identification using heuristics like DPI. =20 -Tiru -----Original Message----- From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Charles Eckel (eckel= cu) Sent: Friday, February 14, 2014 11:59 PM To: aeon@ietf.org Subject: [Aeon] FW: New Version Notification for draft-eckel-aeon-problem-s= tatement-00.txt This draft has been submitted in an attempt to focus on the problem stateme= nt without jumping to a specific solution. Instead, a section at the end ca= ptures some high level requirements of any such solution. Please have a loo= k and share your comments. Cheers, Charles On 2/14/14 10:18 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-eckel-aeon-problem-statement-00.txt >has been successfully submitted by Charles Eckel and posted to the IETF=20 >repository. > >Name: draft-eckel-aeon-problem-statement >Revision: 00 >Title: Application Enabled Open Networking: Problem Statement and >Requirements >Document date: 2014-02-14 >Group: Individual Submission >Pages: 6 >URL: =20 >http://www.ietf.org/internet-drafts/draft-eckel-aeon-problem-statement-00. >txt >Status: =20 >https://datatracker.ietf.org/doc/draft-eckel-aeon-problem-statement/ >Htmlized: =20 >http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00 > > >Abstract: > Identification and treatment of application flows are critical for > the successful deployment and operation of applications. > Historically, this functionality has been accomplished to the extent > possible using heuristics, which inspect and infer flow > characteristics. Heuristics may be based on port ranges, network > separation, or deep packet inspection (DPI). But many application > flows in current usages are dynamic, time-bound (short lived for some > of them), possibly encrypted (TLS for signaling), peer-to-peer, > possibly asymmetric, and used on non-dedicated devices, any > combination of which renders such techniques less effective or > results in compromises to application security or user privacy. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > _______________________________________________ Aeon mailing list Aeon@ietf.org https://www.ietf.org/mailman/listinfo/aeon From nobody Mon Feb 17 07:23:16 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 789BF1A0238 for ; Mon, 17 Feb 2014 07:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 BRfAO0O_X6xk for ; Mon, 17 Feb 2014 07:23:03 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 790C41A0211 for ; Mon, 17 Feb 2014 07:23:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=201112; q=dns/txt; s=iport; t=1392650579; x=1393860179; h=from:to:cc:subject:date:message-id:mime-version; bh=CjttME4znqIj5XqiBRAd6sf7dHj53P59ww5pv/G66rk=; b=NwZtY0rNV6NpMIDM7vUM/Dlga+Dsjnv00xCeOFKiF6bZcEhDe4BVSot7 mk7KC3ed2A05pgoMoYggiePbScKrhHn4V4TJMk3slhAoH+Jl9Foyxnbw7 eRrfIpOp/Gh08djLSvps4tyRYFPWv3ZH2LjIoHMdr5I/TlAJ2TSrs/cr5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8HAOooAlOtJV2d/2dsb2JhbABPCoJCRDhXgwKnV4wGiApPGIEHFnSCJQEBAQIBAQEBARcBCAQGOgUCBAQDBQ0BBgIRBAEBCxYBAgQDAgQfBgsUCQkBBAEJBAUIARKHVgMJCA2OBpt/mUANiA8XjGeBLgoGCgIBAR0WFgEEBgqCZjWBFASFWI5rgX2DHosshUWBb4E+gXE5 X-IronPort-AV: E=Sophos;i="4.95,861,1384300800"; d="scan'208,217";a="304600217" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 17 Feb 2014 15:22:57 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1HFMtm4029182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 15:22:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.80]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 09:22:55 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Karl Stahl , "Dan Wing (dwing)" , "Pal Martinsen (palmarti)" Thread-Topic: QoS for RTC over the Internet, DISCUSS: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: Ac8r9BugYsLIjYAAQP2Yz1Hsf4BmOA== Date: Mon, 17 Feb 2014 15:22:54 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242AF62F@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.99] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242AF62Fxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/8WtYNrvnQN_cRxYKRch6pk9Gg7Y Cc: "tram@ietf.org" Subject: Re: [tram] QoS for RTC over the Internet, DISCUSS: Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 15:23:12 -0000 --_000_913383AAA69FF945B8F946018B75898A242AF62Fxmbrcdx10ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgS2FybCwNCg0KUGxlYXNlIHNlZSBpbmxpbmUgW1RSXQ0KDQoNCkZyb206IEthcmwgU3RhaGwg W21haWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlXQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAx NywgMjAxNCA2OjQxIFBNDQpUbzogVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KTsgRGFuIFdp bmcgKGR3aW5nKTsgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpDQpDYzogdHJhbUBpZXRmLm9yZzxt YWlsdG86dHJhbUBpZXRmLm9yZz4NClN1YmplY3Q6IFFvUyBmb3IgUlRDIG92ZXIgdGhlIEludGVy bmV0LCBESVNDVVNTOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292 ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpUaXJ1ID4gSSBkaWQgbm90 IGRpZCBub3QgdW5kZXJzdGFuZCBob3cgVFVSTiBzZXJ2ZXIgd2lsbCBpZGVudGlmeSBpZiBpdOKA mXMgV2ViUlRDIG1lZGlhIHN0cmVhbXMgb3IgZ2FtaW5nIHRyYWZmaWMgb3Igc29tZSBvdGhlciBk YXRhIHRyYWZmaWMgcmVsYXllZCB0aHJvdWdoIGl0IHRvIHNldCB0aGUgZGlmZnNlcnYgYml0cyBj b3JyZWN0bHkgIQ0KLS0tIEkgdGhpbmsgeW91IGRvIHVuZGVyc3RhbmTigKYg4oCTIGJ1dCBJIHdp bGwgc3BlbGwgb3V0IHRoYXQgRElTQ1VTUy9NQUxJQ0UgZG9lcyBpdCBiZXR0ZXIgYW5kIHdpdGgg dXNlZnVsIGRldGFpbCDimLoNCg0KUMOlbCwgVGlydSwgRGFuIGFuZCB5b3Ugb3RoZXIgdGhpbmtp bmcgYWJvdXQgdGhlc2UgdGhpbmdzOg0KDQpXaGF0IGhhcyBiZWVuIGRpc2N1c3NlZCBieSBtZSBo ZXJlIHNvIGZhciwgdG8gZ2l2ZSB1cyBxdWFsaXR5IG9mIHJlYWwtdGltZSB0cmFmZmljIG92ZXIg dGhlIEludGVybmV0IChub3QgYSBzbWFsbCB0YXNrKSBpczoNCg0KMSkgVG8gZGlyZWN0IHRoZSBy ZWFsLXRpbWUgdHJhZmZpYyB0byB3aGVyZSB0aGUgbmV0d29yayBjYW4gaGFuZGxlIHN1Y2ggdHJh ZmZpYyAodXNpbmcgYSBuZXR3b3JrIG9mZmVyZWQgVFVSTiBzZXJ2ZXJzKSAod2hpY2ggaXMgbm90 IHdpdGhpbiB0aGUgc2NvcGUgb2YgRElTQ1VTUykNCg0KW1RSXSBJIHN0aWxsIGRvbuKAmXQgdW5k ZXJzdGFuZCB0aGUgbmVlZCB0byBmb3JjZSB0aGUgbWVkaWEgdHJhZmZpYyB0byBiZSBzZW50IHRo cm91Z2ggdGhlIFRVUk4gc2VydmVyIGVpdGhlciB3aXRoIERJU0NVU1Mgb3IgUENQLg0KDQoyKSBX aGVuIHN1Y2ggYSBUVVJOIHNlcnZlciBmbG93IGlzIGFsbG9jYXRlZCwgaXQgY2FuIEFTU1VNRSB0 aGF0IGl0IGlzIGdvaW5nIHRvIHVzZWQgZm9yIHJlYWwtdGltZSB0cmFmZmljIGFuZCBpbnN0cnVj dCB0aGUgbmV0d29yayAoZSBnIHZpYSBzZXR0aW5nIGRpZmZzZXJ2ZSBiaXRzKSB0byBwcmlvcml0 aXplIHRoZSBhc3N1bWVkIHJlYWwtdGltZSB0cmFmZmljLiAoR2l2aW5nIHRoZSBzYW1lIHByaW9y aXRpemF0aW9uIHRvIGFsbCBUVVJOIHRyYWZmaWMgd29ya3MgcXVpdGUgd2VsbC4g4oCTIE9ubHkg aWYgd2UgZmlsbCB0aGUgd2hvbGUgcGlwZSB3aXRoIHByaW9yaXRpemVkIHRyYWZmaWMgKGJlc3Qg ZWZmb3J0IHRvdGFsbHkgcHVzaGVkIG9mZikgaXMgaXQgaW1wb3J0YW50IHRoYXQgZS5nLiB2b2lj ZSBpZiBwcmlvcml0aXplZCBoaWdoZXIgdGhhbiB2aWRlbykuDQoNCltUUl0gVGhpcyBhc3N1bXB0 aW9uIGlzIG5vdCByaWdodCBhbmQgY291bGQgcmVzdWx0IGluIGZhbHNlIHBvc2l0aXZlcy4NCg0K MykgV2hlbiB0aGUgVFVSTiBzZXJ2ZXIgc2VlcyB0aGUgZmxvdyBjb21pbmcgaW4gKE5vdGU6IGlu IGJvdGggZGlyZWN0aW9ucykgaXQgY2FuIGRvIHNtYXJ0ZXIgZ3Vlc3N3b3JrIG9mIHdoYXQgdHJh ZmZpYyBpdCBpcyAobGlrZSBhIERQSS1ib3gpLCBlLmcuIHdoYXQgaXMgUlRQIGFuZCB3aGF0IGlz IGRhdGEgY2hhbm5lbCB0byBpbnN0cnVjdCB0aGUgbmV0d29yayBiZXR0ZXIuDQoNCltUUl0gSSBk b27igJl0IHRoaW5rIERQSSB3aWxsIGhlbHAsIGhvdyB3aWxsIHRoZSBUVVJOIHNlcnZlciBkaWZm ZXJlbnRpYXRlIGIvdyBhdWRpbyBhbmQgdmlkZW8gc3RyZWFtcyB3aGVuIGl0IGlzIERUTFMtU1JU UCA/DQpFdmVuIHRoZSBIb21lIFJvdXRlciBuZWVkcyB0byB0cmVhdCB0aGVzZSBtZWRpYSBzdHJl YW1zIGRpZmZlcmVudGx5IGJ1dCBtYXkgbm90IHNlZSB0aGUgbmVlZCB0byBkZXBsb3kgYSBUVVJO IHNlcnZlci4NCg0KTm93IGFmdGVyIGJyb3dzaW5nIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LW1hcnRpbnNlbi10cmFtLWRpc2N1c3MtMDANCg0KNCkgRElTQ1VTUyB0cmFuc2ZlcnMg aW5mb3JtYXRpb24gZGlyZWN0bHkgZnJvbSB0aGUgYXBwbGljYXRpb24gdG8gdGhlIG5ldHdvcmsg YXQgdGhlIHRpbWUgb2Ygc2V0dXAgb2YgdGhlIFNUVU4gb3IgVFVSTig/KSBzZXJ2ZXIsIHdoaWNo IGl0IHRoZXJlZm9yZSBjYW4gZG8gd2l0aCBiZXR0ZXIgZGV0YWlsIGFuZCBwcmVkaWN0aW9uLiBU aGlzIGlzIHZhbHVhYmxlLCBhbHNvIGZvciByZXNlcnZpbmcgYmFuZHdpZHRoIGluIG5vbiBkaWZm c2VydmUgbmV0d29ya3MgbGlrZSBDYWJsZSBhbmQgIE1vYmlsZSB3aGVyZSBvbmUgcmVzZXJ2ZXMg YmFuZHdpZHRoIHJhdGhlciB0aGFuIHVzZSBkaWZmc2VydmUgZm9yIFFvUy4NCg0KW1RSXSBZZXMs IHRoZSBuZXR3b3JrIGNhbiBlbmZvcmNlIGFueSBRT1MgcG9saWN5IGJhc2VkIG9uIHRoZSBtZXRh ZGF0YSBzaWduYWxlZCBieSB0aGUgY2xpZW50LiBQbGVhc2Ugbm90ZSB0aGF0IGR1cmluZyB0aGUg cmV2aWV3IG9mIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbmctcGNwLWZsb3dk YXRhLTAwIHdlIGZvdW5kIHRoYXQgdGhlcmUgd2FzIG9ubHkgaW50ZXJlc3QgdG8gcHJvdmlkZSBH QlIgKEd1YXJhbnRlZWQgQml0IFJhdGUg4oCTIGJhbmR3aWR0aCByZXNlcnZhdGlvbikgZm9yIFdl YlJUQyBtZWRpYSBzdHJlYW1zIGlmIHRoZSBXZWJSVEMgc2VydmVyIGhhcyBidXNpbmVzcyB0aWUt dXAgd2l0aCB0aGUgTW9iaWxlIG5ldHdvcmsgb3RoZXJ3aXNlIGl04oCZcyBub24tR0JSIGZvciB0 aGUgV2ViUlRDIG1lZGlhIHN0cmVhbXMuICBUaGlzIHRvcGljIG5lZWRzIG1vcmUgZGlzY3Vzc2lv bi4NCg0KNSkgSXNu4oCZdCBESVNDVVNTIHVzYWJsZSB3aXRoIFRVUk4/IE1heWJlIGV2ZW4gYmV0 dGVyISBBbmQgaXQgY2FuIGJlIHVzZWQgd2l0aCAxKSBhYm92ZSDimLoNCllvdSBjYW4gdHJhbnNm ZXIgdGhlIHNhbWUgaW5mb3JtYXRpb24gaW4gdGhlIFRVUk4gYWxsb2NhdGUgcmVxdWVzdCBhcyBp biB0aGUgU1RVTiBiaW5kaW5nIHJlcXVlc3QsIGNhbuKAmXQgeW91Py4gSSBzZWFyY2hlZCBmb3Ig 4oCcVFVSTuKAnSBpbiB0aGUgRElTQ1VTUyBkcmFmdCwgYnV0IGNvdWxkIG5vdCBzZWUgaXQgc3Bl bGxlZCBvdXQuIFRVUk4gaXMgYW4gZXh0ZW5zaW9uIHRvIFNUVU4sIHNvIG1heWJlIGl0IGlzIGp1 c3Qgb2J2aW91cz8g4oCTIEkgaGF2ZSBub3QgY2hlY2tlZCBkZXRhaWxzIGluIHRoZSBzcGVjcyBz byBQw6VsLCBUaXJ1IG9yIERhbiBrbm93aW5nIGJldHRlciwgcGxlYXNlIGNvbmZpcm0gb3IgY29y cmVjdCAhDQoNCltUUl0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGhvbXNvbi10 cmFtLXR1cm4tYmFuZHdpZHRoLTAwIGFkZHJlc3NlcyB0aGUgcHJvYmxlbSB5b3UgaGFkIG1lbnRp b25lZCwgaXQgbmVlZHMgdG8gYmUgZW5oYW5jZWQgd2l0aCBtb3JlIG1ldGFkYXRhIGFuZCB0aGUg b3RoZXIgYWR2YW50YWdlIGlzIFRVUk4gc2VydmVyIGNhbiByZXNwb25kIGluIHRoZSBBTExPQ0FU RSByZXNwb25zZSBpZiBpdCBjYW4gbWVldCB0aGUgZmxvdyBjaGFyYWN0ZXJpc3RpY3Mgb3Igbm90 LiAgSXTigJlzIGRpc2N1c3NlZCBpbiBzZWN0aW9uIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXRob21zb24tdHJhbS10dXJuLWJhbmR3aWR0aC0wMCNzZWN0aW9uLTQuMiBvZiB0aGUg ZHJhZnQuICBNeSBwb2ludCBpcyBpdOKAmXMgb25seSB1c2VmdWwgaWYgVFVSTiBpcyBzZWxlY3Rl ZCBiZWNhdXNlIGRpcmVjdCBjb25uZWN0aXZpdHkgdXNpbmcgaG9zdC9zZXJ2ZXItcmVmbGV4aXZl IGNhbmRpZGF0ZXMgZmFpbGVkIG9yIHJlbGF5ZWQgY2FuZGlkYXRlcyBhcmUgb25seSBhZHZlcnRp c2VkIGZvciBwcml2YWN5IHJlYXNvbi4NCg0KU29tZSBvYnNlcnZhdGlvbnM6DQoNCmEuIEluIERJ U0NVU1MgdXNpbmcgU1RVTiwgdGhlIG5ldHdvcmsgZWxlbWVudCBkb2luZyB0aGUgZGlmZnNlcnYg b3IgcmVzZXJ2YXRpb24gc2V0dGluZ3MgV09VTEQgYmUgaW4gdGhlIGRlZmF1bHQgZ2F0ZXdheS4N CmIuIEluIERJU0NVU1MgdXNpbmcgVFVSTiwgdGhlIFRVUk4gc2VydmVyIGRvaW5nIHRoZSBkaWZm c2VydiBvciByZXNlcnZhdGlvbiBzZXR0aW5ncyBDT1VMRCBiZSBpbiB0aGUgZGVmYXVsdCBnYXRl d2F5LiAoVGhlIGF1dG8tZGlzY292ZXJ5IG9mIHRoZSBUVVJOIHNlcnZlciB3b3VsZCBzaW1wbHkg cG9pbnQgb3V0IHRoZSBkZWZhdWx0IGdhdGV3YXkuKQ0KDQpTb3VuZCB2ZXJ5IHNpbWlsYXI6IENv dWxkIG5vdCBESVNDVVNTIG92ZXIgVFVSTiBhbHdheXMgYmUgdXNlZD8NCg0KYy4gV2l0aCBESVND VVNTIHVzaW5nIFRVUk4sIHRoZSBhcHBsaWNhdGlvbiB3b3VsZCBkaXJlY3RseSB0YWxrIHRvIHRo ZSBuZXR3b3JrIGRldmljZSBkb2luZyB0aGUgZGlmZnNlcnZlIHNldHRpbmdzIGV0Yy4gKGluc3Rl YWQgb2YgdGhyb3VnaCBpdCwgd2hlcmUgdHlwaWNhbGx5IHRoZSBkZWZhdWx0IGdhdGV3YXkgd291 bGQgc25vcGUgdGhhdCB0YWxrKS4gV291bGQgdGhhdCBub3QgZWFzeSBzb21lIG9mIHRoZSBjb25j ZXJucyBpbiB0aGUgZHJhZnQgbGVmdCBmb3IgZnVydGhlciBkaXNjdXNzaW9uPw0KDQpkLiBDYW4g d2UgYWRkIGluZm8gaW4gdGhlIHJlc3BvbnNlPyBFLmcuIGlmIHRoZSBuZXR3b3JrIGRldmljZSBp cyBvbmx5IHdpbGxpbmcgdG8gZ2l2ZSAxIE1icHMgaW5zdGVhZCBvZiBuZWVkZWQgMyBNYnBzLCBz byB0aGUgYXBwbGljYXRpb24gY2FuIGJlIGluZm9ybWVkIHRvIHJlZHVjZSBoaXMgdmlkZW8gcmVz b2x1dGlvbj8gV291bGQgYmUgYSBuaWNlIG1lY2hhbmlzbSB3aGVuIFJUQyBhbG9uZSBzdGFydHMg ZmlsbGluZyBvdXIgcGlwZXMuIChJIHNhdyBhIHNpbWlsYXIgaWRlYSBieSBQw6VsIGluIHRoZSBw cmV2aW91cyBlbWFpbCBJIGp1c3QgY29tbWVudGVkLikNCg0KW1RSXSBQQ1Agc29sdmVzIHRoZSBw cm9ibGVtIGJ5IHByb3ZpZGluZyByZXNwb25zZSBzaW1pbGFyIHRvIHdoYXQgeW91IGhhZCBtZW50 aW9uZWQgYW5kIGNhbiBhbHNvIHNlbmQgc3Vic2VxdWVudCByZXNwb25zZSB1cGRhdGluZyB0aGUg aW5mb3JtYXRpb24gYWJvdXQgdGhlIGZsb3csIHNob3VsZCB0aGUgbmV0d29yayBjb25kaXRpb25z IGNoYW5nZS4gRm9yIG1vcmUgZGV0YWlscyByZWZlciB0byBodHRwOi8vd3d3LmlldGYub3JnL3By b2NlZWRpbmdzLzg3L3NsaWRlcy9zbGlkZXMtODctcGNwLTUucGRmLg0KDQotVGlydS4NCg0KNikg UGxlYXNlIGFkZCB0byB0aGUgRElTQ1VTUyBkcmFmdCB0aGF0IGl0IGFsc28gY291bGQgcmVzZXJ2 ZSBiYW5kd2lkdGggaW4gYmFuZHdpZHRoIHJlc2VydmF0aW9uIHR5cGUgb2YgbmV0d29ya3MgbGlr ZSBDYWJsZSBhbmQgIE1vYmlsZSBuZXR3b3JrcyENCg0KDQpBIGZldyBtb3JlIHRoaW5ncyBhcmUg bmVlZGVkIGZvciB0aGUgdWx0aW1hdGUgZ29hbCwgYnJpbmdpbmcgZW5kLXRvLWVuZCBRb1Mgb3Ig UW9FIGZvciByZWFsLXRpbWUgY29tbXVuaWNhdGlvbiB0byBCZXN0IEVmZm9ydCBJbnRlcm5ldCAo d2hpY2ggZG9lcyBub3Qgc2VlbSBpbXBvc3NpYmxlLCBidXQgcXVpdGUgZG9hYmxlIG5vdyDimLog KSByZW1haW5zIHRob3VnaC4gSeKAmWxsIGNvbWUgYmFjayB0byB0aG9zZS4NCg0KSXQgd2lsbCBl LmcuIHJlbGF0ZSB0byBob3cgdG8gZG8gd2l0aCBJTkNPTUlORyB0cmFmZmljLCBlc3BlY2lhbGx5 IGluIHJlc2VydmF0aW9uIHR5cGUgb2YgbmV0d29ya3MsIGFuZCB0aGUgd2lsZCBjaGFuZ2luZy9z dHJpcHBpbmcgb2YgZGlmZnNlcnZlIGJpdHMgYmV0d2VlbiBJU1BzLg0KDQpZb3UgbWF5IHdhbnQg dG8gY2hlY2sgdGhpcyBvbGQgZGlzY3Vzc2lvbiB0byBzZWUgaWYgdGhpcyB1c2VmdWw6DQpodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMDkxMjgu aHRtbA0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50 L21zZzA5MTI5Lmh0bWwNCg0KL0thcmwNCg0KDQpGcsOlbjogVGlydW1hbGVzd2FyIFJlZGR5ICh0 aXJlZGR5KSBbbWFpbHRvOnRpcmVkZHlAY2lzY28uY29tXQ0KU2tpY2thdDogZGVuIDEzIGZlYnJ1 YXJpIDIwMTQgMTc6NDcNClRpbGw6IEthcmwgU3RhaGwNCktvcGlhOiB0cmFtQGlldGYub3JnPG1h aWx0bzp0cmFtQGlldGYub3JnPg0Kw4RtbmU6IFJFOiBJTVBPUlRBTlQgQ0xBUklGSUNBVElPTlM6 IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNt IGZvciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNCkhpIEthcmwsDQoNCkkgZGlkIG5vdCB1bmRlcnN0 YW5kIGhvdyBUVVJOIHNlcnZlciB3aWxsIGlkZW50aWZ5IGlmIGl04oCZcyBXZWJSVEMgbWVkaWEg c3RyZWFtcyBvciBnYW1pbmcgdHJhZmZpYyBvciBzb21lIG90aGVyIGRhdGEgdHJhZmZpYyByZWxh eWVkIHRocm91Z2ggaXQgdG8gc2V0IHRoZSBkaWZmc2VydiBiaXRzIGNvcnJlY3RseSAhDQoNCi1U aXJ1Lg0KRnJvbTogS2FybCBTdGFobCBbbWFpbHRvOmthcmwuc3RhaGxAaW50ZXJ0ZXguc2VdDQpT ZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMTMsIDIwMTQgNTowNSBQTQ0KVG86IFRpcnVtYWxlc3dh ciBSZWRkeSAodGlyZWRkeSk7ICdIdXR0b24sIEFuZHJldyc7ICdKdXN0aW4gVWJlcnRpJzsgTXV0 aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkNCkNjOiB0aXJlZGR5QGljaXNjby5jb208 bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT47ICdTaW1vbiBQZXJyZWF1bHQnOyAnT2xlZyBNb3Nr YWxlbmtvJzsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47ICdNYXJjIEJsYW5j aGV0JzsgRGFuIFdpbmcgKGR3aW5nKQ0KU3ViamVjdDogSU1QT1JUQU5UIENMQVJJRklDQVRJT05T OiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlz bSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0KDQpPbiB0aGUgc2lkZSBvZiB0aGlzIFRSQU0tbGlz dCwgSSBhbHNvIGdvdCB0aGlzIHF1ZXN0aW9uOg0KPiBSZWdhcmRpbmcgdGhlIGVudGVycHJpc2Ug Y2FzZSwgSSBhbSBub3Qgc3VyZSBJIGZvbGxvdyB5b3VyIGFyZ3VtZW50Lg0KPiBEbyB5b3UgbWVh biB0aGF0IGJ5IHNldHRpbmcgdXAgYW4gZW50ZXJwcmlzZSBUVVJOIHNlcnZlciwgYW5kIG9wZW4g dGhlIGZpcmV3YWxsIGZvciBtZWRpYSBvdmVyIFVEUCBmcm9tL3RvIFRVUk4gc2VydmVyIGJlIHRo ZSBzb2x1dGlvbj8NCi0tLS0gQXMgd2UgYWxsIHJlYWxpemUsIHRoYXQgd291bGQgb2YgY291cnNl IG5vdCBoZWxwIG9yIGltcHJvdmUgdGhpbmdzDQoNClRoZSBpbnRlbmRlZCBzb2x1dGlvbiBpbiB0 aGUgZW50ZXJwcmlzZSBjYXNlIGhhcyBub3QgeWV0IGJlZW4gc3BlbGxlZCBvdXQgaW4gdGhpcyBU UkFNLWxpc3QgZGlzY3Vzc2lvbiwgc28gZm9yIGJldHRlciB1bmRlcnN0YW5kaW5nLCBsZXQgbWUg Y29weSBhIGZldyB0aGluZ3MgZnJvbSB0aGUgZGlzY3Vzc2lvbiBpbiBTZXB0ZW1iZXIvT2N0b2Jl ciBvbiB0aGUgUlRDV0VCLWxpc3QgYW5kIHdoYXQgaXMgKHNpbmNlIGxvbmcpIHNwZWxsZWQgb3V0 IGluIHRoZSBkcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy4NCg0K Rm9yIGJldHRlciB1bmRlcnN0YW5kaW5nLCBJIGFsc28gd2FudCB0byBwb2ludCBvdXQgdGhhdCBh IFRVUk4gY2FuIGhhdmUgdHdvIGludGVyZmFjZXMgKGFjdGluZyBsaWtlIGEgcm91dGVyIGZvciBt ZWRpYSBiZXR3ZWVuIGRpZmZlcmVudCBuZXR3b3JrcykuIFRoaXMgYWxsb3dzIHRvIGVhc2llciB1 bmRlcnN0YW5kIHRoYXQgY2FuIFRVUk4gc2VydmVycyBjYW4gZGlyZWN0IGEgYmVzdCBtZWRpYSBw YXRoIChyYXRoZXIgdGhhbiBqdXN0IHRoaW5raW5nIHRoYXQgYSBUVVJOIHNlcnZpY2UgaXMgYSBk ZXZpY2Ugd2hpY2ggbWVkaWEganVzdCBib3VuY2VzIGFnYWluc3QgYXQgb25lIGludGVyZmFjZSku DQoNCkFuZCwgd2UgY2FuIGFsc28gaG9wZSBmb3IgdGhhdCBhIFRVUk4gc2VydmVyIGJlY29tZXMg YSAoY29tbW9uKSBjb21wb25lbnQgb2YgYSBmaXJld2FsbCwgd2hpY2ggd291bGQgYWxsb3cgdGhl IGZpcmV3YWxsIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGUgbWVkaWEgZGlyZWN0ZWQgdG8gaXQgaXMg UlRDIGFuZCBzaG91bGQgYmUgcHJpb3JpdGl6ZWQgd2hlcmVieSB0aGUgZmlyZXdhbGwgY2FuIHRy YWZmaWMgc2hhcGVkIChiYWNrLW9mZiBkYXRhIHRyYWZmaWMgdGhhdCBtYXkgYmUgZmlsbGluZyBp dHMgSW50ZXJuZXQgcGlwZSkgYXMgd2VsbCBhcyBlLmcuIHNldCBkaWZmc2VydmUgYml0cyBvciB0 YWtlIG90aGVyIG1lYXN1cmVzIHRvIGFzc2lzdCBwcm9wZXIgcXVhbGl0eSBoYW5kbGluZyB0aG91 Z2h0IHRoZSBuZXR3b3JrLiAoVGhlc2UgYXJlIGNvbW1vbiBtZWNoYW5pc21zIGF2YWlsYWJsZSBh bmQgdXNlZCBpbiBmaXJld2FsbHMvTkFUcy9hY2Nlc3Mgcm91dGVycywgYnV0IFRVUk4gc2VydmVy cyBhcmUgbm90IHlldCBpbmNsdWRlZCBzdWNoIGRldmljZXMuKSBUaGUgc2FtZSBnb2VzIGZvciBh Y2Nlc3Mgcm91dGVycy9kZWZhdWx0IGdhdGV3YXlzLCBEUElzIGluIHRoZSB0cmFuc3BvcnQgbmV0 d29yayBpdHNlbGYg4oCTIFRVUk4gc2VydmVycyBpbmNsdWRlZCBpbiBzdWNoIHBvaW50cyB3ZXJl IG1lZGlhIGNhbiBwYXNzIGFuZCBxdWFsaXR5IG1lYXN1cmVzIGFwcGxpZWQgbWF5L3dpbGwgYmUg dmVyeSB1c2VmdWwgdG8gZ2V0IHVzIFdlYlJUQyBtZWRpYSB3aXRoIHRocm91Z2ggbmV0d29ya3Mg d2l0aG91dCBxdWFsaXR5IGRlc3RydWN0aW9uLg0KDQpGcm9tIHRoZSBSVENXRUIgbWFpbGluZyBs aXN0IFNlcHRlbWJlciAyMHRoIChieSBtZSk6DQoNCkFuIGVudGVycHJpc2UgbmV0d29yayB0aGF0 IHdhbnQgdG8ga2VlcCBhIHJlc3RyaWN0aXZlIGZpcmV3YWxsIG5vdCBhbGxvd2luZyBVRFAgdHJh ZmZpYywgY291bGQgcHJvdmlkZSBhIHJlYWwtdGltZSBwYXRoIHVzaW5nIGEgVFVSTiBzZXJ2ZXIg cGFyYWxsZWxpbmcgdGhlIGZpcmV3YWxsLCBpbnN0ZWFkIG9mIHR1bm5lbGluZyBSVFAgdGhyb3Vn aCBhbHdheXMgb3BlbiBodHRwIG9yIGh0dHBzIHBvcnRzIHJlc3VsdGluZyBpbiBSVFAgbWVkaWEg b3ZlciBUQ1Ag4oCTIHdpdGggc2V2ZXJlIHF1YWxpdHkgcHJvYmxlbXMgZnJvbSBUQ1AgcmV0cmFu c21pc3Npb25zIG9mIGRyb3BwZWQgcGFja2V0cy4gVGhlIFRVUk4gc2VydmVyIGFkZHJlc3MgaXMg bW9zdCBlYXNpbHkgcHJvdmlkZWQgaW4gdGhlIHNhbWUgd2F5IGFzIHRoZSBJUCBhZGRyZXNzIGFu ZCBETlMgYWRkcmVzcy4gKFRoYXQgd291bGQgYWxzbyBwdXQgdGhlIHJpZ2h0IHBhcnR5IGluIGNv bnRyb2wg4oCTIFRoZSBuZXR3b3JrIHByb3ZpZGVyIChoZXJlIHRoZSBlbnRlcnByaXNlKSBkZWNp ZGVzIHdoYXQgaXMgYWxsb3dlZCBvbiBoaXMgbmV0d29yay4pDQoNCg0KDQpUaGUgYnJvd3NlciBz aG91bGQgc2VsZWN0IHdoaWNoIGF2YWlsYWJsZSBUVVJOIHNlcnZlciBhZGRyZXNzIHRvIHVzZSBp biB0aGUgZm9sbG93aW5nIHByaW9yaXR5IG9yZGVyLCB3aGVyZSBJQ0UgY291bGQgYmUgdXNlZCB0 byB0cnkgc2V2ZXJhbDoNCg0KDQoNCjEpIFRVUk4gc2VydmVyIGFkZHJlc3MgY29uZmlndXJlZCBp biB0aGUgYnJvd3NlciBieSB0aGUgdXNlciAoc3BlY2lhbCBjYXNlcywgbm9ybWFsbHkgbm90IHVz ZWQpDQoNCjIpIFRVUk4gc2VydmVyIGFkZHJlc3MgY29uZmlndXJlZCBieSB0aGUgbmV0d29yayBh ZG1pbmlzdHJhdG9yIHZpYSBhbiDigJxhZG1pbiBwb2xpY3kgdGVtcGxhdGXigJ0NCg0KMykgVFVS TiBzZXJ2ZXIgYWRkcmVzcyBzdXBwbGllZCBieSBESENQIG9yIHNpbWlsYXIgYXV0b21hdGljIG5l dHdvcmsgbWV0aG9kDQoNCjQpIFRVUk4gc2VydmVyIGFkZHJlc3MgYmVpbmcgc3VwcGxpZWQgYnkg dGhlIHdlYiBhcHBsaWNhdGlvbiINCg0KDQpBbmQgZnJvbSB5ZXN0ZXJkYXlzKCEpIGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWly ZW1lbnRzLTE0IHRoZXNlIGVudGVycHJpc2UgdGhpbmdzIGFuZCBuZWNlc3NpdHkgYXJlIHNwZWxs ZWQgb3V0IGluOg0KDQpGMTkgICAgIFRoZSBicm93c2VyIG11c3QgYmUgYWJsZSB0byB1c2Ugc2V2 ZXJhbCBTVFVOIGFuZCBUVVJOIHNlcnZlcnMNCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KQTIyDQozLjMuNTxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJl cXVpcmVtZW50cy0xNCNzZWN0aW9uLTMuMy41Pi4gIFNpbXBsZSBWaWRlbyBDb21tdW5pY2F0aW9u IFNlcnZpY2UsIGVudGVycHJpc2UgYXNwZWN0cw0KMy4zLjUuMTxodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xNCNz ZWN0aW9uLTMuMy41LjE+LiAgRGVzY3JpcHRpb24NCiAgIFRoaXMgdXNlLWNhc2UgaXMgc2ltaWxh ciB0byB0aGUgU2ltcGxlIFZpZGVvIENvbW11bmljYXRpb24gU2VydmljZQ0KICAgdXNlLWNhc2Ug KFNlY3Rpb24gMy4zLjE8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3 ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuMT4pLg0KDQogICBX aGF0IGlzIGFkZGVkIGlzIGFzcGVjdHMgd2hlbiB1c2luZyB0aGUgc2VydmljZSBpbiBlbnRlcnBy aXNlcy4gIElDRQ0KICAgaXMgYXNzdW1lZCBpbiB0aGUgZnVydGhlciBkZXNjcmlwdGlvbiBvZiB0 aGlzIHVzZS1jYXNlLg0KDQogICBBbiBlbnRlcnByaXNlIHRoYXQgdXNlcyBhIFJUQ1dFQiBiYXNl ZCB3ZWIgYXBwbGljYXRpb24gZm9yDQogICBjb21tdW5pY2F0aW9uIGRlc2lyZXMgdG8gYXVkaXQg YWxsIFJUQ1dFQiBiYXNlZCBhcHBsaWNhdGlvbiBzZXNzaW9ucw0KICAgdXNlZCBmcm9tIGluc2lk ZSB0aGUgY29tcGFueSB0b3dhcmRzIGFueSBleHRlcm5hbCBwZWVyLiAgVG8gYmUgYWJsZQ0KICAg dG8gZG8gdGhpcyB0aGV5IGRlcGxveSBhIFRVUk4gc2VydmVyIHRoYXQgc3RyYWRkbGVzIHRoZSBi b3VuZGFyeQ0KICAgYmV0d2VlbiB0aGUgaW50ZXJuYWwgYW5kIHRoZSBleHRlcm5hbCBuZXR3b3Jr Lg0KDQogICBUaGUgZmlyZXdhbGwgd2lsbCBibG9jayBhbGwgYXR0ZW1wdHMgdG8gdXNlIFNUVU4g d2l0aCBhbiBleHRlcm5hbA0KICAgZGVzdGluYXRpb24gdW5sZXNzIHRoZXkgZ28gdG8gdGhlIGVu dGVycHJpc2UgYXVkaXRpbmcgVFVSTiBzZXJ2ZXIuDQogICBJbiBjYXNlcyB3aGVyZSBlbXBsb3ll ZXMgYXJlIHVzaW5nIFJUQ1dFQiBhcHBsaWNhdGlvbnMgcHJvdmlkZWQgYnkgYW4NCiAgIGV4dGVy bmFsIHNlcnZpY2UgcHJvdmlkZXIgdGhleSBzdGlsbCB3YW50IHRoZSB0cmFmZmljIHRvIHN0YXkg aW5zaWRlDQogICB0aGVpciBpbnRlcm5hbCBuZXR3b3JrIGFuZCBpbiBhZGRpdGlvbiBub3QgbG9h ZCB0aGUgc3RyYWRkbGluZyBUVVJODQogICBzZXJ2ZXIsIHRodXMgdGhleSBkZXBsb3kgYSBTVFVO IHNlcnZlciBhbGxvd2luZyB0aGUgUlRDV0VCIGNsaWVudCB0bw0KICAgZGV0ZXJtaW5lIGl0cyBz ZXJ2ZXIgcmVmbGV4aXZlIGFkZHJlc3Mgb24gdGhlIGludGVybmFsIHNpZGUuICBUaHVzDQogICBl bmFibGluZyBjYXNlcyB3aGVyZSBwZWVycyBhcmUgYm90aCBvbiB0aGUgaW50ZXJuYWwgc2lkZSB0 byBjb25uZWN0DQogICB3aXRob3V0IHRoZSB0cmFmZmljIGxlYXZpbmcgdGhlIGludGVybmFsIG5l dHdvcmsuICBJdCBtdXN0IGJlDQogICBwb3NzaWJsZSB0byBjb25maWd1cmUgdGhlIGJyb3dzZXJz IHVzZWQgaW4gdGhlIGVudGVycHJpc2Ugd2l0aA0KICAgbmV0d29yayBzcGVjaWZpYyBTVFVOIGFu ZCBUVVJOIHNlcnZlcnMuICBUaGlzIHNob3VsZCBiZSBwb3NzaWJsZSB0bw0KICBhY2hpZXZlIGJ5 IGF1dG8tY29uZmlndXJhdGlvbiBtZXRob2RzLiAgVGhlIFJUQ1dFQiBmdW5jdGlvbmFsaXR5IHdp bGwNCiAgIG5lZWQgdG8gdXRpbGl6ZSBib3RoIG5ldHdvcmsgc3BlY2lmaWMgU1RVTiBhbmQgVFVS TiByZXNvdXJjZXMgYW5kDQogICBTVFVOIGFuZCBUVVJOIHNlcnZlcnMgcHJvdmlzaW9uZWQgYnkg dGhlIHdlYiBhcHBsaWNhdGlvbi4NCjMuMy41LjI8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0z LjMuNS4yPi4gIEFkZGl0aW9uYWwgUmVxdWlyZW1lbnRzDQogICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICBSRVEtSUQg ICAgICBERVNDUklQVElPTg0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgRjIwICAgICBUaGUgYnJvd3NlciBtdXN0 IHN1cHBvcnQgdGhlIHVzZSBvZiBTVFVOIGFuZCBUVVJODQogICAgICAgICAgIHNlcnZlcnMgdGhh dCBhcmUgc3VwcGxpZWQgYnkgZW50aXRpZXMgb3RoZXIgdGhhbg0KICAgICAgICAgICB0aGUgd2Vi IGFwcGxpY2F0aW9uIChpLmUuIHRoZSBuZXR3b3JrIHByb3ZpZGVyKS4NCiAgIC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K VGhlcmUgYXJlIGZ1cnRoZXIgcmVxdWlyZW1lbnQgbGlzdGVkLCBoZWxwaW5nIHVzIHRvIHVuZGVy c3RhbmQgdGhlIG5lZWQgZm9yIGF1dG8gZGlzY292ZXJ5IGFuZCBhIG5ldHdvcmsgcHJvdmlkZWQg VFVSTi1zZXJ2ZXIgc2hvdWxkIGJlIHVzZWQgdG8gRU5GT1JDRSB0aGF0IG1lZGlhIHRha2VzIHRo YXQgcGF0aCAoYW5kIHRodXMsIG90aGVyIHBhdGhzIGUuZy4gc3VnZ2VzdGVkIGJ5IHRoZSByZW1v dGUgTVVTVCBub3QgaGFwcGVuIHRvIGJlIHVzZWQpLiBUaGlzIGlzIHJlbGF0ZWQgdG8gdGhlIG1v YmlsaXR5IGFzcGVjdCAodmFsaWQgZXZlbiB3aXRob3V0IHRoZSByb2FtaW5nIGlkZWEpOg0KMy4z LjY8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2Vz LWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNj4uICBTaW1wbGUgVmlkZW8gQ29tbXVu aWNhdGlvbiBTZXJ2aWNlLCBhY2Nlc3MgY2hhbmdlDQozLjMuNi4xPGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0 I3NlY3Rpb24tMy4zLjYuMT4uICBEZXNjcmlwdGlvbg0KDQogICBUaGlzIHVzZS1jYXNlIGlzIGFs bW9zdCBpZGVudGljYWwgdG8gdGhlDQoNCiAgIFNpbXBsZSBWaWRlbyBDb21tdW5pY2F0aW9uIFNl cnZpY2UgdXNlLWNhc2UgKFNlY3Rpb24gMy4zLjE8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0z LjMuMT4pLiAgVGhlDQoNCiAgIGRpZmZlcmVuY2UgaXMgdGhhdCB0aGUgdXNlciBjaGFuZ2VzIG5l dHdvcmsgYWNjZXNzIGR1cmluZyB0aGUNCg0KICAgc2Vzc2lvbi4NCg0KDQoNCiAgIFRoZSBjb21t dW5pY2F0aW9uIGRldmljZSB1c2VkIGJ5IG9uZSBvZiB0aGUgdXNlcnMgaGFzIHNldmVyYWwgbmV0 d29yaw0KDQogICBhZGFwdGVycyAoRXRoZXJuZXQsIFdpRmksIENlbGx1bGFyKS4gIFRoZSBjb21t dW5pY2F0aW9uIGRldmljZSBpcw0KDQogICBhY2Nlc3NpbmcgdGhlIEludGVybmV0IHVzaW5nIEV0 aGVybmV0LCBidXQgdGhlIHVzZXIgaGFzIHRvIHN0YXJ0IGENCg0KICAgdHJpcCBkdXJpbmcgdGhl IHNlc3Npb24uICBUaGUgY29tbXVuaWNhdGlvbiBkZXZpY2UgYXV0b21hdGljYWxseQ0KDQogICBj aGFuZ2VzIHRvIHVzZSBXaUZpIHdoZW4gdGhlIEV0aGVybmV0IGNhYmxlIGlzIHJlbW92ZWQgYW5k IHRoZW4gbW92ZXMNCg0KICAgdG8gY2VsbHVsYXIgYWNjZXNzIHRvIHRoZSBJbnRlcm5ldCB3aGVu IG1vdmluZyBvdXQgb2YgV2lGaSBjb3ZlcmFnZS4NCg0KICAgVGhlIHNlc3Npb24gY29udGludWVz IGV2ZW4gdGhvdWdoIHRoZSBhY2Nlc3MgbWV0aG9kIGNoYW5nZXMuDQoNCjMuMy42LjI8aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1 aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNi4yPi4gIEFkZGl0aW9uYWwgUmVxdWlyZW1lbnRzDQoN CiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KICAgUkVRLUlEICAgICAgREVTQ1JJUFRJT04NCg0KICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQogICBGMTcgICAgIFRoZSBjb21tdW5pY2F0aW9uIHNlc3Npb24gbXVzdCBzdXJ2aXZlIGFjcm9z cyBhDQoNCiAgICAgICAgICAgY2hhbmdlIG9mIHRoZSBuZXR3b3JrIGludGVyZmFjZSB1c2VkIGJ5 IHRoZQ0KDQogICAgICAgICAgIHNlc3Npb24NCg0KICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQozLjMuNzxodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVp cmVtZW50cy0xNCNzZWN0aW9uLTMuMy43Pi4gIFNpbXBsZSBWaWRlbyBDb21tdW5pY2F0aW9uIFNl cnZpY2UsIFFvUw0KMy4zLjcuMTxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xNCNzZWN0aW9uLTMuMy43LjE+LiAg RGVzY3JpcHRpb24NCg0KICAgVGhpcyB1c2UtY2FzZSBpcyBhbG1vc3QgaWRlbnRpY2FsIHRvIHRo ZQ0KDQogICBTaW1wbGUgVmlkZW8gQ29tbXVuaWNhdGlvbiBTZXJ2aWNlLCBhY2Nlc3MgY2hhbmdl IHVzZS1jYXNlDQoNCiAgIChTZWN0aW9uIDMuMy42PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0I3NlY3Rpb24t My4zLjY+KS4gIFRoZSB1c2Ugb2YgUXVhbGl0eSBvZiBTZXJ2aWNlIChRb1MpIGNhcGFiaWxpdGll cyBpcw0KDQogICBhZGRlZDoNCg0KDQoNCiAgIFRoZSB1c2VyIGluIHRoZSBwcmV2aW91cyB1c2Ug Y2FzZSB0aGF0IHN0YXJ0cyBhIHRyaXAgaXMgYmVoaW5kIGENCg0KICAgY29tbW9uIHJlc2lkZW50 aWFsIHJvdXRlciB0aGF0IHN1cHBvcnRzIHByaW9yaXRpemF0aW9uIG9mIHRyYWZmaWMuDQoNCiAg IEluIGFkZGl0aW9uLCB0aGUgdXNlcidzIHByb3ZpZGVyIG9mIGNlbGx1bGFyIGFjY2VzcyBoYXMg UW9TIHN1cHBvcnQNCg0KICAgZW5hYmxlZC4gIFRoZSB1c2VyIGlzIGFibGUgdG8gdGFrZSBhZHZh bnRhZ2Ugb2YgdGhlIFFvUyBzdXBwb3J0IGJvdGgNCg0KICAgd2hlbiBhY2Nlc3NpbmcgdmlhIHRo ZSByZXNpZGVudGlhbCByb3V0ZXIgYW5kIHdoZW4gdXNpbmcgY2VsbHVsYXIuDQoNCjMuMy43LjI8 aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFu ZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNy4yPi4gIEFkZGl0aW9uYWwgUmVxdWlyZW1l bnRzDQoNCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgUkVRLUlEICAgICAgREVTQ1JJUFRJT04NCg0KICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQogICBGMTcgICAgIFRoZSBjb21tdW5pY2F0aW9uIHNlc3Npb24gbXVzdCBzdXJ2aXZl IGFjcm9zcyBhDQoNCiAgICAgICAgICAgY2hhbmdlIG9mIHRoZSBuZXR3b3JrIGludGVyZmFjZSB1 c2VkIGJ5IHRoZQ0KDQogICAgICAgICAgIHNlc3Npb24NCg0KICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICBGMjIg ICAgIFRoZSBicm93c2VyIG11c3QgYmUgYWJsZSB0byByZWNlaXZlIHN0cmVhbXMgYW5kDQoNCiAg ICAgICAgICAgZGF0YSBmcm9tIG11bHRpcGxlIHBlZXJzIGNvbmN1cnJlbnRseS4NCg0KICAgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQpGdXJ0aGVyIGZyb20gdGhlIFJUQ1dFQiBtYWlsaW5nIGxpc3QgU2VwdGVtYmVyIDIw dGggKGJ5IG1lKToNCg0KDQpUaGVyZSBhcmUgc2V2ZXJhbCByZWFzb25zIGZvciBhIG5ldHdvcmsg c2VydmljZSBwcm92aWRlciB0byBzdXBwbHkgYSBUVVJOIHNlcnZlciBhcyBwYXJ0IG9mIGhpcyBv ZmZlcmVkIGFjY2VzczoNCg0KLSB0byBrZWVwIG1lZGlhIHBhdGhzIHNob3J0LCBzcGVjaWZpY2Fs bHkgbm90IHNlbmRpbmcgbWVkaWEgb3V0c2lkZSBpdHMgb3duIG5ldHdvcmsgdG8gc29tZSBkaXN0 YW50IGFwcGxpY2F0aW9uIHByb3ZpZGVkIFRVUk4gc2VydmVyDQoNCi0gdG8gc3VwcG9ydCBtb2Jp bGl0eSwgaS5lLiB5b3UgbWF5IHdhbnQgdG8gbW92ZSBmcm9tIGEgTEFOIHdpdGggYSBjb25maWd1 cmVkIFRVUk4gc2VydmVyIHRvIGFjY2Vzc2luZyB2aWEgV2lGaSBvciAzRy80RyBPVFQgY2hhbm5l bHMNCg0KLSB0byBvZmZlciBhIG1lZGlhIHBhdGggd2l0aCBiZXR0ZXIgcXVhbGl0eSAodGhhbiBi ZXN0IGVmZm9ydCBkYXRhIHRyYWZmaWMpLg0KDQpHZXR0aW5nIOKAnFdlYlJUQy1yZWFkeeKAnSBh Y2Nlc3MgYW5kIHdlIGxvb2sgZm9yd2FyZCB0byB0ZWxlcHJlc2VuY2UgZm9yIGV2ZXJ5b25lLg0K DQoNCkkgaG9wZSB0aGlzIChhIGJpdCBsZW5ndGh5KSBzdW1tYXJ5IG9mIGFscmVhZHkgdGhvdWdo dC1vdXQgYW5kIGRpc2N1c3NlZCBhc3BlY3RzL3JlcXVpcmVtZW50cyB3aWxsIGhlbHAgdXMgdW5k ZXJzdGFuZCB0aGF0IHRoZSBhdXRvLWRpc2NvdmVyZWQgVFVSTiBzZXJ2ZXIgaXMgYW4gT1JERVIg ZnJvbSB0aGUgZW50ZXJwcmlzZSBhbmQvb3IgdGhlIE5TUC9JU1AgIHRvIHNlbmQgdGhlIG1lZGlh IHRocm91Z2ggdGhpcyBUVVJOIHBhdGgsIGFuZCB0aGF0IG90aGVyIG1lZGlhIHBhdGhzIHRoYXQg bWF5IGV4aXN0IE1VU1QgTk9UIEJFIFVTRUQuIChUaGF0IGlzIHdoeSB3ZSBlc3BlY2lhbGx5IGhh dmUgdG8gd2F0Y2gvYWR2aWNlIHRoYXQgd29ya2FibGUgbWVkaWEgcGF0aHMgcHJvcG9zZWQgYnkg dGhlIHJlbW90ZSBwYXJ0eSBub3QgYmVjb21lcyB1c2VkIOKAnGJ5IGFjY2lkZW504oCdLg0KDQov S2FybA0KDQoNCkZyw6VuOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpIFttYWlsdG86dGly ZWRkeUBjaXNjby5jb21dDQpTa2lja2F0OiBkZW4gMTMgZmVicnVhcmkgMjAxNCAwNDozNw0KVGls bDogSHV0dG9uLCBBbmRyZXc7IEp1c3RpbiBVYmVydGk7IE11dGh1IEFydWwgTW96aGkgUGVydW1h bCAobXBlcnVtYWwpDQpLb3BpYTogdGlyZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGlj aXNjby5jb20+OyBTaW1vbiBQZXJyZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsgdHJhbUBpZXRmLm9y ZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IE1hcmMgQmxhbmNoZXQ7IERhbiBXaW5nIChkd2luZyk7 IEthcmwgU3RhaGwNCsOEbW5lOiBSRTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBh dXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KSGkgQW5k eSwNCg0KVGhlcmUgYXJlIG90aGVyIHdheXMgdG8gc29sdmUgdGhlIHByb2JsZW0gZm9yIGV4YW1w bGUgdXNpbmcgUENQLiBDYW4geW91IGNsYXJpZnkgaG93IGRlcGxveWluZyBhIFRVUk4gc2VydmVy IGluIHRoZSBFbnRlcnByaXNlIHByb3RlY3RzIHRoZSB1c2VycyBhbmQgdGhlIG5ldHdvcmsgPw0K DQotVGlydS4NCkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBIdXR0b24sIEFuZHJldw0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE0 IDE6MDAgQU0NClRvOiBKdXN0aW4gVWJlcnRpOyBNdXRodSBBcnVsIE1vemhpIFBlcnVtYWwgKG1w ZXJ1bWFsKQ0KQ2M6IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29t PjsgU2ltb24gUGVycmVhdWx0OyBPbGVnIE1vc2thbGVua287IHRyYW1AaWV0Zi5vcmc8bWFpbHRv OnRyYW1AaWV0Zi5vcmc+OyBNYXJjIEJsYW5jaGV0OyBEYW4gV2luZyAoZHdpbmcpOyBLYXJsIFN0 YWhsDQpTdWJqZWN0OiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRp c2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0KVGhlIGNhc2Ugd2hl cmUgdGhlIFRVUk4gc2VydmVyIGlzIHRoZSBvbmx5IG9wdGlvbiBtYXkgYmVjb21lIGNvbW1vbiB3 aXRoaW4gZW50ZXJwcmlzZSBuZXR3b3JrcyBhbmQgdGhhdCBtaWdodCBiZSBkZWxpYmVyYXRlIGVu dGVycHJpc2UgcG9saWN5IGJlY2F1c2UgaXQgcHJvdmlkZXMgdGhlIGJldHRlciBwYXRoIChVRFAg dGhyb3VnaCB0aGUgRi9XKSBhbmQgcHJvdGVjdHMgdGhlIHVzZXJzIGFuZCB0aGUgbmV0d29yay4N Cg0KQW5keQ0KDQoNCkZyb206IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBKdXN0aW4gVWJlcnRpDQpTZW50OiAxMiBGZWJydWFyeSAyMDE0IDE3OjQ2DQpU bzogTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCkNCkNjOiB0aXJlZGR5QGljaXNj by5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT47IFNpbW9uIFBlcnJlYXVsdDsgT2xlZyBN b3NrYWxlbmtvOyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPjsgTWFyYyBCbGFu Y2hldDsgRGFuIFdpbmcgKGR3aW5nKTsgS2FybCBTdGFobA0KU3ViamVjdDogUmU6IFt0cmFtXSBN aWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRl cnByaXNlIGFuZCBJU1BzDQoNCkFncmVlLiBJZiBUVVJOIGlzIGluZGVlZCBiZWluZyBwcm92aWRl ZCBmb3IgdGhlIHVzZXIncyBiZW5lZml0LCB0aGUgY2xpZW50J3MgSUNFIGxvZ2ljIChiYXNlZCBv biBSVFQgb3Igc2ltaWxhcikgc2hvdWxkIHJlc3VsdCBpbiBpdCBwcmVmZXJyaW5nIHRoZSBUVVJO IHBhdGguDQoNCk9uIFdlZCwgRmViIDEyLCAyMDE0IGF0IDE6MjcgQU0sIE11dGh1IEFydWwgTW96 aGkgUGVydW1hbCAobXBlcnVtYWwpIDxtcGVydW1hbEBjaXNjby5jb208bWFpbHRvOm1wZXJ1bWFs QGNpc2NvLmNvbT4+IHdyb3RlOg0KWWVzLCBJIGJlbGlldmUgdGhlIHNlY29uZCBjYXNlIGlzIHJh cmUsIGJ1dCB3b3VsZCBiZSBiZXR0ZXIgdGhhbiBhIHJhdCByYWNlIGIvdyBhZG1pbmlzdHJhdG9y cyB0cnlpbmcgdG8gYmxvY2sgcDJwIHRyYWZmaWMgYW5kIGZvcmNlIGl0IHRocm91Z2ggYSBUVVJO IHNlcnZlciBhbmQgYXBwcy9lbmRwb2ludHMgZmluZGluZyBzbWFydGVyIHdheXMgdG8gYnlwYXNz IHRoZW0uDQoNCk11dGh1DQoNCkZyb206IE9sZWcgTW9za2FsZW5rbyBbbWFpbHRvOm1vbTA0MDI2 N0BnbWFpbC5jb208bWFpbHRvOm1vbTA0MDI2N0BnbWFpbC5jb20+XQ0KU2VudDogV2VkbmVzZGF5 LCBGZWJydWFyeSAxMiwgMjAxNCAxOjA3IFBNDQpUbzogTXV0aHUgQXJ1bCBNb3poaSBQZXJ1bWFs IChtcGVydW1hbCkNCkNjOiBKdXN0aW4gVWJlcnRpOyBLYXJsIFN0YWhsOyB0aXJlZGR5QGljaXNj by5jb208bWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbT47IE1hcmMgQmxhbmNoZXQ7IHRyYW1AaWV0 Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+OyBEYW4gV2luZyAoZHdpbmcpOyBTaW1vbiBQZXJy ZWF1bHQNCg0KU3ViamVjdDogUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0 by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNClRoZSBUVVJO IHNlcnZlciBoYXMgdG8gYmUgdXNlZCB3aGVuIGl0IGlzIGVpdGhlciB0aGUgb25seSBvcHRpb24s IG9yIGlmIGl0IHByb3ZpZGVzIGEgYmV0dGVyIHBhdGggKEkgZ3Vlc3MgdGhlIHNlY29uZCBjYXNl IGlzIHJhdGhlciByYXJlKS4NCg0KT24gVHVlLCBGZWIgMTEsIDIwMTQgYXQgMTE6MzIgUE0sIE11 dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpIDxtcGVydW1hbEBjaXNjby5jb208bWFp bHRvOm1wZXJ1bWFsQGNpc2NvLmNvbT4+IHdyb3RlOg0KKzENCg0KRm9yY2luZyBhbGwgdHJhZmZp YyB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIgYW5kIGV4cGVjdGluZyBpdCB3b3VsZCBwcm92aWRlIHRo ZSBiZXN0IHVzZXIgZXhwZXJpZW5jZSBkb2Vzbid0IGxvb2sgdGhlIHJpZ2h0IGFwcHJvYWNoLiBJ bnN0ZWFkLCBpZiBhIHBhdGggdGhyb3VnaCBhIFRVUk4gc2VydmVyIGV4aXN0cyBhbmQgZG9lcyBw cm92aWRlIGxvd2VyIFJUVCwgaml0dGVyIGV0YywgYmVpbmcgYWJsZSB0byBkZXRlY3QgYW5kIHVz ZSAob3Igc3dpdGNoIHRvKSB0aGF0IHBhdGggbWlnaHQgYmUgZGVzaXJhYmxlLi4NCg0KTXV0aHUN Cg0KRnJvbTogdHJhbSBbbWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dHJhbS1i b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEp1c3RpbiBVYmVydGkNClNlbnQ6IFdlZG5l c2RheSwgRmVicnVhcnkgMTIsIDIwMTQgMTE6NDMgQU0NClRvOiBLYXJsIFN0YWhsDQpDYzogdGly ZWRkeUBpY2lzY28uY29tPG1haWx0bzp0aXJlZGR5QGljaXNjby5jb20+OyBNYXJjIEJsYW5jaGV0 OyB0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPjsgRGFuIFdpbmcgKGR3aW5nKTsg U2ltb24gUGVycmVhdWx0DQpTdWJqZWN0OiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNl cnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHMNCg0K SW5saW5lLg0KDQpPbiBUdWUsIEZlYiAxMSwgMjAxNCBhdCAyOjM3IFBNLCBLYXJsIFN0YWhsIDxr YXJsLnN0YWhsQGludGVydGV4LnNlPG1haWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlPj4gd3Jv dGU6DQpMaXN0ZW5pbmcgdG8gdGhpcyB0aHJlYWQsIEkgYW0gYWZyYWlkIHdlIGFyZSBtaXNzaW5n IHRoZSB2ZXJ5IHBvaW50IGFuZCBuZWNlc3NpdHkgZm9yIHRoaXMgbWlsZXN0b25lIQ0KLSBUaGVy ZSBhcmUgc2V2ZXJlIE5BVCB0cmF2ZXJzYWwgYW5kIHF1YWxpdHkgaXNzdWVzIHRoYXQgc2hvdWxk IGFuZCBjYW4gYmUgZGVhbHQgd2l0aCBieSBhIGdvb2QgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNt IGFuZCB0aGUgcmlnaHQgdXNhZ2UgYnkgdGhlIHR1cm4gY2xpZW50ICh0aGUgV2ViUlRDIGJyb3dz ZXIpDQoNClRoZXJlIGFyZSB3YXlzLCBub3Qgb25seTogRW50ZXJwcmlzZXMgb3IgSVNQcyB3aXNo aW5nIHRvIHByb3ZpZGUgdGhlaXIgb3duIFRVUk4gc2VydmVyLCBpbiBhbiBhdHRlbXB0IHRvIHJl ZHVjZSBzby1jYWxsZWQgInRyaWFuZ2xlIHJvdXRpbmciLG5lZWQgYSBuZXcgYXV0by1kaXNjb3Zl cnkgbWVjaGFuaXNtDQpCdXQgYWxzbzogLSBOU1BzIChOZXR3b3JrIFNlcnZpY2UgUHJvdmlkZXJz KSB3YW50IHRvIHByb3ZpZGUgYSBwYXRoIHdoZXJlIHRoZSBiYW5kd2lkdGggb2YgV2ViUlRDIGlz IGJldHRlciBjb3BlZCB3aXRoLg0KLSBOU1BzIG9yIEVudGVycHJpc2VzIHdhbnQgdG8gb2ZmZXIg YW4gSW50ZXJuZXQgYWNjZXNzIHF1YWxpdHkgcGlwZSBmb3IgcHJpb3JpdGl6ZWQgUlRDIChSZWFs IFRpbWUgQ29tbXVuaWNhdGlvbikgdHJhZmZpYy4NCi0gRW50ZXJwcmlzZXMgaGF2aW5nIHJlc3Ry aWN0aXZlIGZpcmV3YWxscywgd2FudCB0byBwcm92aWRlIGEgVURQLXBhdGggZm9yIFdlYlJUQyBh bmQgcG9zc2libHkgYWxzbyBmb3IgYmV0dGVyIHF1YWxpdHkgd2hlcmUgUlRDIGRvIG5vdCBjb21w ZXRlIHdpdGggZGF0YSB0cmFmZmljLg0KQWxzbyBjb25zaWRlcmluZw0KLSBNb2JpbGl0eTsgSXQg aXMgY29tbW9uIHRvIG1vdmUgZnJvbSBhIExBTiB0byBhY2Nlc3NpbmcgdmlhIFdpRmkgb3IgM0cv NEcgT1RUIGNoYW5uZWxzLCBhbGwgc2hvdWxkIGJlIGFibGUgdG8gYXV0b21hdGljYWxseSBvZmZl ciB0aGVpciBvd24gb3B0aW1hbCBUVVJOIHNlcnZlcg0KDQpUaGlzIGxlYWRzIHVzIGludG8gIOKA nFRVUk7igKZ0byBpZGVudGlmeSBXZWJSVEMgZmxvd3PigJ0gZXRjISBJdCBpcyBub3QgYSBtaXN0 YWtlLCBidXQgdGhlIHZlcnkgbmVlZCBmb3IgdGhpcyBtaWxlc3RvbmUhDQoNCkFnYWluLCBpdCBo YXMgbm90IGJlZW4gZGVtb25zdHJhdGVkIHdoeSBUVVJOIGlzIHRoZSByaWdodCB0ZWNobm9sb2d5 IGhlcmUsIGNvbXBhcmVkIHRvIGEgbW9yZSB0cmFuc3BhcmVudCBmbG93IGlkZW50aWZpY2F0aW9u IHRvb2wgbGlrZSBNQUxJQ0UuIFdlIGRvbid0IGZvcmNlIGFsbCBIVFRQIHJlcXVlc3RzIHRvIGxv Y2F0ZSBhIEhUVFAgcHJveHkgdmlhIGFueWNhc3QsIEkgZG9uJ3Qgc2VlIHdoeSB3ZSBuZWVkIHRv IGRvIHRoZSBzYW1lIGZvciBXZWJSVEMuDQoNCldoYXQgYXJlIHRoZSBoZXNpdGF0aW9ucyByYWlz ZWQgaGVyZT8NCj4gVFVSTiBwcmltYXJpbHkgdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dzLCBhcyBv cHBvc2VkIHRvIHVzaW5nIGl0IGFzIGEgTkFUIHRyYXZlcnNhbCB0b29sLiBUaGlzIG1ha2VzIG1l IGNvbmNlcm5lZCB0aGF0IHdlIG1heSBiZSB1c2luZyB0aGUgd3JvbmcgdGVjaG5vbG9neSB0byBz b2x2ZSB0aGUgcHJvYmxlbQ0KSXQgaXMgY29ycmVjdCB0aGF0IElDRS9TVFVOL1RVUk4gd2FzIGRl c2lnbmVkIHRvIGFkZHJlc3MgdGhlIE5BVC9GaXJld2FsbCB0cmF2ZXJzYWwgcHJvYmxlbSBhc3Nv Y2lhdGVkIHdpdGggcmVhbC10aW1lIGNvbW11bmljYXRpb24gKFNJUCBhdCB0aGF0IHRpbWUpLiBI b3dldmVyLCBpdHMgbGFyZ2VzdCBmbGF3L3Byb2JsZW0gaXMgdGhhdCBxdWFsaXR5IHRoaW5ncyB3 ZXJlIG5vdCAoY291bGQgbm90IGJlPykgY29uc2lkZXJlZC4gVGhlIG1ldGhvZOKAmXMgdmVyeSBp ZGVhIChsaWtlIGFsbCBzaW1pbGFyIG1ldGhvZHMgZm9yIGdldHRpbmcgUlRDIHRocm91Z2ggb3Jk aW5hcnkgTkFUL0ZpcmV3YWxscykgaXMgdG8gZm9vbCB0aGUgbWVkaWEgdGhyb3VnaCBhIE5BVC9G aXJld2FsbCB0aGF0IGlzIHVuYXdhcmUgb2Ygd2hhdCBpcyBoYXBwZW5pbmcuIFRodXMsIHRoaXMg aXMgcm9vdCBvZiBxdWFsaXR5IGlzc3VlcyAoYW5kIGJhbmR3aWR0aCBhbGxvY2F0aW9uIG9wdGlt aXphdGlvbikgdGhhdCBuZWVkcyB0byBiZSBkZWFsdCB3aXRoOiBSZWFsLXRpbWUgdHJhZmZpYyBm aWdodGluZyB3aXRoIGEgZGF0YSB0cmFmZmljIGNyb3dkZWQgY29uZ2VzdGlvbiBwb2ludC4NCg0K SSB0aGluayB0aGF0ICJmb29saW5nIiBpcyBhbiBpbmNvcnJlY3QgZGVzY3JpcHRpb24uIFRoZSBO QVQgaXMgc3VwcG9zZWQgdG8gYmUgdHJhbnNwYXJlbnQgdG8gdGhlIGNsaWVudC4NCg0KQnV0LCBh IEJMRVNTSU5HIG9mIElDRS9TVFVOL1RVUk4gaXMgdGhhdCBpdCBjYW4gYmUgc2VlbiBhcyBhIGxl Z2l0aW1hdGUgcmVxdWVzdCBmb3IgYSBzdWl0YWJsZSBwaXBlIGZvciBxdWFsaXR5IGRlbWFuZGlu ZyByZWFsIHRpbWUgdHJhZmZpYy4g4pi6DQpJQ0UgaXMgYSBwcmUtcHJvdG9jb2wgeW91IHVzZSBi ZWNhdXNlIHlvdSB3YW50IGEgcGF0aCBmb3IgcmVhbC10aW1lIG1lZGlhIGJldHdlZW4gcGFydGll cy4gSGVyZTogVGhlIGJyb3dzZXIgc2F5cyBrbm9jayBrbm9jaywgSSB3YW50IHRvIGdldCBtZWRp YSB0aHJvdWdoIChhbmQgb2YgY291cnNlIHdpdGggYXMgZ29vZCBxdWFsaXR5IGFzIHJlcXVpcmVk IGFuZCBwb3NzaWJsZSkuDQoNCklmIHRoZSBOQVQvRmlyZXdhbGwgb3duZXIgYW5kIG5ldHdvcmsg b3duZXIgYXJlIGFsbG93ZWQgdG8gc2VlIHRoZXNlIHJlcXVlc3RzLCB0aGV5IGNhbiBoZWxwL2Fz c2lzdCBpbiBhY2hpZXZpbmcgdGhlIGdvb2QgbWVkaWEgcGF0aC4gSWYgdGhleSBhcmUgbm90IGF3 YXJlLCB0aGV5IGNhbm5vdCBoZWxwIQ0KDQpIb3BlIHRoaXMgbWFkZSBpdCB1bmRlcnN0YW5kYWJs ZSBvbiBhbiBvdmVydmlldyBsZXZlbCBob3cgdGhpcyBjYW4gYmVjb21lIOKAnFRVUk7igKZ0byBp ZGVudGlmeSBXZWJSVEMgZmxvd3PigJ0NCkl0IGlzIGFsc28gdGhlIE9OTFkgd2F5IEkgY2FuIHNl ZSB0byBhY2hpZXZlIHdoYXQgd2Ugd2FudCB0byBhY2hpZXZlIGFuZCBzaG91bGQgYmUgdGhlIGFp bSBhbmQgcmVxdWlyZW1lbnQgb2YgdGhpcyBtaWxlc3RvbmUuDQoNCkkgYW0gdGFsa2luZyBhYm91 dCBnZW5lcmFsIHVzYWdlIG9mIFdlYlJUQyBvdmVyIEludGVybmV0L21vYmlsZSBPVFQgKG5vdCBm ZWVkaW5nIFdlYlJUQyBpbnRvIGFwcGxpY2F0aW9uIHNwZWNpZmljIG5ldHdvcmtzIGxpa2UgSU1T IHdoZXJlIG90aGVyIG1ldGhvZHMgbWF5IGV4aXN0KS4NCg0KVGhpcyBpcyBnb29kLCBub3QgZXZp bCENCg0KSWYgdGhlIGhlc2l0YXRpb25zIGFyZSByYWlzZWQgYmVjYXVzZSBvZiBhIGJlbGllZi9o b3BlL3dpc2ggdGhhdCB0aGVyZSBhcmUgbm8gb3Igd2lsbCBub3QgYmUgc2V2ZXJlIHF1YWxpdHkg aXNzdWVzIOKAnGJlY2F1c2UgaXQgaXMgYWxsIGFib3V0IGJhbmR3aWR0aOKAnSwg4oCcaXQgd2ls bCByZXNvbHZlIGl0c2VsZiB3aXRoIHRpbWXigJ0gZXRjLiwgSSBzdHJvbmdseSBvYmplY3QhIFRo YXQgaXMgd3JvbmcgYW5kIHdpbGwgYmUgdmVyeSBkZXRyaW1lbnRhbCBmb3IgV2ViUlRDIHVzYWdl LiBXZSBhbHJlYWR5IHNlZSBpdCBhbmQgSSBjYW4gZ2l2ZSBudW1lcm91cyBleGFtcGxlcyBvZiBo b3cgbXVjaCBsZXNzIHF1YWxpdHkgZGVtYW5kaW5nIFZvSVAgaXMvaXMgbm90IGhhbmRsZWQgcXVh bGl0eSB3aXNlIGFuZCB0aGF0IGl0IG1hdHRlcnMuIEFuZCwgd2hhdCB3b3VsZCBiZSBiYWQgY29u c2lkZXJpbmcgcXVhbGl0eSBpc3N1ZXMgYW5kIGFsbG93aW5nL2VuY291cmFnaW5nIG1ldGhvZHMg dG8gZGVhbCB3aXRoIHRoZW0/DQoNCklmIHRoZSBoZXNpdGF0aW9ucyBhcmUgcmFpc2VkLCBiZWNh dXNlIG9mIHN1c3BpY2lvbiB0aGF0IHRoZSBtZXRob2RzIHdlIG1heSByZWNvbW1lbmQgbWF5IGJl IG1pc3VzZWQgdG8gc3RvcC9ibG9jay9kZXN0cm95IFdlYlJUQyB1c2FnZSAoZS5nLiB0byBwcm90 ZWN0IGluY29tZSBmcm9tIGNhcnJpZXIgdGVsZXBob255IHRyYWZmaWMpLCBJIGNvdWxkIHVuZGVy c3RhbmQgYW5kIHdvdWxkIGZpZ2h0IHRoZSBzYW1lIGJhdHRsZS4gQnV0IGhvcGVmdWxseSwgdGhv c2UgZGF5cyBhcmUgKHNvb24pIG92ZXIg4oCTIEF0IGxlYXN0IGZvcndhcmQgdGhpbmtpbmcgY2Fy cmllcuKAmXMgcmVhbGl6ZSB0aGF0IGFscmVhZHkuIFdlYiBSVEMgd2lsbCBoYXBwZW4uIFdoaWNo IGN1c3RvbWVycyB3YW50IHRvIHBheSBmb3IgYW4gYWNjZXNzIHdpdGggYmxvY2tlZCBXZWJSVEM/ IFRoZSBjYXJyaWVy4oCZcyBvZmZlcmluZy9hc3N1cmluZyBnb29kIFdlYlJUQyB3aWxsIHJhdGhl ciBnZXQgdGhlIGN1c3RvbWVycyBhbmQgaW5jb21lIOKYui4gKE1heWJlIHRoZSBXZWIgYnJvd3Nl ciBjYW4gZGV0ZWN0IGFuZCBlbmNvdXJhZ2UgdGhpc+KApikNCg0KSWYgdGhlcmUgYXJlIHRlY2hu aWNhbCBjb25jZXJucyBvZiBiYWQgcmVzdWx0LCBvciBiZXR0ZXIgbWV0aG9kcyBhbGxvd2luZyBu ZXR3b3JrIHByb3ZpZGVycyBhbmQgTEFOIG1hbmFnZXJzIHRvIG9mZmVyIGFuZCBpbmZvcm0gdGhl IGJyb3dzZXIgdGhhdCB0aGVyZSBhcmUgZ29vZCBtZWRpYSBwYXRocyB0byBiZSB1c2VkLCBhbmQg dGhhdCB0aGUgd2ViIGJyb3dzZXIgYXV0b21hdGljYWxseSBjYW4gY2hvc2UgdGhvc2UsIHRoZW4g bGV0IHVzIGFsbCB1bmRlcnN0YW5kIHRob3NlLCBzbyB3ZSBjYW4gYWNoaWV2ZSB3aGF0IHNob3Vs ZCBiZSBhY2hpZXZlZCBieSB0aGlzIG1pbGVzdG9uZS4NCg0KU2t5cGUsIEhhbmdvdXRzLCBGYWNl dGltZSBhcmUgZG9pbmcgYmlsbGlvbnMgb2YgbWludXRlcyBwZXIgd2VlayBhbmQgdGhlIEludGVy bmV0IGhhcyBub3QgbWVsdGVkIHlldC4gSWYgd2UgbmVlZCB0byBkbyBmbG93IGlkZW50aWZpY2F0 aW9uIHRvIGFsbG93IHRyYWZmaWMgdG8gYmUgcHJpb3JpdGl6ZWQsIGZpbmUgKHNlZSBhYm92ZSBy ZWdhcmRpbmcgbXkgcHJlZmVycmVkIGFwcHJvYWNoKSwgYnV0IGZvcmNpbmcgYWxsIFdlYlJUQyB0 cmFmZmljIHRocm91Z2ggYSBNSVRNIChUVVJOIHNlcnZlcikgaXMgYSBtdWNoIGJpZ2dlciBqdW1w IHRoYXQgSSBkb24ndCB5ZXQgc2VlIHRoZSBqdXN0aWZpY2F0aW9uIGZvci4NCg0KSW4gc2hvcnQ6 IFRVUk4gaXMgYSB0ZWNobm9sb2d5IHRoYXQgaXMgc3VwcG9zZWQgdG8gZmFkZSBhd2F5IHdpdGgg dGhlIG1vdmUgdG8gSVB2Ni4gSSBkb24ndCB0aGluayB3ZSB3YW50IHRvIG1ha2UgaXQgYSBjcml0 aWNhbCBlbGVtZW50IG9mIFdlYlJUQy4NCg0KL0thcmwNCg0KDQpGcsOlbjogRGFuIFdpbmcgW21h aWx0bzpkd2luZ0BjaXNjby5jb208bWFpbHRvOmR3aW5nQGNpc2NvLmNvbT5dDQpTa2lja2F0OiBk ZW4gMTEgZmVicnVhcmkgMjAxNCAxODoyNQ0KVGlsbDogTWFyYyBCbGFuY2hldA0KS29waWE6IEp1 c3RpbiBVYmVydGk7IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWlsdG86dGlyZWRkeUBpY2lzY28uY29t PjsgS2FybCBTdGFobDsgdHJhbUBpZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IFNpbW9u IFBlcnJlYXVsdA0KDQrDhG1uZTogUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIg YXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzDQoNCg0KT24g RmViIDExLCAyMDE0LCBhdCA5OjA4IEFNLCBNYXJjIEJsYW5jaGV0IDxtYXJjLmJsYW5jaGV0QHZp YWdlbmllLmNhPG1haWx0bzptYXJjLmJsYW5jaGV0QHZpYWdlbmllLmNhPj4gd3JvdGU6DQoNCkxl IDIwMTQtMDItMTEgw6AgMDA6MzksIERhbiBXaW5nIDxkd2luZ0BjaXNjby5jb208bWFpbHRvOmR3 aW5nQGNpc2NvLmNvbT4+IGEgw6ljcml0IDoNCg0KDQpPbiBGZWIgMTAsIDIwMTQsIGF0IDU6MzAg UE0sIEp1c3RpbiBVYmVydGkgPGp1YmVydGlAZ29vZ2xlLmNvbTxtYWlsdG86anViZXJ0aUBnb29n bGUuY29tPj4gd3JvdGU6DQoNCkdvb2QgdG8gc2VlIHRoZXJlIGlzIGEgbG90IG9mIGludGVyZXN0 IGZvciB0aGlzIG1pbGVzdG9uZS4gQnV0IGJhc2VkIG9uIHRoZSBkZXNjcmlwdGlvbiBoZXJlLCBp dCBzZWVtcyBsaWtlIHdlIHdhbnQgdG8gdXNlIFRVUk4gcHJpbWFyaWx5IHRvIGlkZW50aWZ5IFdl YlJUQyBmbG93cywgYXMgb3Bwb3NlZCB0byB1c2luZyBpdCBhcyBhIE5BVCB0cmF2ZXJzYWwgdG9v bC4gVGhpcyBtYWtlcyBtZSBjb25jZXJuZWQgdGhhdCB3ZSBtYXkgYmUgdXNpbmcgdGhlIHdyb25n IHRlY2hub2xvZ3kgdG8gc29sdmUgdGhlIHByb2JsZW0uDQoNCisxLg0KDQpJIHdvdWxkIHByZWZl ciBhbGxvd2luZyBmbG93cyB0byBlc3RhYmxpc2ggdGhlbXNlbHZlcyB1c2luZyB0aGVpciAnYmVz dCcgcGF0aCwgYW5kIHRoZSBiZXN0IHBhdGggaXMgc2VsZG9tIHRocm91Z2ggYSBUVVJOIHNlcnZl ci4gIFdoZW4gd2UgaW1hZ2luZSBJUHY2IGluIG91ciBmdXR1cmUsIHdlIGRvbid0IHdhbnQgdG8g Zm9yY2UgYW4gYXBwbGljYXRpb24tbGV2ZWwgcHJveHkgKFRVUk4pIHNlcnZlciBvbiB0aGUgcGF0 aCBzb2xlbHkgZm9yIHRyYXZlcnNpbmcgYW4gSVB2NiBmaXJld2FsbC4NCg0KDQpJdCBzZWVtcyB0 aGlzIHRocmVhZCBpcyBjb25mbGF0aW5nIGFsbCB0aGUgcG9zc2libGUgcmVhc29ucyAvIGp1c3Rp ZmljYXRpb25zIGZvciBUVVJOOg0KICAqIG1vYmlsaXR5DQogICogTkFUIHRyYXZlcnNhbCAoYm90 aCBlbmRwb2ludHMgYXJlIGJlaGluZCBlbmRwb2ludC1kZXBlbmRlbnQgbWFwcGluZyBOQVRzKQ0K ICAqIGZpcmV3YWxsIHRyYXZlcnNhbCAoZmlyZXdhbGwgYmxvY2tzIFVEUCkNCiAgKiBlbmhhbmNp bmcgcHJpdmFjeQ0KDQpVbmZvcnR1bmF0ZWx5IHRoZSBUVVJOIHNlcnZlciBub3IgdGhlIGVuZHBv aW50IHJlYWxseSBrbm93IHdoaWNoIG9mIHRob3NlIHVzZS1jYXNlcyBpcyBkZXNpcmVkIChieSB0 aGUgdXNlciBvciBieSB0aGUgSVQgbmV0d29yayBhZG1pbmlzdHJhdG9yKSBvciBuZWNlc3Nhcnkg KGZvciB0aGUgY2FsbCB0byB3b3JrIGF0IGFsbCkuDQoNCkRhbiwgd2hpbGUgSSBhZ3JlZSBpbiBw cmluY2lwbGUsIEkgZG91YnQgdGhhdCBhIHVzZXIgY291bGQgZXZlciBzYXkgIkkgd2FudCBtb2Jp bGl0eSBvciBJIHdhbnQgTkFUIHRyYXZlcnNhbCIuIEkgdGhpbmsgdGhlIHVzZXIgb25seSB3YW50 IHRoZSBjYWxsIHRvIHN1Y2NlZWQsIHdoYXRldmVyIHRoZSBwcm9wZXJ0aWVzIG9mIGl0cyBuZXR3 b3JrIHBvaW50IG9mIGF0dGFjaG1lbnQgYXJlLg0KDQpTbyB3aGF0IGNhbiB3ZSBkbz8gIFNob3Vs ZCB0aGUgVFVSTiBzZXJ2ZXIgcHJvdmlkZSBhbnkgYW5kIGFsbCBzZXJ2aWNlcyB0aGUgVFVSTiBj bGllbnQgbWlnaHQgcG9zc2libHkgd2FudCwgYXMgdGhhdCBpcyB3aGF0IGEgcm9idXN0IFRVUk4g c2VydmVyIHdpbGwgZG8sIGFuZCB0aGUgZW5kcG9pbnQgc2hvdWxkIHByZWZlciBUVVJOIGNhbmRp ZGF0ZXMgb3ZlciBhbGwgb3RoZXJzIGJlY2F1c2UgdGhlcmUgbWlnaHQgYmUgc29tZSBmdW5jdGlv bmFsaXR5IC8gdXNlZnVsbmVzcyBvZiBUVVJOIHRoYXQgdGhlIHVzZXIgbWlnaHQgZ2FpbiB0aHJv dWdoIFRVUk4gKGUuZy4sIGVuaGFuY2VkIHByaXZhY3kpPw0KDQotZA0KDQoNCg0KIFRoaXMgc2Vl bXMgcHJvYmxlbWF0aWMuICBQZXJoYXBzIHdlIG5lZWQgYSB3YXkgdG8gc2lnbmFsIHRoZSBkZXNp cmVkIHVzZS1jYXNlICgidHJhaXQiKSwgb3IgYXMgSnVzdGluIHN1Z2dlc3RzLCB1c2luZyBhIGRp ZmZlcmVudCB0ZWNobm9sb2d5IGZvciBzb21lIG9mIHRoZXNlIHVzZS1jYXNlcy4NCg0KLWQNCg0K DQoNCg0KT24gTW9uLCBGZWIgMTAsIDIwMTQgYXQgMzoxOCBQTSwgS2FybCBTdGFobCA8a2FybC5z dGFobEBpbnRlcnRleC5zZTxtYWlsdG86a2FybC5zdGFobEBpbnRlcnRleC5zZT4+IHdyb3RlOg0K U2ltb24sDQoNCkdvb2QgcXVlc3Rpb25zIC0gc2VlIGlubGluZSBiZWxvdyAtLT4gLg0KU29tZSBt b3JlIHRob3VnaHQgaXMgcmVxdWlyZWQhDQoNCi9LYXJsDQoNCi0tLS0tVXJzcHJ1bmdsaWd0IG1l ZGRlbGFuZGUtLS0tLQ0KRnLDpW46IHRyYW0gW21haWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZz5dIEbDtnIgU2ltb24gUGVycmVhdWx0DQpTa2lj a2F0OiBkZW4gMTAgZmVicnVhcmkgMjAxNCAxNToxNg0KVGlsbDogS2FybCBTdGFobDsgdHJhbUBp ZXRmLm9yZzxtYWlsdG86dHJhbUBpZXRmLm9yZz47IHRpcmVkZHlAaWNpc2NvLmNvbTxtYWlsdG86 dGlyZWRkeUBpY2lzY28uY29tPg0Kw4RtbmU6IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4g c2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQcw0K DQpLYXJsLA0KDQpJdCBpcyBncmVhdCB0byBzZWUgc3VjaCBlbnRodXNpYXNtISBUaGFua3MhDQoN CkkgaGF2ZSBhIGNvdXBsZSB0ZWNobmljYWwgcXVlc3Rpb25zLi4uDQoNCkxlIDIwMTQtMDItMDgg MDg6MTEsIEthcmwgU3RhaGwgYSDDqWNyaXQgOg0KPiAtIE5vdGUgdGhhdCB0byBhY2hpZXZlIHNv bWUgb2YgdGhlIGFib3ZlIHBvaW50cywgVFVSTiBtdXN0IGJlIGZhdm9yZWQNCj4gb3ZlciBTVFVO IHRvIGVuZm9yY2UgdGhhdCB0aGUgVFVSTi1wYXRoIGFjdHVhbGx5IGlzIHVzZWQuIChUaGUgQW55 Y2FzdA0KPiBtZXRob2Qgc3VnZ2VzdGVkIGJlbG93LCDigJxhdXRvbWF0aWNhbGx54oCdIGRvZXMg dGhpcy4pDQoNCkkgdW5kZXJzdGFuZCB0aGUgU1RVTiB2cyBUVVJOIHByaW9yaXR5IGlzc3VlLiBC dXQgSSBkb24ndCBzZWUgaG93IGFueWNhc3QgYWZmZWN0cyBpdCBpbiBhbnkgd2F5LiBDYW4geW91 IHBsZWFzZSBleHBsYWluPw0KLS0tIEdvb2QgcG9pbnQgLSBJIHdhcyBhIGJpdCBxdWljayBoZXJl IChtYXliZSB0b28gcXVpY2spDQpXZSBoYXZlIGdpdmVuIHRoaXMgcXVpdGUgYml0IG9mIHRob3Vn aHQsIHNpbmNlIGV2ZW4gaWYgYSBUVVJOIHNlcnZlciBpcyBwcm92aWRlZCBhbmQgZGlzY292ZXJl ZCwgQ1VSUkVOVCB1c2FnZSBvZiBJQ0UgbWF5IHN1Z2dlc3QgYSBjYW5kaWRhdGUgZnJvbSB0aGUg cmVtb3RlIHBhcnR5IHRoYXQgd2lsbCBtYWtlIGEgY29ubmVjdGlvbiB3aXRob3V0IHRoZSBuZWVk L3VzYWdlIG9mIHRoZSBUVVJOIHNlcnZlciAodGhhdCB3ZSB3YW50ZWQgdG8gYmUgdXNlZCBmb3Ig dGhlIGdvb2QgcHVycG9zZXMgbGlzdGVkKS4NCg0KVGhlIG9ubHkgd2F5IHdlIGZvdW5kIGFyb3Vu ZCB0aGlzLCB3YXMgdG8gc3RvcCBTVFVOIHRocm91Z2ggdGhlIElQIGRlZmF1bHQgZ2F0ZXdheSAo bGlrZSBhIHJlc3RyaWN0aXZlIEVudGVycHJpc2UgZmlyZXdhbGwgZG9lcyBpbmhpYml0aW5nIElD RSBjb25uZWN0aXZpdHksIHdoaWNoIG90aGVycyBhcmUgY29uY2VybmVkIGFib3V0Li4uKS4gU2lu Y2UgdGhlIHByb3Zpc2lvbmluZyBvZiBhdXRvLWRpc2NvdmVyeSB1c2luZyB0aGUgYW55Y2FzdCBt ZWNoYW5pc20sIHdvdWxkIGJlIGFkZGluZyBhIHJvdXRlIGluIGEgZGVmYXVsdCBnYXRld2F5LCBh ZGRpbmcgYSBmaXJld2FsbCBydWxlIHRvIGVhdCBTVFVOIHBhY2tldHMgd291bGQgYXNzdXJlIHRo YXQgdGhlIHByb3Zpc2lvbmVkIFRVUk4gc2VydmVyIGFjdHVhbGx5IGJlY29tZXMgdXNlZCAoYW5k IG5vdCBieXBhc3NlZCAiYnkgYWNjaWRlbnQiKS4gKFRoYXQgd2FzIHRoZSB0aG91Z2h0IGJlaGlu ZCB0aGUg4oCcYXV0b21hdGljYWxseeKAnSB3aXRoaW4gcXVvdGVzLikNCg0KQlVULCBzaW5jZSB5 b3UgYnJvdWdodCB1cCB0aGUgcXVlc3Rpb24sIGFzc3VtaW5nIHRoYXQgd2UgaGF2ZSB0aGUgcG93 ZXIgdG8gZW5mb3JjZSBXZWJSVEMgdXNhZ2Ugb2YgSUNFLCBJIGJlbGlldmUgYSBNVVNUIHJlcXVp cmVtZW50IHRvIHVzZSBhbiBhdXRvLWRpc2NvdmVyZWQgVFVSTiBzZXJ2ZXIgaW5zdGVhZCBvZiBT VFVOLCB3b3VsZCBzb2x2ZSB0aGUgc2FtZSBwcm9ibGVtLiBIb3dldmVyLCB0aGlua2luZyBmdXJ0 aGVyIChpbiByZWxhdGlvbiB0byB5b3VyIG5leHQgcXVlc3Rpb24gLSAiYW55b25lIGNvdWxkIHNl dCB1cCBhIGJhZGx5LW1haW50YWluZWQiIC0gZW5mb3JjaW5nIHN1Y2ggSUNFIHVzYWdlIG1heSBu b3QgYmUgZ29vZC4pDQoNCg0KPiAtIDNecmQgVGhlIEFueWNhc3QgbWV0aG9kIGJlbG93IOKAkyBJ IHNlZSBubyBwcm9ibGVtDQo+DQo+IEl0IGFsc28gaGFzIHRoZSBhZHZhbnRhZ2Ugb2YgZW5jb3Vy YWdpbmcgKGJ1dCBub3QgcmVxdWlyaW5nKSB0aGUNCj4gU1RVTi9UVVJOIHRvIGJlIGJ1aWx0IGlu IHRoZSBkZWZhdWx0IGdhdGV3YXkgb3IgTkFUL2ZpcmV3YWxsL2FjY2Vzcw0KPiByb3V0ZXIgaXRz ZWxmLCB3aXRoIGEgc2Vjb25kIGludGVyZmFjZSB0byBhIHB1YmxpYyBJUCBhZGRyZXNzIG9uIHRo ZQ0KPiBXQU4gc2lkZS4gKEN1cnJlbnQgdm9sdW1lIGRlcGxveWVkLCBsb3cgY29zdCBOU1AgdHJp cGxlIHBsYXkgbW9kZW1zDQo+IHVzdWFsbHkgaGF2ZSBhIHF1YWxpdHkgYXNzdXJlZCBsZXZlbCAy IG9yIGxldmVsIDMgV0FOIHBpcGUgZm9yIGp1c3QNCj4gdm9pY2UgKGFuZCBhbm90aGVyIGZvciBJ UFRWKSDigJMgVGhlIGFueWNhc3QgZGlzY292ZXJlZCBUVVJOLXNlcnZlciBjYW4NCj4gYmUgdGhl IGFjY2VzcyBnYXRld2F5IHRvIHN1Y2ggcXVhbGl0eSBwaXBlIGZvciBXZWJSVEMgbWVkaWEsIGlu IGENCj4gc2luZ2xlIE5TUCBwcm92aWRlZCBDUEUsIHNjYWxpbmcgZnJvbSByZXNpZGVudGlhbCBh bmQgdXAuKQ0KDQpTdXBwb3NlIHdlIGRlZmluZSB3ZWxsLWtub3duIGFueWNhc3QgVFVSTiBzZXJ2 ZXIgYWRkcmVzc2VzLiBIb3cgd291bGQgdGhpcyBub3QgYmUgc3ViamVjdCB0byB0aGUgc2FtZSBz ZXJ2aWNlIHF1YWxpdHkgaXNzdWVzIHRoYXQgcGxhZ3VlZCA2dG80PyBUaGF0IGlzLCBhbnlvbmUg Y291bGQgc2V0IHVwIGEgYmFkbHktbWFpbnRhaW5lZCwgdW5kZXItcHJvdmlzaW9uZWQgVFVSTiBz ZXJ2ZXIgYW5kIGFubm91bmNlIGl0IG92ZXIgQkdQIHRvIHRoZSB3b3JsZCwgYXMgaXQgd2FzIGRv bmUgZm9yDQo2dG80IHJlbGF5cy4gT3IganVzdCBiYWQgQkdQIG91dGJvdW5kIGZpbHRlciBjb25m aWd1cmF0aW9uLiBBbmQgaG93IGNhbiB3ZSBwcmV2ZW50IHRyaWFuZ2xlIHJvdXRpbmc/IFRoZXJl IGlzIG5vdGhpbmcgZ3VhcmFudGVlaW5nIHRoYXQgdGhlIGFueWNhc3Qgc2VydmVyIHlvdSBzZWUg aXMgYmVpbmcgcHJvdmlkZWQgdG8geW91IGJ5IHlvdXIgSVNQLCByYXRoZXIgdGhhbiBhIHNlcnZl ciBzaXR0aW5nIG9uIHRoZSBvdGhlciBzaWRlIG9mIHRoZSBwbGFuZXQuDQotLS0gR29vZCBwb2lu dCAtIG5lZWRzIHRvIGJlIHJlc29sdmVkLiBGb3IgdGhpcyBJIGRvbid0IGhhdmUgYSByZWFkeSBh bnN3ZXIuLi4NCkFuIGF1dG8tZGlzY292ZXJlZCBUVVJOIHNlcnZlciBtdXN0IGJlIHRydXN0ZWQg KHdoYXRldmVyIG1ldGhvZCBpdCBpcyBkaXNjb3ZlcmVkIGJ5KS4gV2UgYXJlIHRydXN0aW5nIHRo ZSBvbmUgcHJvdmlkaW5nIHVzIHdpdGggYW4gSVAgYWRkcmVzcyBhbmQgZGVmYXVsdCBnYXRld2F5 IGFueXdheS4gSXQgd291bGQgYmUgZWFzeSBpZiB3ZSBjb3VsZCByZXVzZSB0aGF0IHRydXN0LCBp bnN0ZWFkIG9mIGFub3RoZXIgbWVjaGFuaXNtcy4NCg0KSXMgdGhlcmUgYSBnb29kIHdheSBmb3Ig dGhlIGJyb3dzZXIgdG8gY2hlY2sgdGhhdCB0aGUgYW55Y2FzdCBhZGRyZXNzIGlzIG5vdCBoYW5k bGVkIGJleW9uZCB0aGUgbmV0d29yayBzZXJ2aWNlIHByb3ZpZGVyJ3MgZGVmYXVsdCBnYXRld2F5 PyBJZGVhcz8NCg0KDQoNClRoYW5rcywNClNpbW9uDQotLQ0KRFROIG1hZGUgZWFzeSwgbGVhbiwg YW5kIHNtYXJ0IC0tPiBodHRwOi8vcG9zdGVsbGF0aW9uLnZpYWdlbmllLmNhPGh0dHA6Ly9wb3N0 ZWxsYXRpb24udmlhZ2VuaWUuY2EvPg0KTkFUNjQvRE5TNjQgb3Blbi1zb3VyY2UgICAgICAgIC0t PiBodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYTxodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYS8+ DQpTVFVOL1RVUk4gc2VydmVyICAgICAgICAgICAgICAgLS0+IGh0dHA6Ly9udW1iLnZpYWdlbmll LmNhPGh0dHA6Ly9udW1iLnZpYWdlbmllLmNhLz4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxt YWlsdG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdHJhbQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnRyYW0gbWFpbGluZyBsaXN0 DQp0cmFtQGlldGYub3JnPG1haWx0bzp0cmFtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby90cmFtDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQp0cmFtIG1haWxpbmcgbGlzdA0KdHJhbUBpZXRmLm9yZzxtYWls dG86dHJhbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dHJhbQ0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KdHJhbSBtYWlsaW5nIGxpc3QNCnRyYW1AaWV0Zi5vcmc8bWFpbHRvOnRyYW1AaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg0KDQo= --_000_913383AAA69FF945B8F946018B75898A242AF62Fxmbrcdx10ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbWJyaWE7DQoJcGFu b3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNh bGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIg NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KaDQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI ZWFkaW5nIDQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDt9DQpoNQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNSBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7DQoJZm9udC13ZWlnaHQ6bm9ybWFsO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRp di5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uSGVhZGluZzRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7 DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgNCI7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJz ZXJpZiI7DQoJY29sb3I6IzRGODFCRDsNCglmb250LXdlaWdodDpib2xkOw0KCWZvbnQtc3R5bGU6 aXRhbGljO30NCnNwYW4uSGVhZGluZzVDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDUg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcg NSI7DQoJZm9udC1mYW1pbHk6IkNhbWJyaWEiLCJzZXJpZiI7DQoJY29sb3I6IzI0M0Y2MDt9DQpz cGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLlBsYWluVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseTpD b25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5SdWJyaWs0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUnVicmlrIDQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IlJ1YnJpayA0IjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KcC5SdWJyaWs0LCBsaS5SdWJy aWs0LCBkaXYuUnVicmlrNA0KCXttc28tc3R5bGUtbmFtZToiUnVicmlrIDQiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUnVicmlrIDQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uUnVicmlrNUNoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IlJ1YnJpayA1IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0K CW1zby1zdHlsZS1saW5rOiJSdWJyaWsgNSI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cglmb250LXdlaWdodDpib2xkO30NCnAuUnVicmlrNSwgbGkuUnVicmlrNSwgZGl2LlJ1YnJpazUN Cgl7bXNvLXN0eWxlLW5hbWU6IlJ1YnJpayA1IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IlJ1YnJpayA1IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkhUTUwtZnJmb3JtYXRlcmFkQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSFRNTCAtIGbDtnJmb3JtYXRlcmFkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCAtIGbDtnJmb3JtYXRlcmFkIjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnAuSFRNTC1mcmZvcm1hdGVyYWQsIGxpLkhUTUwtZnJmb3Jt YXRlcmFkLCBkaXYuSFRNTC1mcmZvcm1hdGVyYWQNCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgLSBm w7ZyZm9ybWF0ZXJhZCI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIC0gZsO2cmZvcm1hdGVyYWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uT2Zvcm1hdGVyYWR0ZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiT2Zvcm1hdGVyYWQgdGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6Ik9mb3JtYXRlcmFkIHRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnAuT2Zvcm1hdGVyYWR0ZXh0LCBsaS5PZm9ybWF0ZXJhZHRleHQsIGRpdi5PZm9ybWF0ZXJh ZHRleHQNCgl7bXNvLXN0eWxlLW5hbWU6Ik9mb3JtYXRlcmFkIHRleHQiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiT2Zvcm1hdGVyYWQgdGV4dCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5CYWxsb25ndGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvbmd0ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazpCYWxsb25ndGV4dDsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5CYWxsb25ndGV4dCwgbGkuQmFsbG9uZ3RleHQsIGRp di5CYWxsb25ndGV4dA0KCXttc28tc3R5bGUtbmFtZTpCYWxsb25ndGV4dDsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvbmd0ZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUzNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTM5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsdWU7fQ0K c3Bhbi5FbWFpbFN0eWxlNDANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymx1ZTt9DQpzcGFuLmdyZXkNCgl7bXNv LXN0eWxlLW5hbWU6Z3JleTt9DQpzcGFuLkVtYWlsU3R5bGU0Mg0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlNDMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6Ymx1ZTt9DQpzcGFuLkVt YWlsU3R5bGU0NA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SGkgS2FybCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+UGxlYXNlIHNlZSBp bmxpbmUgW1RSXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEthcmwgU3RhaGwgWzwvc3Bhbj48YSBocmVm PSJtYWlsdG86a2FybC5zdGFobEBpbnRlcnRleC5zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPm1haWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMTcs IDIwMTQgNjo0MSBQTTxicj4NCjxiPlRvOjwvYj4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5 KTsgRGFuIFdpbmcgKGR3aW5nKTsgUGFsIE1hcnRpbnNlbiAocGFsbWFydGkpPGJyPg0KPGI+Q2M6 PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFFvUyBmb3IgUlRDIG92ZXIgdGhlIEludGVy bmV0LCBESVNDVVNTOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292 ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaXJ1ICZndDsgSSBkaWQgbm90IGRpZCBub3QgdW5kZXJzdGFuZCBob3cg VFVSTiBzZXJ2ZXIgd2lsbCBpZGVudGlmeSBpZiBpdOKAmXMgV2ViUlRDIG1lZGlhIHN0cmVhbXMg b3IgZ2FtaW5nIHRyYWZmaWMgb3Igc29tZSBvdGhlciBkYXRhIHRyYWZmaWMgcmVsYXllZCB0aHJv dWdoDQogaXQgdG8gc2V0IHRoZSBkaWZmc2VydiBiaXRzIGNvcnJlY3RseSAhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj4tLS0gSSB0aGluayB5b3UgZG8gdW5kZXJzdGFuZOKApiDigJMgYnV0IEkg d2lsbCBzcGVsbCBvdXQgdGhhdCBESVNDVVNTL01BTElDRSBkb2VzIGl0IGJldHRlciBhbmQgd2l0 aCB1c2VmdWwgZGV0YWlsDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOmJsdWUiPko8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5Qw6VsLCBUaXJ1LCBEYW4gYW5k IHlvdSBvdGhlciB0aGlua2luZyBhYm91dCB0aGVzZSB0aGluZ3M6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPldoYXQgaGFzIGJlZW4gZGlz Y3Vzc2VkIGJ5IG1lIGhlcmUgc28gZmFyLCB0byBnaXZlIHVzIHF1YWxpdHkgb2YgcmVhbC10aW1l IHRyYWZmaWMgb3ZlciB0aGUgSW50ZXJuZXQgKG5vdCBhIHNtYWxsIHRhc2spIGlzOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4xKSBUbyBk aXJlY3QgdGhlIHJlYWwtdGltZSB0cmFmZmljIHRvIHdoZXJlIHRoZSBuZXR3b3JrIGNhbiBoYW5k bGUgc3VjaCB0cmFmZmljICh1c2luZyBhIG5ldHdvcmsgb2ZmZXJlZCBUVVJOIHNlcnZlcnMpICh3 aGljaCBpcyBub3Qgd2l0aGluIHRoZSBzY29wZSBvZiBESVNDVVNTKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W1RSXSBJ IHN0aWxsIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgbmVlZCB0byBmb3JjZSB0aGUgbWVkaWEgdHJh ZmZpYyB0byBiZSBzZW50IHRocm91Z2ggdGhlIFRVUk4gc2VydmVyIGVpdGhlciB3aXRoIERJU0NV U1Mgb3IgUENQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibHVlIj4yKSBXaGVuIHN1Y2ggYSBUVVJOIHNlcnZlciBmbG93IGlzIGFsbG9jYXRl ZCwgaXQgY2FuIEFTU1VNRSB0aGF0IGl0IGlzIGdvaW5nIHRvIHVzZWQgZm9yIHJlYWwtdGltZSB0 cmFmZmljIGFuZCBpbnN0cnVjdCB0aGUgbmV0d29yayAoZSBnIHZpYSBzZXR0aW5nIGRpZmZzZXJ2 ZSBiaXRzKQ0KIHRvIHByaW9yaXRpemUgdGhlIGFzc3VtZWQgcmVhbC10aW1lIHRyYWZmaWMuIChH aXZpbmcgdGhlIHNhbWUgcHJpb3JpdGl6YXRpb24gdG8gYWxsIFRVUk4gdHJhZmZpYyB3b3JrcyBx dWl0ZSB3ZWxsLiDigJMgT25seSBpZiB3ZSBmaWxsIHRoZSB3aG9sZSBwaXBlIHdpdGggcHJpb3Jp dGl6ZWQgdHJhZmZpYyAoYmVzdCBlZmZvcnQgdG90YWxseSBwdXNoZWQgb2ZmKSBpcyBpdCBpbXBv cnRhbnQgdGhhdCBlLmcuIHZvaWNlIGlmIHByaW9yaXRpemVkIGhpZ2hlcg0KIHRoYW4gdmlkZW8p LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+W1RSXSBUaGlzIGFzc3VtcHRpb24gaXMgbm90IHJpZ2h0IGFuZCBjb3VsZCBy ZXN1bHQgaW4gZmFsc2UgcG9zaXRpdmVzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjMpIFdoZW4gdGhlIFRVUk4gc2VydmVyIHNlZXMg dGhlIGZsb3cgY29taW5nIGluIChOb3RlOiBpbiBib3RoIGRpcmVjdGlvbnMpIGl0IGNhbiBkbyBz bWFydGVyIGd1ZXNzd29yayBvZiB3aGF0IHRyYWZmaWMgaXQgaXMgKGxpa2UgYSBEUEktYm94KSwg ZS5nLiB3aGF0IGlzIFJUUCBhbmQNCiB3aGF0IGlzIGRhdGEgY2hhbm5lbCB0byBpbnN0cnVjdCB0 aGUgbmV0d29yayBiZXR0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzAwMjA2MCI+W1RSXSBJIGRvbuKAmXQgdGhpbmsgRFBJIHdpbGwg aGVscCwgaG93IHdpbGwgdGhlIFRVUk4gc2VydmVyIGRpZmZlcmVudGlhdGUgYi93IGF1ZGlvIGFu ZCB2aWRlbyBzdHJlYW1zIHdoZW4gaXQgaXMgRFRMUy1TUlRQID8NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwMjA2MCI+RXZlbiB0aGUgSG9tZSBSb3V0ZXIgbmVlZHMgdG8gdHJlYXQgdGhlc2UgbWVk aWEgc3RyZWFtcyBkaWZmZXJlbnRseSBidXQgbWF5IG5vdCBzZWUgdGhlIG5lZWQgdG8gZGVwbG95 IGEgVFVSTiBzZXJ2ZXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+Tm93IGFmdGVyIGJyb3dzaW5nDQo8L3NwYW4+PGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFydGluc2VuLXRyYW0tZGlzY3Vzcy0wMCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtbWFydGluc2VuLXRyYW0tZGlzY3Vzcy0wMDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibHVlIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj40KSBESVNDVVNTIHRyYW5zZmVycyBpbmZvcm1hdGlvbiBk aXJlY3RseSBmcm9tIHRoZSBhcHBsaWNhdGlvbiB0byB0aGUgbmV0d29yayBhdCB0aGUgdGltZSBv ZiBzZXR1cCBvZiB0aGUgU1RVTiBvciBUVVJOKD8pIHNlcnZlciwgd2hpY2ggaXQgdGhlcmVmb3Jl IGNhbiBkbyB3aXRoDQogYmV0dGVyIGRldGFpbCBhbmQgcHJlZGljdGlvbi4gVGhpcyBpcyB2YWx1 YWJsZSwgYWxzbyBmb3IgcmVzZXJ2aW5nIGJhbmR3aWR0aCBpbiBub24gZGlmZnNlcnZlIG5ldHdv cmtzIGxpa2UgQ2FibGUgYW5kICZuYnNwO01vYmlsZSB3aGVyZSBvbmUgcmVzZXJ2ZXMgYmFuZHdp ZHRoIHJhdGhlciB0aGFuIHVzZSBkaWZmc2VydmUgZm9yIFFvUy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gWWVz LCB0aGUgbmV0d29yayBjYW4gZW5mb3JjZSBhbnkgUU9TIHBvbGljeSBiYXNlZCBvbiB0aGUgbWV0 YWRhdGEgc2lnbmFsZWQgYnkgdGhlIGNsaWVudC4gUGxlYXNlIG5vdGUgdGhhdCBkdXJpbmcgdGhl IHJldmlldyBvZg0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXdpbmctcGNwLWZsb3dkYXRhLTAwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdpbmctcGNwLWZsb3dkYXRhLTAwPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+DQogd2UgZm91 bmQgdGhhdCB0aGVyZSB3YXMgb25seSBpbnRlcmVzdCB0byBwcm92aWRlIEdCUiAoR3VhcmFudGVl ZCBCaXQgUmF0ZSDigJMgYmFuZHdpZHRoIHJlc2VydmF0aW9uKSBmb3IgV2ViUlRDIG1lZGlhIHN0 cmVhbXMgaWYgdGhlIFdlYlJUQyBzZXJ2ZXIgaGFzIGJ1c2luZXNzIHRpZS11cCB3aXRoIHRoZSBN b2JpbGUgbmV0d29yayBvdGhlcndpc2UgaXTigJlzIG5vbi1HQlIgZm9yIHRoZSBXZWJSVEMgbWVk aWEgc3RyZWFtcy4mbmJzcDsgVGhpcyB0b3BpYyBuZWVkcw0KIG1vcmUgZGlzY3Vzc2lvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+NSkg SXNu4oCZdCBESVNDVVNTIHVzYWJsZSB3aXRoIFRVUk4/IE1heWJlIGV2ZW4gYmV0dGVyISBBbmQg aXQgY2FuIGJlIHVzZWQgd2l0aCAxKSBhYm92ZQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibHVlIj5KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVl Ij5Zb3UgY2FuIHRyYW5zZmVyIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIHRoZSBUVVJOIGFsbG9j YXRlIHJlcXVlc3QgYXMgaW4gdGhlIFNUVU4gYmluZGluZyByZXF1ZXN0LCBjYW7igJl0IHlvdT8u IEkgc2VhcmNoZWQgZm9yIOKAnFRVUk7igJ0gaW4gdGhlIERJU0NVU1MgZHJhZnQsIGJ1dCBjb3Vs ZA0KIG5vdCBzZWUgaXQgc3BlbGxlZCBvdXQuIFRVUk4gaXMgYW4gZXh0ZW5zaW9uIHRvIFNUVU4s IHNvIG1heWJlIGl0IGlzIGp1c3Qgb2J2aW91cz8g4oCTIEkgaGF2ZSBub3QgY2hlY2tlZCBkZXRh aWxzIGluIHRoZSBzcGVjcyBzbyBQw6VsLCBUaXJ1IG9yIERhbiBrbm93aW5nIGJldHRlciwgcGxl YXNlIGNvbmZpcm0gb3IgY29ycmVjdDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1 ZSI+ITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+W1RSXQ0KPC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXRob21zb24tdHJhbS10dXJuLWJhbmR3aWR0aC0wMCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10aG9tc29u LXRyYW0tdHVybi1iYW5kd2lkdGgtMDA8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4NCiBhZGRyZXNzZXMgdGhlIHByb2JsZW0geW91IGhhZCBtZW50 aW9uZWQsIGl0IG5lZWRzIHRvIGJlIGVuaGFuY2VkIHdpdGggbW9yZSBtZXRhZGF0YSBhbmQgdGhl IG90aGVyIGFkdmFudGFnZSBpcyBUVVJOIHNlcnZlciBjYW4gcmVzcG9uZCBpbiB0aGUgQUxMT0NB VEUgcmVzcG9uc2UgaWYgaXQgY2FuIG1lZXQgdGhlIGZsb3cgY2hhcmFjdGVyaXN0aWNzIG9yIG5v dC4mbmJzcDsgSXTigJlzIGRpc2N1c3NlZCBpbiBzZWN0aW9uDQo8L3NwYW4+PGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGhvbXNvbi10cmFtLXR1cm4tYmFuZHdpZHRo LTAwI3NlY3Rpb24tNC4yIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRob21zb24tdHJhbS10dXJuLWJhbmR3aWR0aC0wMCNzZWN0 aW9uLTQuMjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPg0KIG9mIHRoZSBkcmFmdC4mbmJzcDsgTXkgcG9pbnQgaXMgaXTigJlzIG9ubHkgdXNlZnVs IGlmIFRVUk4gaXMgc2VsZWN0ZWQgYmVjYXVzZSBkaXJlY3QgY29ubmVjdGl2aXR5IHVzaW5nIGhv c3Qvc2VydmVyLXJlZmxleGl2ZSBjYW5kaWRhdGVzIGZhaWxlZCBvciByZWxheWVkIGNhbmRpZGF0 ZXMgYXJlIG9ubHkgYWR2ZXJ0aXNlZCBmb3IgcHJpdmFjeSByZWFzb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+U29tZSBvYnNl cnZhdGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPmEuIEluIERJU0NVU1MgdXNpbmcgU1RVTiwgdGhlIG5ldHdvcmsgZWxlbWVudCBk b2luZyB0aGUgZGlmZnNlcnYgb3IgcmVzZXJ2YXRpb24gc2V0dGluZ3MgV09VTEQgYmUgaW4gdGhl IGRlZmF1bHQgZ2F0ZXdheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPmIuIEluIERJU0NVU1Mg dXNpbmcgVFVSTiwgdGhlIFRVUk4gc2VydmVyIGRvaW5nIHRoZSBkaWZmc2VydiBvciByZXNlcnZh dGlvbiBzZXR0aW5ncyBDT1VMRCBiZSBpbiB0aGUgZGVmYXVsdCBnYXRld2F5LiAoVGhlIGF1dG8t ZGlzY292ZXJ5IG9mIHRoZSBUVVJOIHNlcnZlciB3b3VsZA0KIHNpbXBseSBwb2ludCBvdXQgdGhl IGRlZmF1bHQgZ2F0ZXdheS4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPlNvdW5kIHZlcnkgc2ltaWxhcjogQ291bGQgbm90IERJU0NVU1Mg b3ZlciBUVVJOIGFsd2F5cyBiZSB1c2VkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5jLiBXaXRoIERJU0NVU1MgdXNpbmcgVFVSTiwgdGhl IGFwcGxpY2F0aW9uIHdvdWxkIGRpcmVjdGx5IHRhbGsgdG8gdGhlIG5ldHdvcmsgZGV2aWNlIGRv aW5nIHRoZSBkaWZmc2VydmUgc2V0dGluZ3MgZXRjLiAoaW5zdGVhZCBvZiB0aHJvdWdoIGl0LCB3 aGVyZSB0eXBpY2FsbHkgdGhlDQogZGVmYXVsdCBnYXRld2F5IHdvdWxkIHNub3BlIHRoYXQgdGFs aykuIFdvdWxkIHRoYXQgbm90IGVhc3kgc29tZSBvZiB0aGUgY29uY2VybnMgaW4gdGhlIGRyYWZ0 IGxlZnQgZm9yIGZ1cnRoZXIgZGlzY3Vzc2lvbj8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5kLiBDYW4gd2UgYWRkIGluZm8gaW4gdGhl IHJlc3BvbnNlPyBFLmcuIGlmIHRoZSBuZXR3b3JrIGRldmljZSBpcyBvbmx5IHdpbGxpbmcgdG8g Z2l2ZSAxIE1icHMgaW5zdGVhZCBvZiBuZWVkZWQgMyBNYnBzLCBzbyB0aGUgYXBwbGljYXRpb24g Y2FuIGJlIGluZm9ybWVkIHRvIHJlZHVjZQ0KIGhpcyB2aWRlbyByZXNvbHV0aW9uPyBXb3VsZCBi ZSBhIG5pY2UgbWVjaGFuaXNtIHdoZW4gUlRDIGFsb25lIHN0YXJ0cyBmaWxsaW5nIG91ciBwaXBl cy4gKEkgc2F3IGEgc2ltaWxhciBpZGVhIGJ5IFDDpWwgaW4gdGhlIHByZXZpb3VzIGVtYWlsIEkg anVzdCBjb21tZW50ZWQuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltUUl0gUENQIHNvbHZlcyB0aGUgcHJvYmxlbSBieSBw cm92aWRpbmcgcmVzcG9uc2Ugc2ltaWxhciB0byB3aGF0IHlvdSBoYWQgbWVudGlvbmVkIGFuZCBj YW4gYWxzbyBzZW5kIHN1YnNlcXVlbnQgcmVzcG9uc2UgdXBkYXRpbmcgdGhlIGluZm9ybWF0aW9u IGFib3V0IHRoZQ0KIGZsb3csIHNob3VsZCB0aGUgbmV0d29yayBjb25kaXRpb25zIGNoYW5nZS4g Rm9yIG1vcmUgZGV0YWlscyByZWZlciB0byA8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRm Lm9yZy9wcm9jZWVkaW5ncy84Ny9zbGlkZXMvc2xpZGVzLTg3LXBjcC01LnBkZiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg3L3Ns aWRlcy9zbGlkZXMtODctcGNwLTUucGRmPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tVGlydS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+NikgUGxlYXNlIGFkZCB0 byB0aGUgRElTQ1VTUyBkcmFmdCB0aGF0IGl0IGFsc28gY291bGQgcmVzZXJ2ZSBiYW5kd2lkdGgg aW4gYmFuZHdpZHRoIHJlc2VydmF0aW9uIHR5cGUgb2YgbmV0d29ya3MgbGlrZSBDYWJsZSBhbmQg Jm5ic3A7TW9iaWxlIG5ldHdvcmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi PkEgZmV3IG1vcmUgdGhpbmdzIGFyZSBuZWVkZWQgZm9yIHRoZSB1bHRpbWF0ZSBnb2FsPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiwgYnJpbmdpbmcgZW5k LXRvLWVuZA0KIFFvUyBvciBRb0UgZm9yIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uIHRvIEJlc3Qg RWZmb3J0IEludGVybmV0ICh3aGljaCBkb2VzIG5vdCBzZWVtIGltcG9zc2libGUsIGJ1dCBxdWl0 ZSBkb2FibGUgbm93DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6V2luZ2RpbmdzO2NvbG9yOmJsdWUiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibHVlIj4gKSByZW1haW5zIHRob3VnaC4gSeKAmWxsIGNvbWUgYmFjayB0byB0 aG9zZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj5JdCB3aWxsIGUuZy4gcmVsYXRlIHRvIGhvdyB0byBkbyB3aXRoIElOQ09NSU5HIHRy YWZmaWMsIGVzcGVjaWFsbHkgaW4gcmVzZXJ2YXRpb24gdHlwZSBvZiBuZXR3b3JrcywgYW5kIHRo ZSB3aWxkIGNoYW5naW5nL3N0cmlwcGluZyBvZiBkaWZmc2VydmUgYml0cyBiZXR3ZWVuIElTUHMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi PllvdSBtYXkgd2FudCB0byBjaGVjayB0aGlzIG9sZCBkaXNjdXNzaW9uIHRvIHNlZSBpZiB0aGlz IHVzZWZ1bDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQv bXNnMDkxMjguaHRtbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3J0Y3dlYi9jdXJyZW50L21zZzA5MTI4Lmh0bWw8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvcnRjd2ViL2N1cnJlbnQvbXNnMDkxMjkuaHRtbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L3J0Y3dlYi9jdXJyZW50L21zZzA5MTI5Lmh0bWw8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Ymx1ZSI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+L0thcmw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5GcsOlbjo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSBbPC9zcGFu PjxhIGhyZWY9Im1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPm1haWx0bzp0aXJlZGR5QGNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPl0NCjxicj4NCjxiPlNraWNrYXQ6PC9iPiBkZW4gMTMgZmVicnVhcmkgMjA8 L3NwYW4+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4xNCAxNzo0Nzxicj4N CjxiPlRpbGw6PC9iPiBLYXJsIFN0YWhsPGJyPg0KPGI+S29waWE6PC9iPiA8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48YnI+DQo8Yj7DhG1uZTo8L2I+IFJFOiBJTVBPUlRBTlQgQ0xBUklGSUNBVElP TlM6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFu aXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IlNWIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgS2FybCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZGlkIG5vdCB1 bmRlcnN0YW5kIGhvdyBUVVJOIHNlcnZlciB3aWxsIGlkZW50aWZ5IGlmIGl04oCZcyBXZWJSVEMg bWVkaWEgc3RyZWFtcyBvciBnYW1pbmcgdHJhZmZpYyBvciBzb21lIG90aGVyIGRhdGEgdHJhZmZp YyByZWxheWVkIHRocm91Z2ggaXQgdG8gc2V0IHRoZSBkaWZmc2Vydg0KIGJpdHMgY29ycmVjdGx5 ICE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPi1UaXJ1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp biA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEthcmwgU3RhaGwgWzwvc3Bhbj48YSBocmVmPSJt YWlsdG86a2FybC5zdGFobEBpbnRlcnRleC5zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pm1haWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAxMywg MjAxNCA1OjA1IFBNPGJyPg0KPGI+VG86PC9iPiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkp OyAnSHV0dG9uLCBBbmRyZXcnOyAnSnVzdGluIFViZXJ0aSc7IE11dGh1IEFydWwgTW96aGkgUGVy dW1hbCAobXBlcnVtYWwpPGJyPg0KPGI+Q2M6PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRp cmVkZHlAaWNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRpcmVkZHlAaWNp c2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgJ1NpbW9uIFBl cnJlYXVsdCc7ICdPbGVnIE1vc2thbGVua28nOw0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0cmFt QGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgJ01hcmMgQmxhbmNoZXQnOyBEYW4g V2luZyAoZHdpbmcpPGJyPg0KPGI+U3ViamVjdDo8L2I+IElNUE9SVEFOVCBDTEFSSUZJQ0FUSU9O UzogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5p c20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPk9u IHRoZSBzaWRlIG9mIHRoaXMgVFJBTS1saXN0LCBJIGFsc28gZ290IHRoaXMgcXVlc3Rpb246PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZndDsgUmVnYXJkaW5nIHRoZSBlbnRlcnByaXNlIGNhc2UsIEkgYW0gbm90 IHN1cmUgSSBmb2xsb3cgeW91ciBhcmd1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0OyBEbyB5b3Ug bWVhbiB0aGF0IGJ5IHNldHRpbmcgdXAgYW4gZW50ZXJwcmlzZSBUVVJOIHNlcnZlciwgYW5kIG9w ZW4gdGhlIGZpcmV3YWxsIGZvciBtZWRpYSBvdmVyIFVEUCBmcm9tL3RvIFRVUk4gc2VydmVyIGJl IHRoZSBzb2x1dGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPi0tLS0gQXMgd2UgYWxsIHJl YWxpemUsIHRoYXQgd291bGQgb2YgY291cnNlIG5vdCBoZWxwIG9yIGltcHJvdmUgdGhpbmdzPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlRo ZSBpbnRlbmRlZCBzb2x1dGlvbiBpbiB0aGUgZW50ZXJwcmlzZSBjYXNlIGhhcyBub3QgeWV0IGJl ZW4gc3BlbGxlZCBvdXQgaW4gdGhpcyBUUkFNLWxpc3QgZGlzY3Vzc2lvbiwgc28gZm9yIGJldHRl ciB1bmRlcnN0YW5kaW5nLCBsZXQgbWUgY29weSBhIGZldyB0aGluZ3MgZnJvbQ0KIHRoZSBkaXNj dXNzaW9uIGluIFNlcHRlbWJlci9PY3RvYmVyIG9uIHRoZSBSVENXRUItbGlzdCBhbmQgd2hhdCBp cyAoc2luY2UgbG9uZykgc3BlbGxlZCBvdXQgaW4gdGhlIGRyYWZ0LWlldGYtcnRjd2ViLXVzZS1j YXNlcy1hbmQtcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj5Gb3IgYmV0dGVyIHVuZGVyc3RhbmRpbmcsIEkgYWxzbyB3 YW50IHRvIHBvaW50IG91dCB0aGF0IGEgVFVSTiBjYW4gaGF2ZSB0d28gaW50ZXJmYWNlcyAoYWN0 aW5nIGxpa2UgYSByb3V0ZXIgZm9yIG1lZGlhIGJldHdlZW4gZGlmZmVyZW50IG5ldHdvcmtzKS4g VGhpcyBhbGxvd3MgdG8NCiBlYXNpZXIgdW5kZXJzdGFuZCB0aGF0IGNhbiBUVVJOIHNlcnZlcnMg Y2FuIGRpcmVjdCBhIGJlc3QgbWVkaWEgcGF0aCAocmF0aGVyIHRoYW4ganVzdCB0aGlua2luZyB0 aGF0IGEgVFVSTiBzZXJ2aWNlIGlzIGEgZGV2aWNlIHdoaWNoIG1lZGlhIGp1c3QgYm91bmNlcyBh Z2FpbnN0IGF0IG9uZSBpbnRlcmZhY2UpLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkFuZCwgd2UgY2FuIGFsc28gaG9wZSBmb3IgdGhh dCBhIFRVUk4gc2VydmVyIGJlY29tZXMgYSAoY29tbW9uKSBjb21wb25lbnQgb2YgYSBmaXJld2Fs bCwgd2hpY2ggd291bGQgYWxsb3cgdGhlIGZpcmV3YWxsIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGUg bWVkaWEgZGlyZWN0ZWQgdG8NCiBpdCBpcyBSVEMgYW5kIHNob3VsZCBiZSBwcmlvcml0aXplZCB3 aGVyZWJ5IHRoZSBmaXJld2FsbCBjYW4gdHJhZmZpYyBzaGFwZWQgKGJhY2stb2ZmIGRhdGEgdHJh ZmZpYyB0aGF0IG1heSBiZSBmaWxsaW5nIGl0cyBJbnRlcm5ldCBwaXBlKSBhcyB3ZWxsIGFzIGUu Zy4gc2V0IGRpZmZzZXJ2ZSBiaXRzIG9yIHRha2Ugb3RoZXIgbWVhc3VyZXMgdG8gYXNzaXN0IHBy b3BlciBxdWFsaXR5IGhhbmRsaW5nIHRob3VnaHQgdGhlIG5ldHdvcmsuIChUaGVzZQ0KIGFyZSBj b21tb24gbWVjaGFuaXNtcyBhdmFpbGFibGUgYW5kIHVzZWQgaW4gZmlyZXdhbGxzL05BVHMvYWNj ZXNzIHJvdXRlcnMsIGJ1dCBUVVJOIHNlcnZlcnMgYXJlIG5vdCB5ZXQgaW5jbHVkZWQgc3VjaCBk ZXZpY2VzLikgVGhlIHNhbWUgZ29lcyBmb3IgYWNjZXNzIHJvdXRlcnMvZGVmYXVsdCBnYXRld2F5 cywgRFBJcyBpbiB0aGUgdHJhbnNwb3J0IG5ldHdvcmsgaXRzZWxmIOKAkyBUVVJOIHNlcnZlcnMg aW5jbHVkZWQgaW4gc3VjaCBwb2ludHMgd2VyZQ0KIG1lZGlhIGNhbiBwYXNzIGFuZCBxdWFsaXR5 IG1lYXN1cmVzIGFwcGxpZWQgbWF5L3dpbGwgYmUgdmVyeSB1c2VmdWwgdG8gZ2V0IHVzIFdlYlJU QyBtZWRpYSB3aXRoIHRocm91Z2ggbmV0d29ya3Mgd2l0aG91dCBxdWFsaXR5IGRlc3RydWN0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVl Ij5Gcm9tIHRoZSBSVENXRUIgbWFpbGluZyBsaXN0IFNlcHRlbWJlciAyMDxzdXA+dGg8L3N1cD4g KGJ5IG1lKTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+QW4gZW50 ZXJwcmlzZSBuZXR3b3JrIHRoYXQgd2FudCB0byBrZWVwIGEgcmVzdHJpY3RpdmUgZmlyZXdhbGwg bm90IGFsbG93aW5nIFVEUCB0cmFmZmljLCBjb3VsZCBwcm92aWRlIGEgcmVhbC10aW1lIHBhdGgg dXNpbmcgYSBUVVJOIHNlcnZlciBwYXJhbGxlbGluZyB0aGUgZmlyZXdhbGwsIGluc3RlYWQgb2Yg dHVubmVsaW5nDQogUlRQIHRocm91Z2ggYWx3YXlzIG9wZW4gaHR0cCBvciBodHRwcyBwb3J0cyBy ZXN1bHRpbmcgaW4gUlRQIG1lZGlhIG92ZXIgVENQIOKAkyB3aXRoIHNldmVyZSBxdWFsaXR5IHBy b2JsZW1zIGZyb20gVENQIHJldHJhbnNtaXNzaW9ucyBvZiBkcm9wcGVkIHBhY2tldHMuIFRoZSBU VVJOIHNlcnZlciBhZGRyZXNzIGlzIG1vc3QgZWFzaWx5IHByb3ZpZGVkIGluIHRoZSBzYW1lIHdh eSBhcyB0aGUgSVAgYWRkcmVzcyBhbmQgRE5TIGFkZHJlc3MuIChUaGF0DQogd291bGQgYWxzbyBw dXQgdGhlIHJpZ2h0IHBhcnR5IGluIGNvbnRyb2wg4oCTIFRoZSBuZXR3b3JrIHByb3ZpZGVyICho ZXJlIHRoZSBlbnRlcnByaXNlKSBkZWNpZGVzIHdoYXQgaXMgYWxsb3dlZCBvbiBoaXMgbmV0d29y ay4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj5UaGUgYnJvd3NlciBzaG91bGQg c2VsZWN0IHdoaWNoIGF2YWlsYWJsZSBUVVJOIHNlcnZlciBhZGRyZXNzIHRvIHVzZSBpbiB0aGUg Zm9sbG93aW5nIHByaW9yaXR5IG9yZGVyLCB3aGVyZSBJQ0UgY291bGQgYmUgdXNlZCB0byB0cnkg c2V2ZXJhbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjEpIFRVUk4gc2VydmVy IGFkZHJlc3MgY29uZmlndXJlZCBpbiB0aGUgYnJvd3NlciBieSB0aGUgdXNlciAoc3BlY2lhbCBj YXNlcywgbm9ybWFsbHkgbm90IHVzZWQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXMiPjIpIFRVUk4gc2VydmVyIGFkZHJlc3MgY29uZmlndXJlZCBieSB0aGUgbmV0d29y ayBhZG1pbmlzdHJhdG9yIHZpYSBhbiDigJxhZG1pbiBwb2xpY3kgdGVtcGxhdGXigJ08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcyI+MykgVFVSTiBzZXJ2ZXIgYWRkcmVz cyBzdXBwbGllZCBieSBESENQIG9yIHNpbWlsYXIgYXV0b21hdGljIG5ldHdvcmsgbWV0aG9kPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPjQpIFRVUk4gc2VydmVyIGFk ZHJlc3MgYmVpbmcgc3VwcGxpZWQgYnkgdGhlIHdlYiBhcHBsaWNhdGlvbiZxdW90OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkFuZCBmcm9tIHllc3RlcmRheXMoISkNCjwvc3Bhbj48 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi11c2Ut Y2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xNCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1y ZXF1aXJlbWVudHMtMTQ8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+DQogdGhlc2UgZW50ZXJwcmlzZSB0aGluZ3MgYW5kIG5lY2Vzc2l0eSBhcmUgc3BlbGxl ZCBvdXQgaW46PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij5GMTkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGJyb3dzZXIgbXVzdCBiZSBh YmxlIHRvIHVzZSBzZXZlcmFsIFNUVU4gYW5kIFRVUk4gc2VydmVyczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+QTIyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saW5lLWhlaWdodC1hbHQ6MHB0O3BhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyI+DQo8YSBuYW1lPSJzZWN0aW9uLTMuMy41Ij48L2E+PGEgaHJlZj0iaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJl bWVudHMtMTQjc2VjdGlvbi0zLjMuNSI+PGI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+My4zLjU8L3NwYW4+PC9i PjwvYT48Yj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4uJm5ic3A7DQogU2ltcGxlIFZpZGVvIENvbW11bmljYXRpb24gU2VydmljZSwg ZW50ZXJwcmlzZSBhc3BlY3RzPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGluZS1oZWlnaHQtYWx0OjBwdDtwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPg0KPGEgbmFtZT0ic2VjdGlvbi0zLjMuNS4xIj48L2E+PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVu dHMtMTQjc2VjdGlvbi0zLjMuNS4xIj48Yj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4zLjMuNS4xPC9zcGFuPjwv Yj48L2E+PGI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+LiZuYnNwOw0KIERlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwOyBUaGlzIHVzZS1jYXNlIGlzIHNpbWlsYXIgdG8gdGhlIFNpbXBsZSBW aWRlbyBDb21tdW5pY2F0aW9uIFNlcnZpY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgdXNlLWNhc2UgKDwvc3Bhbj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXJ0Y3dlYi11c2UtY2FzZXMtYW5kLXJlcXVpcmVtZW50cy0xNCNzZWN0aW9u LTMuMy4xIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5TZWN0aW9uDQogMy4zLjE8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPikuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFdoYXQg aXMgYWRkZWQgaXMgYXNwZWN0cyB3aGVuIHVzaW5nIHRoZSBzZXJ2aWNlIGluIGVudGVycHJpc2Vz LiZuYnNwOyBJQ0U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgaXMgYXNzdW1l ZCBpbiB0aGUgZnVydGhlciBkZXNjcmlwdGlvbiBvZiB0aGlzIHVzZS1jYXNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBB biBlbnRlcnByaXNlIHRoYXQgdXNlcyBhIFJUQ1dFQiBiYXNlZCB3ZWIgYXBwbGljYXRpb24gZm9y PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGNvbW11bmljYXRpb24gZGVzaXJl cyB0byBhdWRpdCBhbGwgUlRDV0VCIGJhc2VkIGFwcGxpY2F0aW9uIHNlc3Npb25zPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHVzZWQgZnJvbSBpbnNpZGUgdGhlIGNvbXBhbnkg dG93YXJkcyBhbnkgZXh0ZXJuYWwgcGVlci4mbmJzcDsgVG8gYmUgYWJsZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0byBkbyB0aGlzIHRoZXkgZGVwbG95IGEgVFVSTiBzZXJ2 ZXIgdGhhdCBzdHJhZGRsZXMgdGhlIGJvdW5kYXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IGJldHdlZW4gdGhlIGludGVybmFsIGFuZCB0aGUgZXh0ZXJuYWwgbmV0d29yay48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBs YW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgVGhlIGZpcmV3YWxsIHdpbGwgYmxvY2sgYWxsIGF0dGVtcHRzIHRvIHVzZSBTVFVO IHdpdGggYW4gZXh0ZXJuYWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgZGVz dGluYXRpb24gdW5sZXNzIHRoZXkgZ28gdG8gdGhlIGVudGVycHJpc2UgYXVkaXRpbmcgVFVSTiBz ZXJ2ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEluIGNhc2VzIHdoZXJl IGVtcGxveWVlcyBhcmUgdXNpbmcgUlRDV0VCIGFwcGxpY2F0aW9ucyBwcm92aWRlZCBieSBhbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBleHRlcm5hbCBzZXJ2aWNlIHByb3Zp ZGVyIHRoZXkgc3RpbGwgd2FudCB0aGUgdHJhZmZpYyB0byBzdGF5IGluc2lkZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0aGVpciBpbnRlcm5hbCBuZXR3b3JrIGFuZCBpbiBh ZGRpdGlvbiBub3QgbG9hZCB0aGUgc3RyYWRkbGluZyBUVVJOPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7Jm5ic3A7IHNlcnZlciwgdGh1cyB0aGV5IGRlcGxveSBhIFNUVU4gc2VydmVyIGFs bG93aW5nIHRoZSBSVENXRUIgY2xpZW50IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IGRldGVybWluZSBpdHMgc2VydmVyIHJlZmxleGl2ZSBhZGRyZXNzIG9uIHRoZSBpbnRl cm5hbCBzaWRlLiZuYnNwOyBUaHVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 IGVuYWJsaW5nIGNhc2VzIHdoZXJlIHBlZXJzIGFyZSBib3RoIG9uIHRoZSBpbnRlcm5hbCBzaWRl IHRvIGNvbm5lY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgd2l0aG91dCB0 aGUgdHJhZmZpYyBsZWF2aW5nIHRoZSBpbnRlcm5hbCBuZXR3b3JrLiZuYnNwOyBJdCBtdXN0IGJl PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHBvc3NpYmxlIHRvIGNvbmZpZ3Vy ZSB0aGUgYnJvd3NlcnMgdXNlZCBpbiB0aGUgZW50ZXJwcmlzZSB3aXRoPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IG5ldHdvcmsgc3BlY2lmaWMgU1RVTiBhbmQgVFVSTiBzZXJ2 ZXJzLiZuYnNwOyBUaGlzIHNob3VsZCBiZSBwb3NzaWJsZSB0bzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPiZuYnNwOyZuYnNwO2FjaGlldmUgYnkgYXV0by1jb25maWd1cmF0aW9uIG1ldGhvZHMuJm5i c3A7IFRoZSBSVENXRUIgZnVuY3Rpb25hbGl0eSB3aWxsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IG5lZWQgdG8gdXRpbGl6ZSBib3RoIG5ldHdvcmsgc3BlY2lmaWMgU1RVTiBh bmQgVFVSTiByZXNvdXJjZXMgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7 IFNUVU4gYW5kIFRVUk4gc2VydmVycyBwcm92aXNpb25lZCBieSB0aGUgd2ViIGFwcGxpY2F0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGluZS1o ZWlnaHQtYWx0OjBwdDtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPGEgbmFtZT0ic2VjdGlv bi0zLjMuNS4yIj48L2E+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNS4y Ij48Yj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4zLjMuNS4yPC9zcGFuPjwvYj48L2E+PGI+PHNwYW4gbGFuZz0i RU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LiZuYnNwOw0K IEFkZGl0aW9uYWwgUmVxdWlyZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxh bmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFJFUS1J RCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBERVNDUklQVElPTjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IEYyMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgYnJvd3NlciBtdXN0IHN1 cHBvcnQgdGhlIHVzZSBvZiBTVFVOIGFuZCBUVVJOPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHNlcnZlcnMgdGhhdCBhcmUgc3VwcGxpZWQgYnkgZW50aXRpZXMgb3RoZXIgdGhhbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgd2ViIGFwcGxpY2F0aW9uIChpLmUuIHRoZSBuZXR3b3Jr IHByb3ZpZGVyKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5U aGVyZSBhcmUgZnVydGhlciByZXF1aXJlbWVudCBsaXN0ZWQsIGhlbHBpbmcgdXMgdG8gdW5kZXJz dGFuZCB0aGUgbmVlZCBmb3IgYXV0byBkaXNjb3ZlcnkgYW5kIGEgbmV0d29yayBwcm92aWRlZCBU VVJOLXNlcnZlciBzaG91bGQgYmUgdXNlZCB0byBFTkZPUkNFIHRoYXQgbWVkaWENCiB0YWtlcyB0 aGF0IHBhdGggKGFuZCB0aHVzLCBvdGhlciBwYXRocyBlLmcuIHN1Z2dlc3RlZCBieSB0aGUgcmVt b3RlIE1VU1Qgbm90IGhhcHBlbiB0byBiZSB1c2VkKS4gVGhpcyBpcyByZWxhdGVkIHRvIHRoZSBt b2JpbGl0eSBhc3BlY3QgKHZhbGlkIGV2ZW4gd2l0aG91dCB0aGUgcm9hbWluZyBpZGVhKTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8aDQgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saW5lLWhlaWdodC1hbHQ6MHB0O3BhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+DQo8YSBuYW1lPSJzZWN0aW9uLTMuMy42Ij48L2E+PGEgaHJlZj0i aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFu ZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNiI+PGI+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazt0ZXh0LWRl Y29yYXRpb246bm9uZSI+My4zLjY8L3NwYW4+PC9iPjwvYT48Yj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4uJm5ic3A7DQogU2ltcGxl IFZpZGVvIENvbW11bmljYXRpb24gU2VydmljZSwgYWNjZXNzIGNoYW5nZTxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L2g0Pg0KPGg1IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGluZS1oZWlnaHQtYWx0OjBwdDtwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPg0KPGEgbmFtZT0ic2VjdGlvbi0zLjMuNi4xIj48L2E+PGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1y ZXF1aXJlbWVudHMtMTQjc2VjdGlvbi0zLjMuNi4xIj48Yj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO3RleHQtZGVj b3JhdGlvbjpub25lIj4zLjMuNi4xPC9zcGFuPjwvYj48L2E+PGI+PHNwYW4gbGFuZz0iRU4iIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LiZuYnNwOw0KIERlc2Ny aXB0aW9uPG86cD48L286cD48L3NwYW4+PC9iPjwvaDU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGlzIHVzZS1jYXNlIGlzIGFsbW9zdCBp ZGVudGljYWwgdG8gdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBTaW1wbGUgVmlkZW8gQ29tbXVu aWNhdGlvbiBTZXJ2aWNlIHVzZS1jYXNlICg8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMt MTQjc2VjdGlvbi0zLjMuMSI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+U2VjdGlvbiAzLjMuMTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0i RU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+KS4mbmJzcDsg VGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBkaWZmZXJlbmNlIGlzIHRoYXQgdGhlIHVzZXIgY2hh bmdlcyBuZXR3b3JrIGFjY2VzcyBkdXJpbmcgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBzZXNz aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSBjb21tdW5pY2F0 aW9uIGRldmljZSB1c2VkIGJ5IG9uZSBvZiB0aGUgdXNlcnMgaGFzIHNldmVyYWwgbmV0d29yazxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYWRhcHRlcnMgKEV0aGVybmV0LCBXaUZpLCBDZWxsdWxhciku Jm5ic3A7IFRoZSBjb21tdW5pY2F0aW9uIGRldmljZSBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsg YWNjZXNzaW5nIHRoZSBJbnRlcm5ldCB1c2luZyBFdGhlcm5ldCwgYnV0IHRoZSB1c2VyIGhhcyB0 byBzdGFydCBhPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB0cmlwIGR1cmluZyB0aGUgc2Vzc2lvbi4m bmJzcDsgVGhlIGNvbW11bmljYXRpb24gZGV2aWNlIGF1dG9tYXRpY2FsbHk8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IGNoYW5nZXMgdG8gdXNlIFdpRmkgd2hlbiB0aGUgRXRoZXJuZXQgY2FibGUgaXMg cmVtb3ZlZCBhbmQgdGhlbiBtb3ZlczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgdG8gY2VsbHVsYXIg YWNjZXNzIHRvIHRoZSBJbnRlcm5ldCB3aGVuIG1vdmluZyBvdXQgb2YgV2lGaSBjb3ZlcmFnZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSBzZXNzaW9uIGNvbnRpbnVlcyBldmVuIHRob3VnaCB0 aGUgYWNjZXNzIG1ldGhvZCBjaGFuZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGg1IHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGluZS1oZWlnaHQtYWx0OjBwdDtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPGEgbmFt ZT0ic2VjdGlvbi0zLjMuNi4yIj48L2E+PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVudHMtMTQjc2VjdGlv bi0zLjMuNi4yIj48Yj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpub25lIj4zLjMuNi4y PC9zcGFuPjwvYj48L2E+PGI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+LiZuYnNwOw0KIEFkZGl0aW9uYWwgUmVxdWlyZW1lbnRzPG86 cD48L286cD48L3NwYW4+PC9iPjwvaDU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBSRVEt SUQmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgREVTQ1JJUFRJT048bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5i c3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEYxNyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBUaGUgY29tbXVuaWNhdGlvbiBzZXNzaW9uIG11c3Qgc3Vydml2ZSBhY3Jvc3Mg YTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgY2hhbmdlIG9mIHRoZSBuZXR3b3JrIGludGVyZmFjZSB1c2VkIGJ5IHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgc2Vzc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPGg0IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGluZS1oZWlnaHQtYWx0OjBwdDtwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPg0KPGEgbmFtZT0ic2VjdGlvbi0zLjMuNyI+PC9hPjxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXVzZS1jYXNlcy1h bmQtcmVxdWlyZW1lbnRzLTE0I3NlY3Rpb24tMy4zLjciPjxiPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPjMuMy43PC9zcGFuPjwvYj48L2E+PGI+PHNwYW4gbGFuZz0iRU4iIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LiZuYnNwOw0KIFNpbXBs ZSBWaWRlbyBDb21tdW5pY2F0aW9uIFNlcnZpY2UsIFFvUzxvOnA+PC9vOnA+PC9zcGFuPjwvYj48 L2g0Pg0KPGg1IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGluZS1oZWlnaHQtYWx0OjBwdDtwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPg0KPGEgbmFtZT0ic2VjdGlvbi0zLjMuNy4xIj48L2E+PGEgaHJlZj0iaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdXNlLWNhc2VzLWFuZC1yZXF1aXJlbWVu dHMtMTQjc2VjdGlvbi0zLjMuNy4xIj48Yj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlvbjpu b25lIj4zLjMuNy4xPC9zcGFuPjwvYj48L2E+PGI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+LiZuYnNwOw0KIERlc2NyaXB0aW9uPG86 cD48L286cD48L3NwYW4+PC9iPjwvaDU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGlzIHVzZS1jYXNlIGlzIGFsbW9zdCBpZGVudGljYWwg dG8gdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBTaW1wbGUgVmlkZW8gQ29tbXVuaWNhdGlvbiBT ZXJ2aWNlLCBhY2Nlc3MgY2hhbmdlIHVzZS1jYXNlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAoPC9z cGFuPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2Vi LXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0I3NlY3Rpb24tMy4zLjYiPjxzcGFuIGxhbmc9 IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPlNlY3Rpb24g My4zLjY8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPikuJm5ic3A7IFRoZSB1c2Ugb2YgUXVhbGl0eSBvZiBTZXJ2aWNl IChRb1MpIGNhcGFiaWxpdGllcyBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgYWRkZWQ6PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVGhlIHVzZXIgaW4gdGhlIHByZXZpb3Vz IHVzZSBjYXNlIHRoYXQgc3RhcnRzIGEgdHJpcCBpcyBiZWhpbmQgYTxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgY29tbW9uIHJlc2lkZW50aWFsIHJvdXRlciB0aGF0IHN1cHBvcnRzIHByaW9yaXRpemF0 aW9uIG9mIHRyYWZmaWMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBJbiBhZGRpdGlvbiwgdGhlIHVz ZXIncyBwcm92aWRlciBvZiBjZWxsdWxhciBhY2Nlc3MgaGFzIFFvUyBzdXBwb3J0PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiZuYnNwOyZuYnNwOyBlbmFibGVkLiZuYnNwOyBUaGUgdXNlciBpcyBhYmxlIHRvIHRha2UgYWR2 YW50YWdlIG9mIHRoZSBRb1Mgc3VwcG9ydCBib3RoPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyB3aGVu IGFjY2Vzc2luZyB2aWEgdGhlIHJlc2lkZW50aWFsIHJvdXRlciBhbmQgd2hlbiB1c2luZyBjZWxs dWxhci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxoNSBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpbmUtaGVpZ2h0LWFsdDow cHQ7cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjxhIG5hbWU9InNlY3Rpb24tMy4zLjcuMiI+ PC9hPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2Vi LXVzZS1jYXNlcy1hbmQtcmVxdWlyZW1lbnRzLTE0I3NlY3Rpb24tMy4zLjcuMiI+PGI+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+My4zLjcuMjwvc3Bhbj48L2I+PC9hPjxiPjxz cGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pi4mbmJzcDsNCiBBZGRpdGlvbmFsIFJlcXVpcmVtZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvYj48 L2g1Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgUkVRLUlEJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IERFU0NSSVBUSU9OPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPiZuYnNwOyZuYnNwOyBGMTcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGNvbW11 bmljYXRpb24gc2Vzc2lvbiBtdXN0IHN1cnZpdmUgYWNyb3NzIGE8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0i RU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7ICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NoYW5n ZSBvZiB0aGUgbmV0d29yayBpbnRlcmZhY2UgdXNlZCBieSB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0i RU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNlc3Np b248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEYy MiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgYnJvd3NlciBtdXN0IGJlIGFibGUgdG8gcmVj ZWl2ZSBzdHJlYW1zIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGF0YSBmcm9tIG11bHRpcGxlIHBlZXJzIGNv bmN1cnJlbnRseS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5GdXJ0aGVyIGZyb20g dGhlIFJUQ1dFQiBtYWlsaW5nIGxpc3QgU2VwdGVtYmVyIDIwPHN1cD50aDwvc3VwPiAoYnkgbWUp OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXMiPlRoZXJlIGFyZSBzZXZlcmFsIHJlYXNvbnMgZm9yIGEgbmV0d29y ayBzZXJ2aWNlIHByb3ZpZGVyIHRvIHN1cHBseSBhIFRVUk4gc2VydmVyIGFzIHBhcnQgb2YgaGlz IG9mZmVyZWQgYWNjZXNzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ij4tIHRvIGtlZXAgbWVkaWEgcGF0aHMgc2hvcnQsIHNwZWNpZmljYWxseSBub3Qgc2VuZGluZyBt ZWRpYSBvdXRzaWRlIGl0cyBvd24gbmV0d29yayB0byBzb21lIGRpc3RhbnQgYXBwbGljYXRpb24g cHJvdmlkZWQgVFVSTiBzZXJ2ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25z b2xhcyI+LSB0byBzdXBwb3J0IG1vYmlsaXR5LCBpLmUuIHlvdSBtYXkgd2FudCB0byBtb3ZlIGZy b20gYSBMQU4gd2l0aCBhIGNvbmZpZ3VyZWQgVFVSTiBzZXJ2ZXIgdG8gYWNjZXNzaW5nIHZpYSBX aUZpIG9yIDNHLzRHIE9UVCBjaGFubmVsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzIj4tIHRvIG9mZmVyIGEgbWVkaWEgcGF0aCB3aXRoIGJldHRlciBxdWFsaXR5ICh0 aGFuIGJlc3QgZWZmb3J0IGRhdGEgdHJhZmZpYykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6Q29uc29sYXMiPkdldHRpbmcg4oCcV2ViUlRDLXJlYWR54oCdIGFjY2VzcyBhbmQgd2Ug bG9vayBmb3J3YXJkIHRvIHRlbGVwcmVzZW5jZSBmb3IgZXZlcnlvbmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6Ymx1ZSI+SSBob3BlIHRoaXMgKGEgYml0IGxlbmd0aHkpIHN1bW1hcnkgb2Yg YWxyZWFkeSB0aG91Z2h0LW91dCBhbmQgZGlzY3Vzc2VkIGFzcGVjdHMvcmVxdWlyZW1lbnRzIHdp bGwgaGVscCB1cyB1bmRlcnN0YW5kIHRoYXQgdGhlIGF1dG8tZGlzY292ZXJlZCBUVVJOIHNlcnZl ciBpcyBhbg0KIE9SREVSIGZyb20gdGhlIGVudGVycHJpc2UgYW5kL29yIHRoZSBOU1AvSVNQICZu YnNwO3RvIHNlbmQgdGhlIG1lZGlhIHRocm91Z2ggdGhpcyBUVVJOIHBhdGgsIGFuZCB0aGF0IG90 aGVyIG1lZGlhIHBhdGhzIHRoYXQgbWF5IGV4aXN0IE1VU1QgTk9UIEJFIFVTRUQuIChUaGF0IGlz IHdoeSB3ZSBlc3BlY2lhbGx5IGhhdmUgdG8gd2F0Y2gvYWR2aWNlIHRoYXQgd29ya2FibGUgbWVk aWEgcGF0aHMgcHJvcG9zZWQgYnkgdGhlIHJlbW90ZSBwYXJ0eSBub3QgYmVjb21lcw0KIHVzZWQg 4oCcYnkgYWNjaWRlbnTigJ0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPi9LYXJsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnLDpW46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IFRpcnVtYWxlc3dhciBSZWRkeSAodGlyZWRkeSkgWzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86dGlyZWRkeUBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5tYWlsdG86dGlyZWRkeUBjaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5dDQo8YnI+DQo8Yj5Ta2lja2F0OjwvYj4gZGVuIDEzIGZlYnJ1YXJpIDIwMTQgMDQ6 Mzc8YnI+DQo8Yj5UaWxsOjwvYj4gSHV0dG9uLCBBbmRyZXc7IEp1c3RpbiBVYmVydGk7IE11dGh1 IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpPGJyPg0KPGI+S29waWE6PC9iPiA8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPnRpcmVkZHlAaWNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjsgU2ltb24gUGVycmVhdWx0OyBPbGVnIE1vc2thbGVua287DQo8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFt QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBNYXJjIEJs YW5jaGV0OyBEYW4gV2luZyAoZHdpbmcpOyBLYXJsIFN0YWhsPGJyPg0KPGI+w4RtbmU6PC9iPiBS RTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5p c20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGkgQW5keSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZXJlIGFyZSBvdGhlciB3YXlzIHRvIHNvbHZlIHRoZSBw cm9ibGVtIGZvciBleGFtcGxlIHVzaW5nIFBDUC4gQ2FuIHlvdSBjbGFyaWZ5IGhvdyBkZXBsb3lp bmcgYSBUVVJOIHNlcnZlciBpbiB0aGUgRW50ZXJwcmlzZSBwcm90ZWN0cyB0aGUgdXNlcnMgYW5k IHRoZSBuZXR3b3JrDQogPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1UaXJ1LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHRyYW0gWzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86dHJhbS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+bWFpbHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SHV0dG9uLCBBbmRyZXc8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDEzLCAyMDE0IDE6MDAgQU08YnI+ DQo8Yj5Ubzo8L2I+IEp1c3RpbiBVYmVydGk7IE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBl cnVtYWwpPGJyPg0KPGI+Q2M6PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRpcmVkZHlAaWNp c2NvLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRpcmVkZHlAaWNpc2NvLmNvbTwv c3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgU2ltb24gUGVycmVhdWx0OyBP bGVnIE1vc2thbGVua287DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBNYXJjIEJsYW5jaGV0OyBEYW4gV2luZyAoZHdpbmcpOyBL YXJsIFN0YWhsPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gTWlsZXN0b25lIDM6IFRV Uk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlzZSBhbmQgSVNQ czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgY2FzZSB3aGVyZSB0aGUgVFVS TiBzZXJ2ZXIgaXMgdGhlIG9ubHkgb3B0aW9uIG1heSBiZWNvbWUgY29tbW9uIHdpdGhpbiBlbnRl cnByaXNlIG5ldHdvcmtzIGFuZCB0aGF0IG1pZ2h0IGJlIGRlbGliZXJhdGUgZW50ZXJwcmlzZSBw b2xpY3kgYmVjYXVzZSBpdCBwcm92aWRlcw0KIHRoZSBiZXR0ZXIgcGF0aCAoVURQIHRocm91Z2gg dGhlIEYvVykgYW5kIHByb3RlY3RzIHRoZSB1c2VycyBhbmQgdGhlIG5ldHdvcmsuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5BbmR5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiB0cmFtIFs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOnRyYW0tYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPm1h aWx0bzp0cmFtLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkp1c3RpbiBVYmVydGk8YnI+DQo8Yj5TZW50 OjwvYj4gMTIgRmVicnVhcnkgMjAxNCAxNzo0Njxicj4NCjxiPlRvOjwvYj4gTXV0aHUgQXJ1bCBN b3poaSBQZXJ1bWFsIChtcGVydW1hbCk8YnI+DQo8Yj5DYzo8L2I+IDwvc3Bhbj48YSBocmVmPSJt YWlsdG86dGlyZWRkeUBpY2lzY28uY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dGly ZWRkeUBpY2lzY28uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+OyBT aW1vbiBQZXJyZWF1bHQ7IE9sZWcgTW9za2FsZW5rbzsNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86 dHJhbUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8 L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47IE1hcmMgQmxhbmNoZXQ7IERh biBXaW5nIChkd2luZyk7IEthcmwgU3RhaGw8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFt XSBNaWxlc3RvbmUgMzogVFVSTiBzZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBl bnRlcnByaXNlIGFuZCBJU1BzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFncmVlLiBJZiBUVVJOIGlzIGluZGVlZCBiZWluZyBwcm92aWRlZCBm b3IgdGhlIHVzZXIncyBiZW5lZml0LCB0aGUgY2xpZW50J3MgSUNFIGxvZ2ljIChiYXNlZCBvbiBS VFQgb3Igc2ltaWxhcikgc2hvdWxkIHJlc3VsdCBpbiBpdCBwcmVmZXJyaW5nIHRoZSBUVVJOIHBh dGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDEyLCAyMDE0IGF0IDE6MjcgQU0sIE11 dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpICZsdDs8YSBocmVmPSJtYWlsdG86bXBl cnVtYWxAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bXBlcnVtYWxAY2lzY28uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPlllcywgSSBiZWxpZXZlIHRoZSBzZWNvbmQgY2FzZSBpcyByYXJlLCBi dXQgd291bGQgYmUgYmV0dGVyIHRoYW4gYSByYXQgcmFjZSBiL3cgYWRtaW5pc3RyYXRvcnMgdHJ5 aW5nIHRvIGJsb2NrIHAycCB0cmFmZmljDQogYW5kIGZvcmNlIGl0IHRocm91Z2ggYSBUVVJOIHNl cnZlciBhbmQgYXBwcy9lbmRwb2ludHMgZmluZGluZyBzbWFydGVyIHdheXMgdG8gYnlwYXNzIHRo ZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+TXV0aHU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE9sZWcgTW9za2FsZW5rbyBbbWFpbHRvOjwv c3Bhbj48YSBocmVmPSJtYWlsdG86bW9tMDQwMjY3QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tb20wNDAyNjdAZ21haWwuY29tPC9zcGFuPjwv YT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgRmVicnVhcnkgMTIsIDIwMTQgMTowNyBQTTxicj4NCjxiPlRvOjwvYj4gTXV0aHUgQXJ1 bCBNb3poaSBQZXJ1bWFsIChtcGVydW1hbCk8YnI+DQo8Yj5DYzo8L2I+IEp1c3RpbiBVYmVydGk7 IEthcmwgU3RhaGw7IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRpcmVkZHlAaWNpc2Nv LmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsNCiBNYXJjIEJsYW5j aGV0OyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgRGFuIFdpbmcgKGR3aW5nKTsgU2ltb24gUGVycmVh dWx0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt0cmFtXSBNaWxlc3RvbmUgMzogVFVSTiBz ZXJ2ZXIgYXV0by1kaXNjb3ZlcnkgbWVjaGFuaXNtIGZvciBlbnRlcnByaXNlIGFuZCBJU1BzPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBUVVJOIHNlcnZlciBoYXMgdG8gYmUgdXNlZCB3aGVu IGl0IGlzIGVpdGhlciB0aGUgb25seSBvcHRpb24sIG9yIGlmIGl0IHByb3ZpZGVzIGEgYmV0dGVy IHBhdGggKEkgZ3Vlc3MgdGhlIHNlY29uZCBjYXNlIGlzIHJhdGhlciByYXJlKS48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBGZWIgMTEsIDIwMTQgYXQgMTE6MzIg UE0sIE11dGh1IEFydWwgTW96aGkgUGVydW1hbCAobXBlcnVtYWwpICZsdDs8YSBocmVmPSJtYWls dG86bXBlcnVtYWxAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+bXBlcnVtYWxAY2lzY28uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiYjNDM7MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkZvcmNpbmcgYWxsIHRyYWZmaWMgdGhy b3VnaCBhIFRVUk4gc2VydmVyIGFuZCBleHBlY3RpbmcgaXQgd291bGQgcHJvdmlkZSB0aGUgYmVz dCB1c2VyIGV4cGVyaWVuY2UgZG9lc24ndCBsb29rIHRoZSByaWdodA0KIGFwcHJvYWNoLiBJbnN0 ZWFkLCBpZiBhIHBhdGggdGhyb3VnaCBhIFRVUk4gc2VydmVyIGV4aXN0cyBhbmQgZG9lcyBwcm92 aWRlIGxvd2VyIFJUVCwgaml0dGVyIGV0YywgYmVpbmcgYWJsZSB0byBkZXRlY3QgYW5kIHVzZSAo b3Igc3dpdGNoIHRvKSB0aGF0IHBhdGggbWlnaHQgYmUgZGVzaXJhYmxlLi48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5NdXRodTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gdHJhbSBbbWFpbHRvOjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbS1i b3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPnRyYW0tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SnVzdGluIFViZXJ0aTxicj4NCjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDEyLCAyMDE0IDExOjQzIEFNPGJyPg0KPGI+VG86PC9i PiBLYXJsIFN0YWhsPGJyPg0KPGI+Q2M6PC9iPiA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRpcmVk ZHlAaWNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij50aXJlZGR5QGljaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij47IE1hcmMgQmxhbmNoZXQ7DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRyYW1AaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9y Zzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjsgRGFuIFdpbmcgKGR3aW5n KTsgU2ltb24gUGVycmVhdWx0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdHJhbV0gTWlsZXN0 b25lIDM6IFRVUk4gc2VydmVyIGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbSBmb3IgZW50ZXJwcmlz ZSBhbmQgSVNQczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbmxpbmUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgRmViIDExLCAyMDE0IGF0IDI6MzcgUE0sIEthcmwg U3RhaGwgJmx0OzxhIGhyZWY9Im1haWx0bzprYXJsLnN0YWhsQGludGVydGV4LnNlIiB0YXJnZXQ9 Il9ibGFuayI+a2FybC5zdGFobEBpbnRlcnRleC5zZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+TGlzdGVuaW5nIHRvIHRoaXMgdGhyZWFkLCBJIGFtIGFm cmFpZCB3ZSBhcmUgbWlzc2luZyB0aGUgdmVyeSBwb2ludCBhbmQgbmVjZXNzaXR5IGZvciB0aGlz IG1pbGVzdG9uZSE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+LSBUaGVyZSBhcmUgc2V2ZXJl IE5BVCB0cmF2ZXJzYWwgYW5kIHF1YWxpdHkgaXNzdWVzIHRoYXQgc2hvdWxkIGFuZCBjYW4gYmUg ZGVhbHQgd2l0aCBieSBhIGdvb2QgYXV0by1kaXNjb3ZlcnkNCiBtZWNoYW5pc20gYW5kIHRoZSBy aWdodCB1c2FnZSBieSB0aGUgdHVybiBjbGllbnQgKHRoZSBXZWJSVEMgYnJvd3Nlcik8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlRo ZXJlIGFyZSB3YXlzLCBub3Qgb25seToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RW50ZXJwcmlzZXMgb3Ig SVNQcyB3aXNoaW5nIHRvIHByb3ZpZGUgdGhlaXIgb3duIFRVUk4gc2VydmVyLCBpbiBhbiBhdHRl bXB0IHRvIHJlZHVjZSBzby1jYWxsZWQgJnF1b3Q7dHJpYW5nbGUgcm91dGluZyZxdW90OyxuZWVk IGEgbmV3IGF1dG8tZGlzY292ZXJ5IG1lY2hhbmlzbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVl Ij5CdXQgYWxzbzogLSBOU1BzIChOZXR3b3JrIFNlcnZpY2UgUHJvdmlkZXJzKSB3YW50IHRvIHBy b3ZpZGUgYSBwYXRoIHdoZXJlIHRoZSBiYW5kd2lkdGggb2YgV2ViUlRDIGlzIGJldHRlcg0KIGNv cGVkIHdpdGguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIE5TUHMgb3IgRW50 ZXJwcmlzZXMgd2FudCB0byBvZmZlciBhbiBJbnRlcm5ldCBhY2Nlc3MgcXVhbGl0eSBwaXBlIGZv ciBwcmlvcml0aXplZCBSVEMgKFJlYWwgVGltZSBDb21tdW5pY2F0aW9uKQ0KIHRyYWZmaWMuIDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIEVudGVycHJpc2VzIGhhdmluZyByZXN0cmljdGl2 ZSBmaXJld2FsbHMsIHdhbnQgdG8gcHJvdmlkZSBhIFVEUC1wYXRoIGZvciBXZWJSVEMgYW5kIHBv c3NpYmx5IGFsc28gZm9yDQogYmV0dGVyIHF1YWxpdHkgd2hlcmUgUlRDIGRvIG5vdCBjb21wZXRl IHdpdGggZGF0YSB0cmFmZmljLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5B bHNvIGNvbnNpZGVyaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4tIE1vYmls aXR5OyBJdCBpcyBjb21tb24gdG8gbW92ZSBmcm9tIGEgTEFOIHRvIGFjY2Vzc2luZyB2aWEgV2lG aSBvciAzRy80RyBPVFQgY2hhbm5lbHMsIGFsbCBzaG91bGQgYmUNCiBhYmxlIHRvIGF1dG9tYXRp Y2FsbHkgb2ZmZXIgdGhlaXIgb3duIG9wdGltYWwgVFVSTiBzZXJ2ZXI8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhp cyBsZWFkcyB1cyBpbnRvDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A74oCcVFVSTuKApnRvIGlkZW50aWZ5IFdlYlJUQyBmbG93c+KAnQ0KPHNwYW4gc3R5bGU9ImNv bG9yOmJsdWUiPmV0YyEgSXQgaXMgbm90IGEgbWlzdGFrZSwgYnV0IHRoZSB2ZXJ5IG5lZWQgZm9y IHRoaXMgbWlsZXN0b25lITwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFnYWluLCBpdCBoYXMgbm90 IGJlZW4gZGVtb25zdHJhdGVkIHdoeSBUVVJOIGlzIHRoZSByaWdodCB0ZWNobm9sb2d5IGhlcmUs IGNvbXBhcmVkIHRvIGEgbW9yZSB0cmFuc3BhcmVudCBmbG93IGlkZW50aWZpY2F0aW9uIHRvb2wg bGlrZSBNQUxJQ0UuIFdlIGRvbid0IGZvcmNlIGFsbCBIVFRQIHJlcXVlc3RzDQogdG8gbG9jYXRl IGEgSFRUUCBwcm94eSB2aWEgYW55Y2FzdCwgSSBkb24ndCBzZWUgd2h5IHdlIG5lZWQgdG8gZG8g dGhlIHNhbWUgZm9yIFdlYlJUQy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+V2hhdCBhcmUgdGhlIGhlc2l0 YXRpb25zIHJhaXNlZCBoZXJlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgVFVSTiBw cmltYXJpbHkgdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dzLCBhcyBvcHBvc2VkIHRvIHVzaW5nIGl0 IGFzIGEgTkFUIHRyYXZlcnNhbCB0b29sLiBUaGlzIG1ha2VzIG1lIGNvbmNlcm5lZA0KIHRoYXQg d2UgbWF5IGJlIHVzaW5nIHRoZSB3cm9uZyB0ZWNobm9sb2d5IHRvIHNvbHZlIHRoZSBwcm9ibGVt PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+SXQgaXMgY29ycmVjdCB0aGF0IElD RS9TVFVOL1RVUk4gd2FzIGRlc2lnbmVkIHRvIGFkZHJlc3MgdGhlIE5BVC9GaXJld2FsbCB0cmF2 ZXJzYWwgcHJvYmxlbSBhc3NvY2lhdGVkDQogd2l0aCByZWFsLXRpbWUgY29tbXVuaWNhdGlvbiAo U0lQIGF0IHRoYXQgdGltZSkuIEhvd2V2ZXIsIGl0cyBsYXJnZXN0IGZsYXcvcHJvYmxlbSBpcyB0 aGF0IHF1YWxpdHkgdGhpbmdzIHdlcmUgbm90IChjb3VsZCBub3QgYmU/KSBjb25zaWRlcmVkLiBU aGUgbWV0aG9k4oCZcyB2ZXJ5IGlkZWEgKGxpa2UgYWxsIHNpbWlsYXIgbWV0aG9kcyBmb3IgZ2V0 dGluZyBSVEMgdGhyb3VnaCBvcmRpbmFyeSBOQVQvRmlyZXdhbGxzKSBpcyB0byBmb29sIHRoZSBt ZWRpYQ0KIHRocm91Z2ggYSBOQVQvRmlyZXdhbGwgdGhhdCBpcyB1bmF3YXJlIG9mIHdoYXQgaXMg aGFwcGVuaW5nLiBUaHVzLCB0aGlzIGlzIHJvb3Qgb2YgcXVhbGl0eSBpc3N1ZXMgKGFuZCBiYW5k d2lkdGggYWxsb2NhdGlvbiBvcHRpbWl6YXRpb24pIHRoYXQgbmVlZHMgdG8gYmUgZGVhbHQgd2l0 aDogUmVhbC10aW1lIHRyYWZmaWMgZmlnaHRpbmcgd2l0aCBhIGRhdGEgdHJhZmZpYyBjcm93ZGVk IGNvbmdlc3Rpb24gcG9pbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRoaW5r IHRoYXQgJnF1b3Q7Zm9vbGluZyZxdW90OyBpcyBhbiBpbmNvcnJlY3QgZGVzY3JpcHRpb24uIFRo ZSBOQVQgaXMgc3VwcG9zZWQgdG8gYmUgdHJhbnNwYXJlbnQgdG8gdGhlIGNsaWVudC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 Ymx1ZSI+QnV0LCBhIEJMRVNTSU5HIG9mIElDRS9TVFVOL1RVUk4gaXMgdGhhdCBpdCBjYW4gYmUg c2VlbiBhcyBhIGxlZ2l0aW1hdGUgcmVxdWVzdCBmb3IgYSBzdWl0YWJsZSBwaXBlIGZvcg0KIHF1 YWxpdHkgZGVtYW5kaW5nIHJlYWwgdGltZSB0cmFmZmljLiA8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOmJsdWUiPko8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj5JQ0UgaXMgYSBwcmUtcHJvdG9jb2wgeW91IHVzZSBiZWNhdXNlIHlvdSB3YW50 IGEgcGF0aCBmb3IgcmVhbC10aW1lIG1lZGlhIGJldHdlZW4gcGFydGllcy4gSGVyZTogVGhlIGJy b3dzZXINCiBzYXlzIGtub2NrIGtub2NrLCBJIHdhbnQgdG8gZ2V0IG1lZGlhIHRocm91Z2ggKGFu ZCBvZiBjb3Vyc2Ugd2l0aCBhcyBnb29kIHF1YWxpdHkgYXMgcmVxdWlyZWQgYW5kIHBvc3NpYmxl KS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6Ymx1ZSI+SWYgdGhlIE5BVC9GaXJld2FsbCBvd25lciBhbmQgbmV0d29yayBvd25lciBhcmUg YWxsb3dlZCB0byBzZWUgdGhlc2UgcmVxdWVzdHMsIHRoZXkgY2FuIGhlbHAvYXNzaXN0IGluDQog YWNoaWV2aW5nIHRoZSBnb29kIG1lZGlhIHBhdGguIElmIHRoZXkgYXJlIG5vdCBhd2FyZSwgdGhl eSBjYW5ub3QgaGVscCE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+ SG9wZSB0aGlzIG1hZGUgaXQgdW5kZXJzdGFuZGFibGUgb24gYW4gb3ZlcnZpZXcgbGV2ZWwgaG93 IHRoaXMgY2FuIGJlY29tZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiDi gJxUVVJO4oCmdG8gaWRlbnRpZnkgV2ViUlRDIGZsb3dz4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsdWUiPkl0IGlzIGFsc28gdGhlIE9OTFkgd2F5IEkgY2FuIHNlZSB0byBhY2hpZXZlIHdoYXQg d2Ugd2FudCB0byBhY2hpZXZlIGFuZCBzaG91bGQgYmUgdGhlIGFpbSBhbmQgcmVxdWlyZW1lbnQN CiBvZiB0aGlzIG1pbGVzdG9uZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkkgYW0gdGFsa2luZyBhYm91dCBnZW5lcmFsIHVzYWdl IG9mIFdlYlJUQyBvdmVyIEludGVybmV0L21vYmlsZSBPVFQgKG5vdCBmZWVkaW5nIFdlYlJUQyBp bnRvIGFwcGxpY2F0aW9uDQogc3BlY2lmaWMgbmV0d29ya3MgbGlrZSBJTVMgd2hlcmUgb3RoZXIg bWV0aG9kcyBtYXkgZXhpc3QpLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlRoaXMgaXMgZ29vZCwgbm90IGV2aWwhPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5JZiB0 aGUgaGVzaXRhdGlvbnMgYXJlIHJhaXNlZCBiZWNhdXNlIG9mIGEgYmVsaWVmL2hvcGUvd2lzaCB0 aGF0IHRoZXJlIGFyZSBubyBvciB3aWxsIG5vdCBiZSBzZXZlcmUgcXVhbGl0eQ0KIGlzc3VlcyDi gJxiZWNhdXNlIGl0IGlzIGFsbCBhYm91dCBiYW5kd2lkdGjigJ0sIOKAnGl0IHdpbGwgcmVzb2x2 ZSBpdHNlbGYgd2l0aCB0aW1l4oCdIGV0Yy4sIEkgc3Ryb25nbHkgb2JqZWN0ISBUaGF0IGlzIHdy b25nIGFuZCB3aWxsIGJlIHZlcnkgZGV0cmltZW50YWwgZm9yIFdlYlJUQyB1c2FnZS4gV2UgYWxy ZWFkeSBzZWUgaXQgYW5kIEkgY2FuIGdpdmUgbnVtZXJvdXMgZXhhbXBsZXMgb2YgaG93IG11Y2gg bGVzcyBxdWFsaXR5IGRlbWFuZGluZyBWb0lQDQogaXMvaXMgbm90IGhhbmRsZWQgcXVhbGl0eSB3 aXNlIGFuZCB0aGF0IGl0IG1hdHRlcnMuIEFuZCwgd2hhdCB3b3VsZCBiZSBiYWQgY29uc2lkZXJp bmcgcXVhbGl0eSBpc3N1ZXMgYW5kIGFsbG93aW5nL2VuY291cmFnaW5nIG1ldGhvZHMgdG8gZGVh bCB3aXRoIHRoZW0/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPklm IHRoZSBoZXNpdGF0aW9ucyBhcmUgcmFpc2VkLCBiZWNhdXNlIG9mIHN1c3BpY2lvbiB0aGF0IHRo ZSBtZXRob2RzIHdlIG1heSByZWNvbW1lbmQgbWF5IGJlIG1pc3VzZWQgdG8NCiBzdG9wL2Jsb2Nr L2Rlc3Ryb3kgV2ViUlRDIHVzYWdlIChlLmcuIHRvIHByb3RlY3QgaW5jb21lIGZyb20gY2Fycmll ciB0ZWxlcGhvbnkgdHJhZmZpYyksIEkgY291bGQgdW5kZXJzdGFuZCBhbmQgd291bGQgZmlnaHQg dGhlIHNhbWUgYmF0dGxlLiBCdXQgaG9wZWZ1bGx5LCB0aG9zZSBkYXlzIGFyZSAoc29vbikgb3Zl ciDigJMgQXQgbGVhc3QgZm9yd2FyZCB0aGlua2luZyBjYXJyaWVy4oCZcyByZWFsaXplIHRoYXQg YWxyZWFkeS4gV2ViIFJUQyB3aWxsDQogaGFwcGVuLiBXaGljaCBjdXN0b21lcnMgd2FudCB0byBw YXkgZm9yIGFuIGFjY2VzcyB3aXRoIGJsb2NrZWQgV2ViUlRDPyBUaGUgY2FycmllcuKAmXMgb2Zm ZXJpbmcvYXNzdXJpbmcgZ29vZCBXZWJSVEMgd2lsbCByYXRoZXIgZ2V0IHRoZSBjdXN0b21lcnMg YW5kIGluY29tZQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OldpbmdkaW5ncztjb2xvcjpibHVlIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6Ymx1ZSI+LiAoTWF5YmUgdGhlIFdlYiBicm93c2VyIGNhbiBkZXRlY3QgYW5kIGVu Y291cmFnZSB0aGlz4oCmKTwvc3Bhbj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPklmIHRoZXJlIGFyZSB0ZWNobmljYWwgY29u Y2VybnMgb2YgYmFkIHJlc3VsdCwgb3IgYmV0dGVyIG1ldGhvZHMgYWxsb3dpbmcgbmV0d29yayBw cm92aWRlcnMgYW5kIExBTiBtYW5hZ2Vycw0KIHRvIG9mZmVyIGFuZCBpbmZvcm0gdGhlIGJyb3dz ZXIgdGhhdCB0aGVyZSBhcmUgZ29vZCBtZWRpYSBwYXRocyB0byBiZSB1c2VkLCBhbmQgdGhhdCB0 aGUgd2ViIGJyb3dzZXIgYXV0b21hdGljYWxseSBjYW4gY2hvc2UgdGhvc2UsIHRoZW4gbGV0IHVz IGFsbCB1bmRlcnN0YW5kIHRob3NlLCBzbyB3ZSBjYW4gYWNoaWV2ZSB3aGF0IHNob3VsZCBiZSBh Y2hpZXZlZCBieSB0aGlzIG1pbGVzdG9uZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlNreXBlLCBIYW5nb3V0cywgRmFjZXRpbWUgYXJlIGRvaW5nIGJpbGxpb25zIG9mIG1pbnV0ZXMg cGVyIHdlZWsgYW5kIHRoZSBJbnRlcm5ldCBoYXMgbm90IG1lbHRlZCB5ZXQuIElmIHdlIG5lZWQg dG8gZG8gZmxvdyBpZGVudGlmaWNhdGlvbiB0byBhbGxvdyB0cmFmZmljIHRvIGJlIHByaW9yaXRp emVkLCBmaW5lDQogKHNlZSBhYm92ZSByZWdhcmRpbmcgbXkgcHJlZmVycmVkIGFwcHJvYWNoKSwg YnV0IGZvcmNpbmcgYWxsIFdlYlJUQyB0cmFmZmljIHRocm91Z2ggYSBNSVRNIChUVVJOIHNlcnZl cikgaXMgYSBtdWNoIGJpZ2dlciBqdW1wIHRoYXQgSSBkb24ndCB5ZXQgc2VlIHRoZSBqdXN0aWZp Y2F0aW9uIGZvci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkluIHNob3J0OiBUVVJOIGlzIGEgdGVjaG5vbG9neSB0aGF0IGlzIHN1cHBv c2VkIHRvIGZhZGUgYXdheSB3aXRoIHRoZSBtb3ZlIHRvIElQdjYuIEkgZG9uJ3QgdGhpbmsgd2Ug d2FudCB0byBtYWtlIGl0IGEgY3JpdGljYWwgZWxlbWVudCBvZiBXZWJSVEMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUi Pi9LYXJsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibHVlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnLDpW46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IERhbiBXaW5nIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkd2luZ0BjaXNjby5j b20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHdpbmdAY2lz Y28uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGJyPg0KPGI+ U2tpY2thdDo8L2I+IGRlbiAxMSBmZWJydWFyaSAyMDE0IDE4OjI1PGJyPg0KPGI+VGlsbDo8L2I+ IDwvc3Bhbj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk1hcmMgQmxhbmNo ZXQ8YnI+DQo8Yj5Lb3BpYTo8L2I+IEp1c3RpbiBVYmVydGk7IDwvc3Bhbj48YSBocmVmPSJtYWls dG86dGlyZWRkeUBpY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij50aXJlZGR5QGljaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIGxh bmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Ow0KIEthcmwgU3RhaGw7IDwvc3Bhbj48YSBo cmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFu Zz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij47IFNpbW9uIFBlcnJlYXVsdDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJTViI+PGJyPg0KPGI+w4RtbmU6PC9iPiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJO IHNlcnZlciBhdXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5PbiBGZWIgMTEsIDIwMTQsIGF0IDk6MDgg QU0sIE1hcmMgQmxhbmNoZXQgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWFyYy5ibGFuY2hl dEB2aWFnZW5pZS5jYSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIj5tYXJjLmJsYW5j aGV0QHZpYWdlbmllLmNhPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViI+Jmd0Ow0KIHdyb3RlOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n PSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPkxlIDIwMTQtMDItMTEgw6AgMDA6MzksIERhbiBXaW5n ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmR3aW5nQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPjxzcGFuIGxhbmc9IlNWIj5kd2luZ0BjaXNjby5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9 IlNWIj4mZ3Q7IGEgw6ljcml0IDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0 b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpPbiBGZWIgMTAsIDIwMTQsIGF0IDU6MzAgUE0sIEp1 c3RpbiBVYmVydGkgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86anViZXJ0aUBnb29nbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pmp1YmVydGlAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZndDsNCiB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Hb29kIHRvIHNlZSB0aGVyZSBpcyBhIGxvdCBvZiBpbnRlcmVz dCBmb3IgdGhpcyBtaWxlc3RvbmUuIEJ1dCBiYXNlZCBvbiB0aGUgZGVzY3JpcHRpb24gaGVyZSwg aXQgc2VlbXMNCiBsaWtlIHdlIHdhbnQgdG8gdXNlIFRVUk4gcHJpbWFyaWx5IHRvIGlkZW50aWZ5 IFdlYlJUQyBmbG93cywgYXMgb3Bwb3NlZCB0byB1c2luZyBpdCBhcyBhIE5BVCB0cmF2ZXJzYWwg dG9vbC4gVGhpcyBtYWtlcyBtZSBjb25jZXJuZWQgdGhhdCB3ZSBtYXkgYmUgdXNpbmcgdGhlIHdy b25nIHRlY2hub2xvZ3kgdG8gc29sdmUgdGhlIHByb2JsZW0uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+JiM0MzsxLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkkgd291bGQgcHJlZmVyIGFsbG93aW5nIGZsb3dzIHRvIGVzdGFibGlzaCB0aGVtc2Vs dmVzIHVzaW5nIHRoZWlyICdiZXN0JyBwYXRoLCBhbmQgdGhlIGJlc3QgcGF0aCBpcw0KIHNlbGRv bSB0aHJvdWdoIGEgVFVSTiBzZXJ2ZXIuICZuYnNwO1doZW4gd2UgaW1hZ2luZSBJUHY2IGluIG91 ciBmdXR1cmUsIHdlIGRvbid0IHdhbnQgdG8gZm9yY2UgYW4gYXBwbGljYXRpb24tbGV2ZWwgcHJv eHkgKFRVUk4pIHNlcnZlciBvbiB0aGUgcGF0aCBzb2xlbHkgZm9yIHRyYXZlcnNpbmcgYW4gSVB2 NiBmaXJld2FsbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JdCBzZWVtcyB0aGlz IHRocmVhZCBpcyBjb25mbGF0aW5nIGFsbCB0aGUgcG9zc2libGUgcmVhc29ucyAvIGp1c3RpZmlj YXRpb25zIGZvciBUVVJOOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOyAqIG1vYmlsaXR5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7ICogTkFUIHRyYXZlcnNhbCAoYm90aCBlbmRwb2ludHMgYXJlIGJlaGlu ZCBlbmRwb2ludC1kZXBlbmRlbnQgbWFwcGluZyBOQVRzKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyAqJm5ic3A7ZmlyZXdhbGwgdHJhdmVyc2FsIChm aXJld2FsbCBibG9ja3MgVURQKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOyAqIGVuaGFuY2luZyBwcml2YWN5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+VW5mb3J0dW5hdGVseSB0aGUgVFVSTiBzZXJ2ZXIgbm9yIHRoZSBlbmRw b2ludCByZWFsbHkga25vdyB3aGljaCBvZiB0aG9zZSB1c2UtY2FzZXMgaXMgZGVzaXJlZCAoYnkg dGhlDQogdXNlciBvciBieSB0aGUgSVQgbmV0d29yayBhZG1pbmlzdHJhdG9yKSBvciBuZWNlc3Nh cnkgKGZvciB0aGUgY2FsbCB0byB3b3JrIGF0IGFsbCkuDQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPkRhbiwgd2hpbGUgSSBhZ3JlZSBpbiBw cmluY2lwbGUsIEkgZG91YnQgdGhhdCBhIHVzZXIgY291bGQgZXZlciBzYXkgJnF1b3Q7SSB3YW50 IG1vYmlsaXR5IG9yIEkgd2FudCBOQVQgdHJhdmVyc2FsJnF1b3Q7LiBJIHRoaW5rIHRoZSB1c2Vy IG9ubHkgd2FudCB0aGUgY2FsbCB0byBzdWNjZWVkLCB3aGF0ZXZlcg0KIHRoZSBwcm9wZXJ0aWVz IG9mIGl0cyBuZXR3b3JrIHBvaW50IG9mIGF0dGFjaG1lbnQgYXJlLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj5TbyB3aGF0IGNh biB3ZSBkbz8gJm5ic3A7U2hvdWxkIHRoZSBUVVJOIHNlcnZlciBwcm92aWRlIGFueSBhbmQgYWxs IHNlcnZpY2VzIHRoZSBUVVJOIGNsaWVudCBtaWdodCBwb3NzaWJseSB3YW50LCBhcyB0aGF0IGlz IHdoYXQgYSByb2J1c3QgVFVSTiBzZXJ2ZXIgd2lsbCBkbywgYW5kIHRoZQ0KIGVuZHBvaW50IHNo b3VsZCBwcmVmZXIgVFVSTiBjYW5kaWRhdGVzIG92ZXIgYWxsIG90aGVycyBiZWNhdXNlIHRoZXJl IG1pZ2h0IGJlIHNvbWUgZnVuY3Rpb25hbGl0eSAvIHVzZWZ1bG5lc3Mgb2YgVFVSTiB0aGF0IHRo ZSB1c2VyIG1pZ2h0IGdhaW4gdGhyb3VnaCBUVVJOIChlLmcuLCBlbmhhbmNlZCBwcml2YWN5KT88 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4tZDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gbGFuZz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7VGhpcyBzZWVtcyBwcm9ibGVtYXRpYy4gJm5ic3A7UGVyaGFwcyB3ZSBuZWVk IGEgd2F5IHRvIHNpZ25hbCB0aGUgZGVzaXJlZCB1c2UtY2FzZSAoJnF1b3Q7dHJhaXQmcXVvdDsp LCBvciBhcyBKdXN0aW4NCiBzdWdnZXN0cywgdXNpbmcgYSBkaWZmZXJlbnQgdGVjaG5vbG9neSBm b3Igc29tZSBvZiB0aGVzZSB1c2UtY2FzZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+LWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iU1YiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+T24gTW9uLCBGZWIgMTAsIDIwMTQgYXQgMzox OCBQTSwgS2FybCBTdGFobCZuYnNwOyZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmthcmwuc3Rh aGxAaW50ZXJ0ZXguc2UiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+a2FybC5zdGFobEBpbnRlcnRleC5zZTwvc3Bhbj48L2E+PHNwYW4gbGFu Zz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsmbmJzcDt3cm90ZTo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5TaW1vbiw8YnI+DQo8YnI+DQpHb29kIHF1ZXN0aW9ucyAtIHNl ZSBpbmxpbmUgYmVsb3cgLS0mZ3Q7IC48YnI+DQpTb21lIG1vcmUgdGhvdWdodCBpcyByZXF1aXJl ZCE8YnI+DQo8YnI+DQovS2FybDxicj4NCjxicj4NCi0tLS0tVXJzcHJ1bmdsaWd0IG1lZGRlbGFu ZGUtLS0tLTxicj4NCkZyw6VuOiB0cmFtIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0 cmFtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+dHJhbS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KIEbDtnIgU2ltb24gUGVycmVh dWx0PGJyPg0KU2tpY2thdDogZGVuIDEwIGZlYnJ1YXJpIDIwMTQgMTU6MTY8YnI+DQpUaWxsOiBL YXJsIFN0YWhsOyZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFt QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+OyZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGlyZWRkeUBpY2lzY28uY29tIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRpcmVk ZHlAaWNpc2NvLmNvbTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxicj4NCsOEbW5lOiBSZTogW3RyYW1dIE1pbGVzdG9uZSAzOiBUVVJOIHNlcnZlciBh dXRvLWRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGVudGVycHJpc2UgYW5kIElTUHM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KS2FybCw8YnI+DQo8YnI+DQpJdCBpcyBncmVhdCB0 byBzZWUgc3VjaCBlbnRodXNpYXNtISBUaGFua3MhPGJyPg0KPGJyPg0KSSBoYXZlIGEgY291cGxl IHRlY2huaWNhbCBxdWVzdGlvbnMuLi48YnI+DQo8YnI+DQpMZSAyMDE0LTAyLTA4IDA4OjExLCBL YXJsIFN0YWhsIGEgw6ljcml0IDo8YnI+DQomZ3Q7IC0gTm90ZSB0aGF0IHRvIGFjaGlldmUgc29t ZSBvZiB0aGUgYWJvdmUgcG9pbnRzLCBUVVJOIG11c3QgYmUgZmF2b3JlZDxicj4NCiZndDsgb3Zl ciBTVFVOIHRvIGVuZm9yY2UgdGhhdCB0aGUgVFVSTi1wYXRoIGFjdHVhbGx5IGlzIHVzZWQuIChU aGUgQW55Y2FzdDxicj4NCiZndDsgbWV0aG9kIHN1Z2dlc3RlZCBiZWxvdywg4oCcYXV0b21hdGlj YWxseeKAnSBkb2VzIHRoaXMuKTxicj4NCjxicj4NCkkgdW5kZXJzdGFuZCB0aGUgU1RVTiB2cyBU VVJOIHByaW9yaXR5IGlzc3VlLiBCdXQgSSBkb24ndCBzZWUgaG93IGFueWNhc3QgYWZmZWN0cyBp dCBpbiBhbnkgd2F5LiBDYW4geW91IHBsZWFzZSBleHBsYWluPzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+LS0tIEdvb2QgcG9pbnQgLSBJIHdhcyBhIGJpdCBxdWljayBoZXJl IChtYXliZSB0b28gcXVpY2spPGJyPg0KV2UgaGF2ZSBnaXZlbiB0aGlzIHF1aXRlIGJpdCBvZiB0 aG91Z2h0LCBzaW5jZSBldmVuIGlmIGEgVFVSTiBzZXJ2ZXIgaXMgcHJvdmlkZWQgYW5kIGRpc2Nv dmVyZWQsIENVUlJFTlQgdXNhZ2Ugb2YgSUNFIG1heSBzdWdnZXN0IGEgY2FuZGlkYXRlIGZyb20g dGhlIHJlbW90ZSBwYXJ0eSB0aGF0IHdpbGwgbWFrZSBhIGNvbm5lY3Rpb24gd2l0aG91dCB0aGUg bmVlZC91c2FnZSBvZiB0aGUgVFVSTiBzZXJ2ZXIgKHRoYXQgd2Ugd2FudGVkIHRvIGJlIHVzZWQN CiBmb3IgdGhlIGdvb2QgcHVycG9zZXMgbGlzdGVkKS48YnI+DQo8YnI+DQpUaGUgb25seSB3YXkg d2UgZm91bmQgYXJvdW5kIHRoaXMsIHdhcyB0byBzdG9wIFNUVU4gdGhyb3VnaCB0aGUgSVAgZGVm YXVsdCBnYXRld2F5IChsaWtlIGEgcmVzdHJpY3RpdmUgRW50ZXJwcmlzZSBmaXJld2FsbCBkb2Vz IGluaGliaXRpbmcgSUNFIGNvbm5lY3Rpdml0eSwgd2hpY2ggb3RoZXJzIGFyZSBjb25jZXJuZWQg YWJvdXQuLi4pLiBTaW5jZSB0aGUgcHJvdmlzaW9uaW5nIG9mIGF1dG8tZGlzY292ZXJ5IHVzaW5n IHRoZSBhbnljYXN0IG1lY2hhbmlzbSwNCiB3b3VsZCBiZSBhZGRpbmcgYSByb3V0ZSBpbiBhIGRl ZmF1bHQgZ2F0ZXdheSwgYWRkaW5nIGEgZmlyZXdhbGwgcnVsZSB0byBlYXQgU1RVTiBwYWNrZXRz IHdvdWxkIGFzc3VyZSB0aGF0IHRoZSBwcm92aXNpb25lZCBUVVJOIHNlcnZlciBhY3R1YWxseSBi ZWNvbWVzIHVzZWQgKGFuZCBub3QgYnlwYXNzZWQgJnF1b3Q7YnkgYWNjaWRlbnQmcXVvdDspLiAo VGhhdCB3YXMgdGhlIHRob3VnaHQgYmVoaW5kIHRoZSDigJxhdXRvbWF0aWNhbGx54oCdIHdpdGhp biBxdW90ZXMuKTxicj4NCjxicj4NCkJVVCwgc2luY2UgeW91IGJyb3VnaHQgdXAgdGhlIHF1ZXN0 aW9uLCBhc3N1bWluZyB0aGF0IHdlIGhhdmUgdGhlIHBvd2VyIHRvIGVuZm9yY2UgV2ViUlRDIHVz YWdlIG9mIElDRSwgSSBiZWxpZXZlIGEgTVVTVCByZXF1aXJlbWVudCB0byB1c2UgYW4gYXV0by1k aXNjb3ZlcmVkIFRVUk4gc2VydmVyIGluc3RlYWQgb2YgU1RVTiwgd291bGQgc29sdmUgdGhlIHNh bWUgcHJvYmxlbS4gSG93ZXZlciwgdGhpbmtpbmcgZnVydGhlciAoaW4gcmVsYXRpb24NCiB0byB5 b3VyIG5leHQgcXVlc3Rpb24gLSAmcXVvdDthbnlvbmUgY291bGQgc2V0IHVwIGEgYmFkbHktbWFp bnRhaW5lZCZxdW90OyAtIGVuZm9yY2luZyBzdWNoIElDRSB1c2FnZSBtYXkgbm90IGJlIGdvb2Qu KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxh bmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQomZ3Q7IC0gM15yZCBU aGUgQW55Y2FzdCBtZXRob2QgYmVsb3cg4oCTIEkgc2VlIG5vIHByb2JsZW08YnI+DQomZ3Q7PGJy Pg0KJmd0OyBJdCBhbHNvIGhhcyB0aGUgYWR2YW50YWdlIG9mIGVuY291cmFnaW5nIChidXQgbm90 IHJlcXVpcmluZykgdGhlPGJyPg0KJmd0OyBTVFVOL1RVUk4gdG8gYmUgYnVpbHQgaW4gdGhlIGRl ZmF1bHQgZ2F0ZXdheSBvciBOQVQvZmlyZXdhbGwvYWNjZXNzPGJyPg0KJmd0OyByb3V0ZXIgaXRz ZWxmLCB3aXRoIGEgc2Vjb25kIGludGVyZmFjZSB0byBhIHB1YmxpYyBJUCBhZGRyZXNzIG9uIHRo ZTxicj4NCiZndDsgV0FOIHNpZGUuIChDdXJyZW50IHZvbHVtZSBkZXBsb3llZCwgbG93IGNvc3Qg TlNQIHRyaXBsZSBwbGF5IG1vZGVtczxicj4NCiZndDsgdXN1YWxseSBoYXZlIGEgcXVhbGl0eSBh c3N1cmVkIGxldmVsIDIgb3IgbGV2ZWwgMyBXQU4gcGlwZSBmb3IganVzdDxicj4NCiZndDsgdm9p Y2UgKGFuZCBhbm90aGVyIGZvciBJUFRWKSDigJMgVGhlIGFueWNhc3QgZGlzY292ZXJlZCBUVVJO LXNlcnZlciBjYW48YnI+DQomZ3Q7IGJlIHRoZSBhY2Nlc3MgZ2F0ZXdheSB0byBzdWNoIHF1YWxp dHkgcGlwZSBmb3IgV2ViUlRDIG1lZGlhLCBpbiBhPGJyPg0KJmd0OyBzaW5nbGUgTlNQIHByb3Zp ZGVkIENQRSwgc2NhbGluZyBmcm9tIHJlc2lkZW50aWFsIGFuZCB1cC4pPGJyPg0KPGJyPg0KU3Vw cG9zZSB3ZSBkZWZpbmUgd2VsbC1rbm93biBhbnljYXN0IFRVUk4gc2VydmVyIGFkZHJlc3Nlcy4g SG93IHdvdWxkIHRoaXMgbm90IGJlIHN1YmplY3QgdG8gdGhlIHNhbWUgc2VydmljZSBxdWFsaXR5 IGlzc3VlcyB0aGF0IHBsYWd1ZWQgNnRvND8gVGhhdCBpcywgYW55b25lIGNvdWxkIHNldCB1cCBh IGJhZGx5LW1haW50YWluZWQsIHVuZGVyLXByb3Zpc2lvbmVkIFRVUk4gc2VydmVyIGFuZCBhbm5v dW5jZSBpdCBvdmVyIEJHUCB0byB0aGUgd29ybGQsDQogYXMgaXQgd2FzIGRvbmUgZm9yPGJyPg0K NnRvNCByZWxheXMuIE9yIGp1c3QgYmFkIEJHUCBvdXRib3VuZCBmaWx0ZXIgY29uZmlndXJhdGlv bi4gQW5kIGhvdyBjYW4gd2UgcHJldmVudCB0cmlhbmdsZSByb3V0aW5nPyBUaGVyZSBpcyBub3Ro aW5nIGd1YXJhbnRlZWluZyB0aGF0IHRoZSBhbnljYXN0IHNlcnZlciB5b3Ugc2VlIGlzIGJlaW5n IHByb3ZpZGVkIHRvIHlvdSBieSB5b3VyIElTUCwgcmF0aGVyIHRoYW4gYSBzZXJ2ZXIgc2l0dGlu ZyBvbiB0aGUgb3RoZXIgc2lkZSBvZiB0aGUgcGxhbmV0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+LS0tIEdvb2QgcG9pbnQgLSBuZWVkcyB0byBiZSByZXNvbHZlZC4gRm9y IHRoaXMgSSBkb24ndCBoYXZlIGEgcmVhZHkgYW5zd2VyLi4uPGJyPg0KQW4gYXV0by1kaXNjb3Zl cmVkIFRVUk4gc2VydmVyIG11c3QgYmUgdHJ1c3RlZCAod2hhdGV2ZXIgbWV0aG9kIGl0IGlzIGRp c2NvdmVyZWQgYnkpLiBXZSBhcmUgdHJ1c3RpbmcgdGhlIG9uZSBwcm92aWRpbmcgdXMgd2l0aCBh biBJUCBhZGRyZXNzIGFuZCBkZWZhdWx0IGdhdGV3YXkgYW55d2F5LiBJdCB3b3VsZCBiZSBlYXN5 IGlmIHdlIGNvdWxkIHJldXNlIHRoYXQgdHJ1c3QsIGluc3RlYWQgb2YgYW5vdGhlciBtZWNoYW5p c21zLjxicj4NCjxicj4NCklzIHRoZXJlIGEgZ29vZCB3YXkgZm9yIHRoZSBicm93c2VyIHRvIGNo ZWNrIHRoYXQgdGhlIGFueWNhc3QgYWRkcmVzcyBpcyBub3QgaGFuZGxlZCBiZXlvbmQgdGhlIG5l dHdvcmsgc2VydmljZSBwcm92aWRlcidzIGRlZmF1bHQgZ2F0ZXdheT8gSWRlYXM/PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8YnI+DQpUaGFu a3MsPGJyPg0KU2ltb248YnI+DQotLTxicj4NCkRUTiBtYWRlIGVhc3ksIGxlYW4sIGFuZCBzbWFy dCAtLSZndDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3Bvc3RlbGxhdGlvbi52aWFnZW5p ZS5jYS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+aHR0cDovL3Bvc3RlbGxhdGlvbi52aWFnZW5pZS5jYTwvc3Bhbj48L2E+PHNwYW4gbGFu Zz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCk5BVDY0L0ROUzY0IG9wZW4tc291 cmNlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tJmd0OyZuYnNwOzwvc3Bhbj48YSBocmVm PSJodHRwOi8vZWNkeXNpcy52aWFnZW5pZS5jYS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5n PSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cDovL2VjZHlzaXMudmlhZ2VuaWUuY2E8 L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpT VFVOL1RVUk4gc2VydmVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAtLSZndDsmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL251bWIudmlhZ2VuaWUu Y2EvIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPmh0dHA6Ly9udW1iLnZpYWdlbmllLmNhPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBo cmVmPSJtYWlsdG86dHJhbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNW IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L3NwYW4+PC9hPjxzcGFuIGxhbmc9IlNWIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCnRyYW0gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFu PjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFu Zz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnRyYW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFtIiB0YXJnZXQ9Il9i bGFuayI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IlNWIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iU1YiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KdHJhbSBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOnRyYW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+dHJhbUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iU1Yi IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBs YW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90cmFtPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQp0cmFtIG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86dHJhbUBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij50cmFtQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJTViIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdHJhbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IlNWIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RyYW08L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IlNWIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJTViI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp0cmFtIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp0cmFtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+dHJhbUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RyYW0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RyYW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_913383AAA69FF945B8F946018B75898A242AF62Fxmbrcdx10ciscoc_-- From nobody Mon Feb 17 09:03:23 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D821A050E for ; Mon, 17 Feb 2014 09:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 byNvmoaWXm9r for ; Mon, 17 Feb 2014 09:03:20 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEF41A04ED for ; Mon, 17 Feb 2014 09:03:20 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 535B9401FE for ; Mon, 17 Feb 2014 12:03:17 -0500 (EST) Message-ID: <530240D5.8090209@viagenie.ca> Date: Mon, 17 Feb 2014 12:03:17 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <52F8EA80.8000104@viagenie.ca> In-Reply-To: <52F8EA80.8000104@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/maKVGCWiZkA4PoZLumkBhc2OboU Subject: Re: [tram] Agenda for London X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 17:03:22 -0000 The agenda is now at its official location: http://datatracker.ietf.org/meeting/89/agenda/tram/ Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Mon Feb 17 10:29:17 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE031A052B for ; Mon, 17 Feb 2014 10:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 VmEq0uEoM9vm for ; Mon, 17 Feb 2014 10:29:13 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9103C1A0239 for ; Mon, 17 Feb 2014 10:29:13 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id y10so15155073pdj.4 for ; Mon, 17 Feb 2014 10:29:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d8rJqBMB6YIUs3oSY1UBSw1jsx6NYxQ6oICVTfszlk4=; b=DxUCqnc8S8lhjCw6nDSKoVLIevo+OjTTYEpMoU5Qq8NVJqqThTKHnZblYb2u0/2Xn3 YQwuxhNNodzNiXbj0Bxl8s+RmatMnIodWF/dlnVVHZAJjbuWoYwFhG+MaANjULdyH1MO nHtioyvWhLLRRAdZHHrziLQ1xsM+p9GS5j2joS0ua1Kbin1Z4uFmM278tFCxXsQZ2PSM zZs5bXvyF1Ozs4NDBYiEEWxUiKL5lvnQ7Ppu4fIsQ6JIn4ccogRDzBo6/KlDFgDHLdmY VO7CFjc/psMzxhUO5ew/+4mufDTRdLa3xACvB3YymL3O7Td4EY6LEoxZhwO67rvmzSOD audQ== MIME-Version: 1.0 X-Received: by 10.66.160.2 with SMTP id xg2mr27777209pab.23.1392661751061; Mon, 17 Feb 2014 10:29:11 -0800 (PST) Received: by 10.68.147.131 with HTTP; Mon, 17 Feb 2014 10:29:11 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A242AF33F@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242AF33F@xmb-rcd-x10.cisco.com> Date: Mon, 17 Feb 2014 10:29:11 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7bacb47cf6e0a804f29e5421 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/CJt1EUCIkHX_EeR0EDmsJDB08_g Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 18:29:16 -0000 --047d7bacb47cf6e0a804f29e5421 Content-Type: text/plain; charset=ISO-8859-1 Hi Tiru please see below as [Oleg]: On Mon, Feb 17, 2014 at 3:10 AM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > Hi Oleg, > > Thanks for the review. Please see inline [TR] > > From: Oleg Moskalenko [mailto:mom040267@gmail.com] > Sent: Sunday, February 16, 2014 10:31 AM > To: Tirumaleswar Reddy (tireddy) > Cc: tram@ietf.org > Subject: Re: [tram] FW: New Version Notification for > draft-reddy-tram-turn-third-party-authz-00.txt > > Hi Tiru > I have some comments: > 1) Section 4. Obtaining a Token Using OAuth, figure 4 > > I believe that the sequence of messages is incorrect. The TURN server most > probably will contact the Authorization server AFTER it gets the Allocate > request. But on the figure 4, it looks like it somehow can predict the > incoming request. The correct sequence must be, in the general case: > Access Token Request (1) from client to Auth server > Access Token + Session Key (2) from Auth server to client > Allocate request from client to TURN server (3) > Get Token from TURN Server to Auth server (4) > Token metadata from Auth Server to TURN server (5) > Allocate response from TURN server to the client (6) > > [TR] Good catch, fixed it. It got messed when we were changing from > self-contained to handle token. > > The sequence shown on the figure 4 is possible only is the Auth Server and > TURN server are somehow closely integrated and that is unnecessary. > > [TR] Yes, the AS and TURN server have to be integrated. There may be ways > to standardize this, but this is not in the scope of this doc right away. > [Oleg]: I am afraid that if we require that AS and TURN to be provided by the same company, it may affect the adoption of this approach. > > 2) The document is saying that the client when communicating to the Auth > Server uses HTTP requests with JSON (REST API ?). May be it would be > helpful if the communication protocol between TURN server and Auth server > would be mentioned, too. > > [TR] Drafts in OAuth WG like > https://tools.ietf.org/html/draft-richer-oauth-introspection-04 discuss > the communication mechanism b/w Resource Server and Authorization server. > You may also want to look into > http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html which > discusses such communication mechanism already implemented but for a > different purpose. I guess it all worked because Resource server and > Authorization server are developed by the same company but with this use > case we may have to discuss if standardization is required for the > communication mechanism. > [Oleg]: As I said, if the AS and TURN in practice will have to be provided by the same company, then that may be a problem - it will affect the standard adoption by the WebRTC community. I'll have to explore the current situation with the open-source OAuth servers - whether they provide a viable "introspection" protocol. I hope some protocol recommendations can be provided for third-party AS communications. > > 3) Section 7.2: > > OAuth does not impose any limitation on the length of the access token > but since > STUN messages cannot exceed 548 bytes (Section 7.1 of [RFC5389]), > access token length needs to be restricted to fit within the maximum > STUN message size. > > I am not sure that the STUN (Binding ?) max message size is relevant here > and worth mentioning at all - because this doc is about TURN, and the TURN > messages are often much larger than 548 bytes (especially when carrying the > video traffic). So I see no relevance of the 548 limit to the new > authentication standard. And that limitation of 548 bytes is applicable > only to the cases when we suspect that the path MTU is really really low > and that is an extremely rare case. > > [TR] Good point. But RFC 5766 recommends to restrict the size (Section 2.7 > Avoiding Fragmentation) > > > > As a guideline, sending a maximum of 500 bytes of application data in > a single TURN message (by the client on the client-to-server leg) or > a UDP datagram (by the peer on the peer-to-server leg) will generally > avoid IP fragmentation. > > > [Oleg]: We recently had a discussion about that in WebRTC forum, with Justin. He is saying that the WebRTC client tools (Chrome) assume the minimum practical MTU as 1280 and that limit is used for media traffic. And he is right that this MTU is a real modern practical limit. > > > 4) Are we sure that we want to limit the OAuth applicability only to the > long-term credentials mechanism ? I see no technical or philosophical > reasons why not to use it for short-term credentials mechanism, too. It > would be a more "symmetric" approach. > > [TR] what is the use case for short-term credential mechanism with TURN ? > [Oleg]: Currently WebRTC uses only the long-term credentials mechanism but still there is a TURN standard for the short-term mechanism. While I cannot provide any concrete example, I suppose there are some. And I believe that OAuth is orthogonal to the TURN auth mechanism used - they can be combined either way. So I see that coupling OAuth with the long-term mechanism is rather artificial. > > 5) I'd put more definite wording how TURN server handles the token > lifetime. What happens in the middle of the TURN session, is the auth token > expires while the session is still active ? There may be two possible cases: > - the token lifetime is applicable only to the session initiation > procedure. When the TURN session has been already established, it can go > indefinitely while the client is refreshing the session properly. > - in second case when the token expires, the server rejects new > requests from the client (in the same TURN session) until the client sends > the new token data in re-authentication exchange. > > I'd suggest the first case as an eisier case for the implementation. > > [TR] The client MUST obtain a new token after the previously used one > expires. As you point out an already established TURN session can continue, > the new token is applicable for new requests. [Oleg]: Tiru, I'd still like to hear a more definite language: what about "new requests" within the existing session ? They are allowed to use the old token - right ? When you are saying "new requests" you mean "new session allocation requests", right ? Regards, Oleg --047d7bacb47cf6e0a804f29e5421 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tiru

please see below as [Oleg]:=



On Mon, Feb 17, 2014 at 3:10 AM, Tirumaleswar Reddy (tireddy) <tired= dy@cisco.com> wrote:
Hi Oleg,

Thanks for the review. Please see inline [TR]

From: Oleg Moskalenko [mailto:mom040= 267@gmail.com]
Sent: Sunday, February 16, 2014 10:31 AM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-= third-party-authz-00.txt

Hi Tiru
I have some comments:
1) Section 4. Obtaining a Token Using OAuth, figure 4

I believe that the sequence of messages is incorrect. The TURN server most = probably will contact the Authorization server AFTER it gets the Allocate r= equest. But on the figure 4, it looks like it somehow can predict the incom= ing request. The correct sequence must be, in the general case:
=A0=A0 Access Token Request (1) from client to Auth server
=A0=A0 Access Token + Session Key (2) from Auth server to client
=A0=A0 Allocate request from client to TURN server (3)
=A0=A0 Get Token from TURN Server to Auth server (4)
=A0=A0 Token metadata from Auth Server to TURN server (5)
=A0=A0 Allocate response from TURN server to the client (6)

[TR] Good catch, fixed it. It got messed when we were changing from s= elf-contained to handle token.

The sequence shown on the figure 4 is possible only is the Auth Server and = TURN server are somehow closely integrated and that is unnecessary.

[TR] Yes, the AS and TURN server have to be integrated. There may be = ways to standardize this, but this is not in the scope of this doc right aw= ay.

[Oleg]: I am afraid that if we requ= ire that AS and TURN to be provided by the same company, it may affect the = adoption of this approach.
=A0

2) The document is saying that the client when communicating to the Auth Se= rver uses HTTP requests with JSON (REST API ?). May be it would be helpful = if the communication protocol between TURN server and Auth server would be = mentioned, too.

[TR] Drafts in OAuth WG like https://tools.ietf.or= g/html/draft-richer-oauth-introspection-04 discuss the communication me= chanism b/w Resource Server and Authorization server. =A0You may also want = to look into http://www.ietf.org/mail-archive/web/oauth= /current/msg08607.html which discusses such communication mechanism alr= eady implemented but for a different purpose. I guess it all worked because= Resource server and Authorization server are developed by the same company= but with this use case we may have to discuss if standardization is requir= ed for the communication mechanism.

[Oleg]: As I said, if the AS and TURN in p= ractice will have to be provided by the same company, then that may be a pr= oblem - it will affect the standard adoption by the WebRTC community. I'= ;ll have to explore the current situation with the open-source OAuth server= s - whether they provide a viable "introspection" protocol. I hop= e some protocol recommendations can be provided for third-party AS communic= ations.=A0
=A0

3) Section 7.2:

=A0 =A0OAuth does not impose any limitation on the length of the access tok= en but since
=A0 =A0STUN messages cannot exceed 548 bytes (Section 7.1 of [RFC5389]), =A0 =A0access token length needs to be restricted to fit within the maximum=
=A0 =A0STUN message size.

I am not sure that the STUN (Binding ?) max message size is relevant here a= nd worth mentioning at all - because this doc is about TURN, and the TURN m= essages are often much larger than 548 bytes (especially when carrying the = video traffic). So I see no relevance of the 548 limit to the new authentic= ation standard. And that limitation of 548 bytes is applicable only to the = cases when we suspect that the path MTU is really really low and that is an= extremely rare case.

[TR] Good point. But RFC 5766 recommends to restrict the size (Sectio= n 2.7 Avoiding Fragmentation)

<snip>

=A0 =A0As a guideline, sending a maximum of 500 bytes of application data i= n
=A0 =A0a single TURN message (by the client on the client-to-server leg) or=
=A0 =A0a UDP datagram (by the peer on the peer-to-server leg) will generall= y
=A0 =A0avoid IP fragmentation.

</snip>

[Oleg]: We recently had a= discussion about that in WebRTC forum, with Justin. He is saying that the = WebRTC client tools (Chrome) assume the minimum practical MTU as 1280 and t= hat limit is used for media traffic. And he is right that this MTU is a rea= l modern practical limit.
=A0


4) Are we sure that we want to limit the OAuth applicability only to the lo= ng-term credentials mechanism ? I see no technical or philosophical reasons= why not to use it for short-term credentials mechanism, too. It would be a= more "symmetric" approach.

[TR] what is the use case for short-term credential mechanism with TU= RN ?

[Oleg]: Currently WebRTC uses only= the long-term credentials mechanism but still there is a TURN standard for= the short-term mechanism. While I cannot provide any concrete example, I s= uppose there are some. And I believe that OAuth is orthogonal to the TURN a= uth mechanism used - they can be combined either way. So I see that couplin= g OAuth with the long-term mechanism is rather artificial.
=A0

5) I'd put more definite wording how TURN server handles the token life= time. What happens in the middle of the TURN session, is the auth token exp= ires while the session is still active ? There may be two possible cases: =A0=A0 - the token lifetime is applicable only to the session initiation pr= ocedure. When the TURN session has been already established, it can go inde= finitely while the client is refreshing the session properly.
=A0=A0 - in second case when the token expires, the server rejects new requ= ests from the client (in the same TURN session) until the client sends the = new token data in re-authentication exchange.

I'd suggest the first case as an eisier case for the implementation.
[TR] The client MUST obtain a new token after the previously used one= expires. As you point out an already established TURN session can continue= , the new token is applicable for new requests. =A0

[Oleg]: Tiru, I'd still like to hear a more definite languag= e: what about "new requests" within the existing session ? They a= re allowed to use the old token - right ? When you are saying "new req= uests" you mean "new session allocation requests", right ?
=A0
Regards,
Oleg

--047d7bacb47cf6e0a804f29e5421-- From nobody Mon Feb 17 12:13:44 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A501A0550 for ; Mon, 17 Feb 2014 12:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 3tQrg3ii_KP2 for ; Mon, 17 Feb 2014 12:13:39 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 22CE91A0552 for ; Mon, 17 Feb 2014 12:13:38 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id e4so2792528wiv.5 for ; Mon, 17 Feb 2014 12:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zgXTyeUGpp4qL2f8nBslWCL+/xsrlUaJCVn90h3ZsCU=; b=0MGjcUKGjsuCVXEn0SmrUoG11jqPMz/2Rdpq+2HDywZ6HMH1U/1z5nGQ3hQqYEi8/u cCFRp44XJ2LuJnX3SZxIk+jZcTp7dzqTuehczrbzYl4THSx2ZM02GnwB/g3qrNHDfY3B NYDDZxsToNVwDZvpB6r5za941dU7zjRW+hVOWmp0oTaCLAPYlORz5ho3B0DZzkLeLDJj AuH8KONvhUvMR6SY0JLX3Zc4zATuTU8TK+pj64j4Jn4wvj+UMqlfLIne4TCquZb3My1d ThSWXmp6AJQY8X3IQg8XzDXE8OwE73OuhYiRlHD8QS/E1tyBQV+dl7rv51jpKhVPoiWV SFaQ== MIME-Version: 1.0 X-Received: by 10.180.102.42 with SMTP id fl10mr14815726wib.42.1392668016084; Mon, 17 Feb 2014 12:13:36 -0800 (PST) Received: by 10.217.152.10 with HTTP; Mon, 17 Feb 2014 12:13:36 -0800 (PST) In-Reply-To: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> Date: Mon, 17 Feb 2014 14:13:36 -0600 Message-ID: From: Alan Johnston To: "tram@ietf.org" Content-Type: multipart/alternative; boundary=90e6ba18132a638d4f04f29fca96 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/5jFLLJttd969c8N0-WUisTO5xGE Subject: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 20:13:42 -0000 --90e6ba18132a638d4f04f29fca96 Content-Type: text/plain; charset=ISO-8859-1 All, We have written a new I-D on a bandwidth attribute for TURN. The use case is to allow a TURN client to indicate to the server the bandwidth it expects to use for the relayed candidate, or for a TURN server to indicate to the client the maximum bandwidth before the TURN server might apply rate limiting. Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent which was discussed in the past, but this draft does not propose an ICE use case for consent. Comments most welcome! - Alan - ---------- Forwarded message ---------- From: Date: Thu, Feb 13, 2014 at 9:07 PM Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Bandwidth Attribute for TURN Authors : Martin Thomson Bernard Aboba Alan Johnston Oleg Moskalenko Filename : draft-thomson-tram-turn-bandwidth-00.txt Pages : 8 Date : 2014-02-13 Abstract: An attribute is defined for Session Traversal Utilities for NAT (STUN) that allows for declarations of bandwidth limits on the negotiated flow. The application of this attribute is the negotiation of bandwidth between a Traversal Using Relays around NAT (TURN) client and a TURN server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwidth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --90e6ba18132a638d4f04f29fca96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

We have written a new I-D on a ban= dwidth attribute for TURN. =A0The use case is to allow a TURN client to ind= icate to the server the bandwidth it expects to use for the relayed candida= te, or for a TURN server to indicate to the client the maximum bandwidth be= fore the TURN server might apply rate limiting.

Note some of the text is from=A0draft-thomson-mmusic-rt= cweb-bw-consent which was discussed in the past, but this draft does not pr= opose an ICE use case for consent.

Comments most w= elcome!

- Alan -

---------- F= orwarded message ----------
From: <internet-dra= fts@ietf.org>
Date: Thu, Feb 13, 2014 at 9:07 PM
Subject: I-D Action: draft-thomson-tr= am-turn-bandwidth-00.txt
To: i-= d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : A Bandwidth Attribute for TURN<= br> =A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Martin Thomson
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bernard Aboba
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Alan Johnston
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Oleg Moskalenko
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-thomson-tram-turn-bandwidth= -00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-02-13

Abstract:
=A0 =A0An attribute is defined for Session Traversal Utilities for NAT
=A0 =A0(STUN) that allows for declarations of bandwidth limits on the
=A0 =A0negotiated flow. =A0The application of this attribute is the
=A0 =A0negotiation of bandwidth between a Traversal Using Relays around NAT=
=A0 =A0(TURN) client and a TURN server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-thomson-tram-= turn-bandwidth/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-thomson-tram-turn-bandw= idth-00


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

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

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

--90e6ba18132a638d4f04f29fca96-- From nobody Mon Feb 17 15:48:06 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538481A05B1 for ; Mon, 17 Feb 2014 15:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 6pUXAxkO4SCX for ; Mon, 17 Feb 2014 15:48:00 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id C9BBA1A027C for ; Mon, 17 Feb 2014 15:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1201; q=dns/txt; s=iport; t=1392680878; x=1393890478; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Wz/TjMkxRTHp7Ff0erPySimM8uHB3vycPHKOeTTTkiI=; b=fnFH/XB8N6p3XBgMJn37iKVfSFvTaUTH9wpUbppccdv0xmt/5R9zbbYm /cvqxZTVDMca2MAglpeFxjuiCPAOSc+0fDeBf7BoyxLFcSp4fnSD12Eq/ kmTXT2N41SGUtybs33B8KGYMlAIypp2cOqfkR0V9Mx2dr+3m+VwhgPGZK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAMyeAlOtJV2Z/2dsb2JhbABZgwY4V8BgFnSCJQEBAQQBAQFrHQEIOzILGwEGBQQTiAUNmUGwfReOLYUTBIkQjxyBMpBxgW+BPoIq X-IronPort-AV: E=Sophos;i="4.95,863,1384300800"; d="scan'208";a="21133771" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 17 Feb 2014 23:47:57 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1HNlvgU019484 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Feb 2014 23:47:57 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 17:47:57 -0600 From: "Charles Eckel (eckelcu)" To: "tram@ietf.org" Thread-Topic: [Aeon] Time slots for AEON session at IETF 89 - Please indicate available via link below by Wed. Feb 19 Thread-Index: AQHPLDqumtNJ9L8wukKWAsGpI1Inkg== Date: Mon, 17 Feb 2014 23:47:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.79.36] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7D3E5286215D5E4D8104EE6BB72841AD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/L4FhLo3kzUbcVL9WNlnMSQMeJu0 Subject: [tram] FW: [Aeon] Time slots for AEON session at IETF 89 - Please indicate available via link below by Wed. Feb 19 X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 23:48:03 -0000 FYI, if you have interested in "Differentiated prIorities and Status Code-points Using Stun Signalling (DISCUSS)=B2, draft-martinsen-tram-discuss-00 (http://tools.ietf.org/html/draft-martinsen-tram-discuss-00), you may also be interested in subscribing to the AEON list and attending the AEON meeting announced in the forwarded e-mail. Cheers, Charles On 2/17/14, 10:12 AM, "Charles Eckel (eckelcu)" wrote: >AEON list members and other interested parties, > >We plan to reserve an IESG breakout room to have an AEON meeting at IETF >89 in London. >Please indicate which of the potential time slots work for you no later >than Wednesday, Feb 19. >All time slots are 1 hour in duration. >The actual location and time will be announced on the AEON list. > > >Preliminary agenda is as follows: >1) problem statement draft >2) draft charter > >The agenda will be finalized via a separate thread on the AEON list as >well. >Here is the link to the poll: >http://www.doodle.com/fb8k5hyqap4iqyye > > >Cheers, >Charles > >_______________________________________________ >Aeon mailing list >Aeon@ietf.org >https://www.ietf.org/mailman/listinfo/aeon From nobody Mon Feb 17 17:56:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EEF1A043D for ; Mon, 17 Feb 2014 17:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 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, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham 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 Zkczhr2pAsc1 for ; Mon, 17 Feb 2014 17:56:26 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 35AB61A051A for ; Mon, 17 Feb 2014 17:56:25 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id ie18so12183922vcb.26 for ; Mon, 17 Feb 2014 17:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IjasYAiWwGilZxYHJK5TyIzSf8c1FU378PpBsF78uj0=; b=X81N3mpL1vgKEKJCNZtjLkofbFvUlR9mP68f5TZvVv/Cp9iFbbaWNQUlObY0NAJ6BD m9xm9zHyp01mnJU032uSxLaxMeXuuAUsHxioK/MA4j/RZ6+OhYHsTlF/n9dEjbk1UYZy HMEVAL8MNCtTnrHnYhNv2ovBQOjASXQwXX+U8n3lMhAX/5d2unztkPI+OVtpT51BR2q/ rU99DQSh9ZQtFABajuP6AiAHRM1b9ouBCfnCchxNSC9LFDYuVn018f/YZcR/FNEEwq7l v1w0htqofOAnvutfWtnvnkf6CnTRjHIVFjF92t/KJTo23nSShjbqRbwrgMTdkKhBwLJr nIXQ== MIME-Version: 1.0 X-Received: by 10.52.61.168 with SMTP id q8mr3000415vdr.40.1392688582311; Mon, 17 Feb 2014 17:56:22 -0800 (PST) Received: by 10.58.100.212 with HTTP; Mon, 17 Feb 2014 17:56:22 -0800 (PST) Date: Tue, 18 Feb 2014 09:56:22 +0800 Message-ID: From: lingli deng To: tram@ietf.org Content-Type: multipart/mixed; boundary=001a1136b3743b83f404f2a494f8 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/aVOAZQeM_9mp9VZoIpn6ibJ1cNc Subject: [tram] considerations for ISP provided Turn server for webrtc X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 01:56:29 -0000 --001a1136b3743b83f404f2a494f8 Content-Type: multipart/alternative; boundary=001a1136b3743b83f004f2a494f6 --001a1136b3743b83f004f2a494f6 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Hi all, We have been following the discussion on relevant lists about ISP deployed Turn relay for webrtc traffic with high interest, and think it would be helpful to share some of our thoughts on this. The attached is an initial draft discussing three potential usecases, including traffic locality, resource sharing and QoS support, for an ISP to provide public relay facilities for third party webrtc traffic. Your review and comments would be highly appreciated. Best Regards, --=20 =B5=CB=C1=E9=C0=F2/Lingli Deng =D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0=BE=BF=D4=BA/China Mobile Researc= h Institute e-mail: denglingli@chinamobile.com tel: 15801696688-3367 mobile: 13810597148 --001a1136b3743b83f004f2a494f6 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Hi all,

We have been followi= ng the discussion on relevant lists about ISP deployed Turn relay for webrt= c traffic with high interest, and think it would be helpful to share s= ome of our thoughts on this.

The attached is an initial draft discussing three poten= tial usecases, including traffic locality, resource sharing and QoS su= pport, for an ISP to provide public relay facilities for third party w= ebrtc traffic.

Your review and comments would be highly appreciat= ed.

Best Regards,
--
=B5= =CB=C1=E9=C0=F2/Lingli Deng
=D6=D0=B9=FA=D2=C6=B6=AF=CD=A8=D0=C5=D1=D0= =BE=BF=D4=BA/China Mobile Research Institute
e-mail: denglingli@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148
--001a1136b3743b83f004f2a494f6-- --001a1136b3743b83f404f2a494f8 Content-Type: text/plain; charset=US-ASCII; name="draft-deng-tram-isp-turn-00.txt" Content-Disposition: attachment; filename="draft-deng-tram-isp-turn-00.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hrsilr780 IA0KDQoNCg0KTVBUQ1AgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBMLiBEZW5nDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQLiBGYW4NCkludGVuZGVkIFN0YXR1 czogSW5mb3JtYXRpb25hbCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIdWkgRGVu Zw0KRXhwaXJlczogQXVndXN0IDE0LCAyMDE0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgQ2hpbmEgTW9iaWxlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMTQsIDIwMTQNCg0KDQogICAgICAgICAgSVNQIFR1 cm4gU2VydmVyIEZvciBUaGlyZCBQYXJ0eSBXRUJSVEMgVHJhZmZpYyBSZWxheQ0KICAgICAgICAg ICAgICAgICAgICAgIGRyYWZ0LWRlbmctdHJhbS1pc3AtdHVybi0wMA0KDQpBYnN0cmFjdA0KDQog ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB1c2VjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGZvciBJ U1AgdG8gcHJvdmlkZQ0KICAgdGhlaXIgb3duIFRVUk4gc2VydmVycyB0byByZWxheSB0aGlyZCBw YXJ0eSBXRUJSVEMgdHJhZmZpYy4gDQoNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBUaGlz IEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCB0byBJRVRGIGluIGZ1bGwgY29uZm9ybWFuY2Ug d2l0aCB0aGUNCiAgIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIEludGVy bmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy aW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3Jv dXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3Jr aW5nIGRvY3VtZW50cyBhcw0KICAgSW50ZXJuZXQtRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFm dHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMN CiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBk b2N1bWVudHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50 ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90 aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50 IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvMWlkLWFic3RyYWN0cy5odG1sDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNo YWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvc2hhZG93Lmh0bWwNCg0KDQpDb3B5cmlnaHQgYW5kIExpY2Vuc2UgTm90aWNlDQoNCiAgIENv cHlyaWdodCAoYykgMjAxMyBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFz IHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gQWxsIHJpZ2h0cyByZXNlcnZlZC4NCg0KICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdh bA0KICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3VtZW50cw0KICAgKGh0dHA6Ly90 cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mDQog ICBwdWJsaWNhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiBQbGVhc2UgcmV2aWV3IHRoZXNlIGRvY3Vt ZW50cw0KICAgY2FyZWZ1bGx5LCBhcyB0aGV5IGRlc2NyaWJlIHlvdXIgcmlnaHRzIGFuZCByZXN0 cmljdGlvbnMgd2l0aCByZXNwZWN0DQogDQoNCg0KPERlbmcsIGV0IGFsLj4gICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMTQsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJTlRFUk5F VCBEUkFGVCAgICAgICAgICAgPElTUCBUVVJOIEZvciBXRUJSVEM+ICAgICAgICAgRmVicnVhcnkg MTQsIDIwMTQNCg0KDQogICB0byB0aGlzIGRvY3VtZW50LiBDb2RlIENvbXBvbmVudHMgZXh0cmFj dGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0DQogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExp Y2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YNCiAgIHRoZSBUcnVzdCBM ZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcw0KICAg ZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLg0KDQoNCg0KVGFibGUgb2Yg Q29udGVudHMNCg0KICAgMSAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAyICBUZXJtaW5vbG9neSAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDMgVXNlLWNh c2VzIGZvciBOZXR3b3JrIGRlcGxveWVkIFRVUk4gc2VydmVycyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAgMw0KICAgICAzLjEgVHJhZmZpYyBMb2NhbGl0eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAgIDMuMiBSZXNvdXJjZSBTaGFyaW5nIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgICAgMy4zICBJU1AgUW9T IFN1cHBvcnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0K ICAgNCAgU3VtbWFyeSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA0DQogICA1ICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgIDYgIEFja25vd2xlZGdlbWVudHMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgNyAg SUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA1DQogICA2ICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAgNi4xICBOb3JtYXRpdmUgUmVmZXJlbmNl cyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgQXV0aG9ycycg QWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA3DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K IA0KDQoNCjxEZW5nLCBldCBhbC4+ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDE0LCAyMDE0ICAg ICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSU5URVJORVQgRFJBRlQgICAgICAgICAgIDxJU1Ag VFVSTiBGb3IgV0VCUlRDPiAgICAgICAgIEZlYnJ1YXJ5IDE0LCAyMDE0DQoNCg0KMSAgSW50cm9k dWN0aW9uDQoNCiAgIEhpc3RvcmljYWxseSwgc3R1bi90dXJuIHNlcnZlcnMgYXJlIG5vdCBkZXBs b3llZCBieSBJU1BzLCBhcyBJQ0UgaXMNCiAgIGRlc2lnbmVkIHRvIGFsbG93IG5ldHdvcmstYWdu b3N0aWMgZmVhdHVyZS4gIA0KDQogICBJdCBpcyBlbnZpc2lvbmVkIHRoYXQgZHJpdmVuIGJ5IFdF QlJUQyBtb3ZlbWVudCwgdGhpcmQgcGFydHkgSUNFDQogICAoc3R1biBhbmQgdHVybikgd291bGQg c2VlIGluY3JlYXNpbmdseSBkZXBsb3ltZW50IGJvb3N0IGluIHRoZSBjb21pbmcNCiAgIHllYXJz LCBhcyB3ZWJydGMtY29tcGF0aWJsZSBicm93c2VycyByZWx5IG9uIElDRSBmcmFtZXdvcmsgdG8g ZW5hYmxlDQogICBOQVQgdHJhdmVyc2FsIGNhcGFiaWxpdGllcyBmb3IgcGVlci10by1wZWVyIG1l ZGlhIGNvbW11bmljYXRpb24uDQoNCiAgIEZvciB0dXJuLCB3aGljaCBpcyBlc3NlbnRpYWxseSBh IG1lZGlhIHJlbGF5IGdhdGV3YXkgZm9yIHBlZXItdG8tcGVlcg0KICAgbWVkaWEgdHJhZmZpYywg cmVseWluZyBleGNsdXNpdmVseSBpbiBhIG5ldHdvcmsgYWdub3N0aWMgd2F5IGlzDQogICBjbGVh cmx5IG5vdCBhbiBlZmZpY2llbnQgd2F5IG9mIGxhcmdlIHZvbHVtZSB0cmFmZmljIHJvdXRpbmcg ZnJvbSB0aGUNCiAgIElTUCdzIHBvaW50IG9mIHZpZXcuIEl0IG1heSByZXN1bHQgaW4gYSBzZWNv bmQgdGhvdWdodCBmb3IgdGhlIElTUCBvbg0KICAgd2hldGhlciBvciBub3QgaXQgc2hvdWxkIHBy b3ZpZGUgcHVibGljIFRVUk4gc2VydmVyIGZhY2lsaXRpZXMgdG8NCiAgIHRoaXJkIHBhcnR5IFdF QlJUQyBhcHBsaWNhdGlvbnMuDQoNCiAgIE9uIHRoZSBvdGhlciBoYW5kLCBmcm9tIHRoZSBwZXJz cGVjdGl2ZSBvZiBXRUJSVEMgYXBwbGljYXRpb25zLA0KICAgY29vcGVyYXRpb24gd2l0aCBJU1Ag ZGVwbG95ZWQgdHVybiBzZXJ2ZXIgY291bGQgYWxzbyBtZWFuIGFub3RoZXINCiAgIGNoYW5jZSBv ZiBmdXJ0aGVyIGV4cGxvcmluZyBuZXR3b3JrIGNhcGFiaWxpdHkgaW4gZGVsaXZlcmluZyBiZXR0 ZXINCiAgIHVzZXIgZXhwZXJpZW5jZS4NCg0KDQoyICBUZXJtaW5vbG9neQ0KDQogICBUaGUga2V5 IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5P VCIsDQogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5k ICJPUFRJT05BTCIgaW4gdGhpcw0KICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFz IGRlc2NyaWJlZCBpbiBSRkMgMjExOSBbUkZDMjExOV0uDQoNCjMgVXNlLWNhc2VzIGZvciBOZXR3 b3JrIGRlcGxveWVkIFRVUk4gc2VydmVycw0KDQogICBUaHJlZSBjYXNlcyBhcmUgZGlzY3Vzc2Vk IGluIGN1cnJlbnQgZHJhZnQuDQoNCjMuMSBUcmFmZmljIExvY2FsaXR5DQoNCiAgIEZyb20gYW4g SVNQJ3MgcG9pbnQgb2YgdmlldywgZm9yIHR3byBsb2NhbCBXRUJSVEMgdXNlcnMgY29tbXVuaWNh dGluZw0KICAgdmlhIGFuIHRoaXJkIHBhcnR5IFRVUk4gc2VydmVyIHVzdWFsbHkgcmVzdWx0IGlu IHN1Yi1vcHRpbWFsDQogICBvdXRjb21lLg0KDQogICBJZiB0aGUgU1AncyBUVVJOIHNlcnZlciBp cyBsb2NhdGVkIG91dHNpZGUgdGhlIElTUCdzIG5ldHdvcmssIHRoZQ0KICAgbWVkaWEgdHJhZmZp YyBpdCByZWxheXMgaGFzIHRvIGdvIHRocm91Z2ggdGhlIGludGVyLXdvcmtpbmcgcG9pbnQgdG8N CiAgIGFub3RoZXIgSVNQIHR3aWNlLCB3aGljaCBpcyB1c3VhbGx5IHRoZSBtb3N0IGNvbmdlc3Rl ZCBwb2ludHMgZm9yIHRoZQ0KICAgdXNlciBhbmQgbW9zdCBleHBlbnNpdmUgbGlua3MgZm9yIHRo ZSBsb2NhbCBJU1AuIA0KDQogICBJbiB0aGlzIGNhc2UsIHVzaW5nIGEgbG9jYWwgKG5ldHdvcmsg ZGVwbG95ZWQpIFRVUk4gc2VydmVyIHdvdWxkDQogICByZXN1bHQgaW4gYSB3aW4td2luIHNpdHVh dGlvbi4NCg0KDQogDQoNCg0KPERlbmcsIGV0IGFsLj4gICAgICAgICAgRXhwaXJlcyBBdWd1c3Qg MTQsIDIwMTQgICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAg ICAgICAgPElTUCBUVVJOIEZvciBXRUJSVEM+ICAgICAgICAgRmVicnVhcnkgMTQsIDIwMTQNCg0K DQozLjIgUmVzb3VyY2UgU2hhcmluZw0KDQogICBGb3IgbGFyZ2UgV0VCUlRDIFNQcywgaXQgbWF5 IGJlIHRlbXB0aW5nIHRvIGJ1aWxkIHVwIHRoZWlyIG93biByZWxheQ0KICAgb3ZlcmxheSBhbmQg Z2FpbiBzdWZmaWNpZW50IGVmZmljaWVuY3kgZm9yIHRhcmdldGVkIGFyZWFzLiANCg0KICAgSG93 ZXZlciwgc21hbGwgb3IgaW50ZWdyYXRlZCBXRUJSVEMgU1BzLCBtYXkgcHJlZmVyIHRvIG1ha2Ug dXNlIG9mDQogICBJU1AncyBsb2NhbGx5IGRlcGxveWVkIHJlbGF5IG5ldHdvcmsgdG8gcmVkdWNl IENBUEVYIGFuZCBPUEVYIGZvcg0KICAgZW1lcmdpbmcgbWFya2V0cy4NCg0KICAgT24gdGhlIG90 aGVyIGhhbmQsIGJ5IHByb3ZpZGluZyBwdWJsaWMgYWNjZXNzaWJsZSByZWxheSBuZXR3b3JrIGFu ZA0KICAgc2hhcmUgaXQgd2l0aCBtdWx0aXBsZSB0aGlyZCBwYXJ0eSBhcHBsaWNhdGlvbnMsIHRo ZQ0KICAgY29uc3RydWN0aW9uL21hbmFnZW1lbnQgY29zdCBmb3IgYW4gSVNQIGlzIGNvbnNpZGVy YWJseSBzbWFsbCBpbg0KICAgY29tcGFyaXNvbiB0byBlYWNoIFNQIGJ1aWxkaW5nIHVwIGEgcHJp dmF0ZSBvbmUuDQoNCjMuMyAgSVNQIFFvUyBTdXBwb3J0DQoNCiAgIEZvciBRb1Mgc2Vuc2l0aXZl IHRyYWZmaWMgbGlrZSBXRUJSQ1QgbWVkaWEsIGl0IHdvdWxkIGJyaW5nDQogICBzdWJzdGFudGlh bCBlbmhhbmNlbWVudCB0byB1c2VyIGV4cGVyaWVuY2UgaWYgcmVsZXZhbnQgUW9TDQogICByZXF1 aXJlbWVudCBiZSBob25vcmVkIGFuZCBwcm9wZXJseSBoYW5kbGVkIGJ5IHRoZSBuZXR3b3JrIGRl dmljZXMNCiAgIGFsb25nIHRoZSB3YXkuDQoNCiAgIEFsdGhvdWdoIHRoZXJlIGhhcyBiZWVuIHdv cmsgb24gRFNDUCBzZXR0aW5nIGZvciB2YXJpb3VzIFdFQlJUQyBtZWRpYQ0KICAgcGFja2V0LCB0 aGVyZSBpcyBubyBndWFyYW50ZWUgdGhhdCB0aGVzZSBlbmQyZW5kIHNldHRpbmcgYmUgaG9ub3Jl ZA0KICAgYnkgYW4gSVNQLCB1bmxlc3MgdGhleSBhcmUgb2ZmaWNpYWxseSByZWNvZ25pemVkIGJ5 IHRoZSBuZXR3b3JrIGZyb20NCiAgIGEgUW9TLWVuYWJsZWQgYm91bmRhcnkgZGV2aWNlIGFuZC9v ciBiZSBleHBsaWNpdGx5IHByb21pc2VkIHRvIGJlDQogICBob25vcmVkIGJ5IGFncmVlbWVudC4N Cg0KICAgQnkgdXRpbGl6aW5nIElTUCBkZXBsb3llZCBUVVJOIHNlcnZlciwgdGhlcmUgaXMgYW4g ZXhwbGljaXQgd2F5IG9mDQogICBpbmRpY2F0aW5nIHRvIHRoZSBuZXR3b3JrIHRoZSB0cmFmZmlj IGlzIHJlYWwtdGltZSBpbnRlcmFjdGl2ZSBhbmQNCiAgIHNob3VsZCBiZSBRb1MgZW5hYmxlZC4N Cg0KNCAgU3VtbWFyeQ0KDQogICBBY2NvcmRpbmcgdG8gdGhlIGFib3ZlIGRpc2N1c3Npb24sIGl0 IGlzIGJlbGlldmVkIHRoYXQgbWFraW5nDQogICBleHBsaWNpdCB1c2FnZSBvZiBJU1AgZGVwbG95 ZWQgcmVsYXkgbmV0d29yayB3b3VsZCBiZSBhIHBsdXMgdG8gYm90aA0KICAgdGhpcmQgcGFydHkg V0VCUlRDIFNQcyBhcyB3ZWxsIGFzIGxvY2FsIElTUHMuDQoNCiAgIFRvIGVuYWJsZSBmbGV4aWJs ZSBhcHBsaWNhdGlvbiwgdGhlIElTUCBuZWVkcyB0byBiZSBnaXZlbiBhbg0KICAgb3Bwb3J0dW5p dHkgdG8gYWR2ZXJ0aXNlL2Fubm91bmNlIHRvIHRoZSBhcHBsaWNhdGlvbi9XZWJSVEMgYnJvd3Nl cg0KICAgdGhlIGF2YWlsYWJpbGl0eSBvZiBhbiBvcHRpbWFsIFRVUk4gc2VydmVyIHRvIHVzZS4g VGhpcyBzaG91bGQgYWxzbw0KICAgYmUgdGhlIFRVUk4gc2VydmVyIHRvIHVzZSwgdW5sZXNzIHRo ZXJlIGFyZSBvdGhlciBjb25jZXJucyB0aGFuIGJlc3QNCiAgIHF1YWxpdHkvdXNlciBleHBlcmll bmNlIGZvciB0aGUgYXBwbGljYXRpb24gdG8gYmUgY29uc2lkZXJlZC4NCg0KICAgVGhlIGF1dG8t ZGlzY292ZXJ5IG1lY2hhbmlzbSBvZiBUVVJOIHNlcnZlcnMgZGlzY3Vzc2VkLCBpcyBhIHdheSB0 bw0KICAgcmVhbGl6ZSBhbmQgbWVldCB0aGUgbmVlZHMgZm9yIHRoZSBJU1AgdG8gYW5ub3VuY2Ug YW5kIGVuZm9yY2UgdGhlDQogICB1c2FnZSBvZiBhbiBvcHRpbWFsIFRVUk4gc2VydmVyIGZvciBx dWFsaXR5IGNvbnNpZGVyYXRpb25zLCBhbmQNCiAgIHNob3VsZCBub3QgaW4gYW55d2F5IGNvbmZs aWN0IHdpdGggdGhlIG5lZWQgZm9yIE5BVC9maXJld2FsbA0KICAgdHJhdmVyc2FsLg0KIA0KDQoN CjxEZW5nLCBldCBhbC4+ICAgICAgICAgIEV4cGlyZXMgQXVndXN0IDE0LCAyMDE0ICAgICAgICAg ICAgICAgICBbUGFnZSA0XQ0KDA0KSU5URVJORVQgRFJBRlQgICAgICAgICAgIDxJU1AgVFVSTiBG b3IgV0VCUlRDPiAgICAgICAgIEZlYnJ1YXJ5IDE0LCAyMDE0DQoNCg0KNSAgU2VjdXJpdHkgQ29u c2lkZXJhdGlvbnMNCg0KICAgVEJBLg0KDQo2ICBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIFRoZSBh dXRob3JzIHdpc2ggdG8gdGhhbmsgS2FybCBTdGFobCBmb3IgcHJvdmlkaW5nIGNvbW1lbnRzLA0K ICAgZmVlZGJhY2ssIHRleHQgYW5kIGltcHJvdmVtZW50IHByb3Bvc2FscyBvbiB0aGUgZG9jdW1l bnQuDQoNCg0KNyAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogICBUaGVyZSBpcyBubyBJQU5BIGFj dGlvbiBpbiB0aGlzIGRvY3VtZW50Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiANCg0KDQo8RGVuZywgZXQgYWwu PiAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCAxNCwgMjAxNCAgICAgICAgICAgICAgICAgW1BhZ2Ug NV0NCgwNCklOVEVSTkVUIERSQUZUICAgICAgICAgICA8SVNQIFRVUk4gRm9yIFdFQlJUQz4gICAg ICAgICBGZWJydWFyeSAxNCwgMjAxNA0KDQoNCjYgIFJlZmVyZW5jZXMNCg0KNi4xICBOb3JtYXRp dmUgUmVmZXJlbmNlcw0KDQogICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZv ciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQ0KICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZl bHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3Lg0KDQogICBbUkZDNTI0NV0gIFJvc2Vu YmVyZywgSi4sICJJbnRlcmFjdGl2ZSBDb25uZWN0aXZpdHkgRXN0YWJsaXNobWVudA0KICAgICAg ICAgICAgICAoSUNFKTogQSBQcm90b2NvbCBmb3IgTmV0d29yayBBZGRyZXNzIFRyYW5zbGF0b3Ig KE5BVCkNCiAgICAgICAgICAgICAgVHJhdmVyc2FsIGZvciBPZmZlci9BbnN3ZXIgUHJvdG9jb2xz IiwgUkZDIDUyNDUsIEFwcmlsDQogICAgICAgICAgICAgIDIwMTAuDQoNCiAgIFtSRkM1Mzg5XSAg Um9zZW5iZXJnLCBKLiwgTWFoeSwgUi4sIE1hdHRoZXdzLCBQLiwgYW5kIEQuIFdpbmcsDQogICAg ICAgICAgICAgICJTZXNzaW9uIFRyYXZlcnNhbCBVdGlsaXRpZXMgZm9yIE5BVCAoU1RVTikiLCBS RkMgNTM4OSwNCiAgICAgICAgICAgICAgT2N0b2JlciAyMDA4Lg0KDQogICBbUkZDNTc2Nl0gIE1h aHksIFIuLCBNYXR0aGV3cywgUC4sIGFuZCBKLiBSb3NlbmJlcmcsICJUcmF2ZXJzYWwgVXNpbmcN CiAgICAgICAgICAgICAgUmVsYXlzIGFyb3VuZCBOQVQgKFRVUk4pOiBSZWxheSBFeHRlbnNpb25z IHRvIFNlc3Npb24NCiAgICAgICAgICAgICAgVHJhdmVyc2FsIFV0aWxpdGllcyBmb3IgTkFUIChT VFVOKSIsIFJGQyA1NzY2LCBBcHJpbCAyMDEwLg0KDQoNCiAgIFtJLUQuaWV0Zi1ydGN3ZWItb3Zl cnZpZXddIEFsdmVzdHJhbmQsIEguLCAiT3ZlcnZpZXc6IFJlYWwgVGltZQ0KICAgICAgICAgICAg ICBQcm90b2NvbHMgZm9yIEJyb3dlci1iYXNlZCBBcHBsaWNhdGlvbnMiLCBJLUQuaWV0Zi1ydGN3 ZWItDQogICAgICAgICAgICAgIG92ZXJ2aWV3IChXb3JrIGluIFByb2dyZXNzKSwgc2VwdGVtYmVy IDIwMTMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQog DQoNCg0KPERlbmcsIGV0IGFsLj4gICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMTQsIDIwMTQgICAg ICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJTlRFUk5FVCBEUkFGVCAgICAgICAgICAgPElTUCBU VVJOIEZvciBXRUJSVEM+ICAgICAgICAgRmVicnVhcnkgMTQsIDIwMTQNCg0KDQpBdXRob3JzJyBB ZGRyZXNzZXMNCg0KDQogICBMaW5nbGkgRGVuZw0KICAgQ2hpbmEgTW9iaWxlDQoNCiAgIEVtYWls OiBFbWFpbDogZGVuZ2xpbmdsaUBjaGluYW1vYmlsZS5jb20NCg0KDQoNCiAgIFBlbmcgRmFuDQog ICBDaGluYSBNb2JpbGUNCg0KICAgRW1haWw6IEVtYWlsOiBmYW5wZW5nQGNoaW5hbW9iaWxlLmNv bQ0KDQoNCg0KICAgSHVpIERlbmcNCiAgIENoaW5hIE1vYmlsZQ0KDQogICBFbWFpbDogRW1haWw6 IGRlbmdodWlAY2hpbmFtb2JpbGUuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo8RGVuZywgZXQgYWwuPiAgICAgICAgICBFeHBp cmVzIEF1Z3VzdCAxNCwgMjAxNCAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCg== --001a1136b3743b83f404f2a494f8-- From nobody Mon Feb 17 21:12:17 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51B91A05B1 for ; Mon, 17 Feb 2014 21:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 iDOjfNzE2ViD for ; Mon, 17 Feb 2014 21:12:12 -0800 (PST) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 810FF1A0346 for ; Mon, 17 Feb 2014 21:12:12 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id md12so16250527pbc.2 for ; Mon, 17 Feb 2014 21:12:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=C9W97/Z5pRrf+99KSCqf9V7oenE85f5PI73o1GTV7uE=; b=MJVKX9GvQ9gVQUjP5+H9kRLoddEunonYGrBRIWSahXsus4ow+GpEGj698C1Reim9fB uzSeFMxftIQd4pBiYApPegUrJOEYoYakokCBf3826SctgMJowuoecToZQ3RraoK1/tHk AhIrZQujRvqdUeqj5QWNivcAFrL7KmRlP4V8EqfUMA5dYYbGq3xlnQ7WUFS5r8m4oH9c 2yG9m7MH5XEhYkk9hY6HZItaTJFGi5mVpf0w8XUlM8KveLXgkJDljDu+6W5wcuE8uJb4 jjqB4cI2Rr8uBB66CnLJxMwyW0Lek9qj9PG7f4GAf8M7CugmxaURwFbITtblhyyJudds bL2A== MIME-Version: 1.0 X-Received: by 10.68.212.161 with SMTP id nl1mr12704632pbc.142.1392700329706; Mon, 17 Feb 2014 21:12:09 -0800 (PST) Received: by 10.68.147.131 with HTTP; Mon, 17 Feb 2014 21:12:09 -0800 (PST) In-Reply-To: References: <913383AAA69FF945B8F946018B75898A242AF33F@xmb-rcd-x10.cisco.com> Date: Mon, 17 Feb 2014 21:12:09 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=e89a8ff1c89c6e4c0f04f2a7502b Archived-At: http://mailarchive.ietf.org/arch/msg/tram/OMYxQ6xOaG8C-D1xrsGFvUbauJg Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 05:12:15 -0000 --e89a8ff1c89c6e4c0f04f2a7502b Content-Type: text/plain; charset=ISO-8859-1 Hi Tiru I went thru the OAuth interoperability links which you suggested (see below): On Mon, Feb 17, 2014 at 10:29 AM, Oleg Moskalenko wrote: > [TR] Drafts in OAuth WG like > https://tools.ietf.org/html/draft-richer-oauth-introspection-04 discuss > the communication mechanism b/w Resource Server and Authorization server. > You may also want to look into > http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html which > discusses such communication mechanism already implemented but for a > different purpose. I guess it all worked because Resource server and > Authorization server are developed by the same company but with this use > case we may have to discuss if standardization is required for the > communication mechanism. > > The links provide meaningful suggestions - but the drafts did not result in definite standards. The current situation in OAuth is that it is a pretty fragmented and balkanized field... and it is not moving toward a definite interoperability standard. As of now, OAuth is actually not a standard - it is more a framework. So we have a logical conflict - the TURN specs are definitely a standard, not a framework, but we introduce a dependency on something that is just a framework. That would be inconsistent. Each OAuth server provider defines its own proprietary API for the Resource Server. That does not sounds very attractive. In practice, every TURN server provider will have to provide its own OAuth server, too. That will lead to further fragmentation. Overall, OAuth is a heated minefield full of emotions and from the outside, it seems to be going nowhere in terms of interoperability. The lead developer of OAuth withdrew himself: http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ As a TURN server developer, I'd be very hesitant to tie, closely, the implementation to OAuth. I'd rather suggest to look at other alternatives, giving the current state of OAuth - or wait till the things will be clarified and OAuth will get more interoperability. Of course we can develop our own OAuth server but that would be a rather unfortunate outcome of the standardization process. I am not saying that from the technical point of view this draft specs is a bad idea. The TURN field is ready for something like that; but I see that OAuth is not ready - and I have concerns on being dependent on OAuth. Tiru, can you address my concerns ? Thanks, Oleg --e89a8ff1c89c6e4c0f04f2a7502b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tiru

I went thru the OAuth interopera= bility links which you suggested (see below):


On Mon, Feb 17, 2014 at 10:29 AM, Oleg = Moskalenko <mom040267@gmail.com> wrote:
[TR] Dra= fts in OAuth WG like https://tools.ietf.org/html/draft-r= icher-oauth-introspection-04 discuss the communication mechanism b/w Re= source Server and Authorization server. =A0You may also want to look into <= a href=3D"http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html"= target=3D"_blank">http://www.ietf.org/mail-archive/web/oauth/current/msg08= 607.html which discusses such communication mechanism already implement= ed but for a different purpose. I guess it all worked because Resource serv= er and Authorization server are developed by the same company but with this= use case we may have to discuss if standardization is required for the com= munication mechanism.
=

The links provide meaningful suggestions - but the drafts = did not result in definite standards. The current situation in OAuth is tha= t it is a pretty fragmented and balkanized field... and it is not moving to= ward a definite interoperability standard.

As of now, OAuth is actually not a sta= ndard - it is more a framework. So we have a logical conflict - the TURN sp= ecs are definitely a standard, not a framework, but we introduce a dependen= cy on something that is just a framework. That would be inconsistent.

Each = OAuth server provider defines its own proprietary API for the Resource Serv= er. That does not sounds very attractive. In practice, every TURN server pr= ovider will have to provide its own OAuth server, too. That will lead to fu= rther fragmentation.

Overall, OAuth is a heated minefield f= ull of emotions and from the outside, it seems to be going nowhere in terms= of interoperability. The lead developer of OAuth withdrew himself:

h= ttp://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/
<= div class=3D"gmail_extra">
As a TURN se= rver developer, I'd be very hesitant to tie, closely, the implementatio= n to OAuth. I'd rather suggest to look at other alternatives, giving th= e current state of OAuth - or wait till the things will be clarified and OA= uth will get more interoperability.

Of course we can develop our own OAuth= server but that would be a rather unfortunate outcome of the standardizati= on process.

I am not saying that from the technical point of view this draft specs is a= bad idea. The TURN field is ready for something like that; but I see that = OAuth is not ready - and I have concerns on being dependent on OAuth.

Tiru, can you address my concerns ?

Tha= nks,
Oleg




--e89a8ff1c89c6e4c0f04f2a7502b-- From nobody Mon Feb 17 21:34:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDFC1A042E for ; Mon, 17 Feb 2014 21:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ZGrvhvvYx2t6 for ; Mon, 17 Feb 2014 21:34:25 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 590D51A02EE for ; Mon, 17 Feb 2014 21:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28007; q=dns/txt; s=iport; t=1392701661; x=1393911261; h=from:to:cc:subject:date:message-id:mime-version; bh=mpw0zafMKWkJFdrwVTumheVtZNUFZ2xV1zAk34ArOJY=; b=EVwQ8LqvGBrxORGo3JT2fn+1YxuYXYY5dT2/9CJaVXcN4154efNqadDG jczHVKuwX5GXLY6X14df+rFEJ9HGUoPyAzets0lwimUtqsPfe3w0vSmjG Vn8Qv9MEaCx/Ny1PgBMpAOCJUE089TYtBJG1NHkPdDvSU676GI9JiBpxD k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwGAKfvAlOtJV2Y/2dsb2JhbABZgkJEOFe2d4hZgRMWdIIlAQEBBC1KAhIBCA4DBAEBCxYHKBEUCAEJAQQOBQgBC4ddAxENwmoNiA8XjGeBQwYBAR4tBAYHgx6BFASWQIMeiyyFRYFvgT6BaAEIFwIg X-IronPort-AV: E=Sophos; i="4.97,500,1389744000"; d="scan'208,217"; a="21178734" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP; 18 Feb 2014 05:34:20 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1I5YK1h006296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 05:34:20 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 23:34:19 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt Thread-Index: Ac8sau5mQl6VH9TvQn+mrFuN/xrk0A== Date: Tue, 18 Feb 2014 05:34:18 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242C01CB@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.68.192] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242C01CBxmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/BmcfZ6cmEKip1uNT2UlseCFwIgc Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 05:34:31 -0000 --_000_913383AAA69FF945B8F946018B75898A242C01CBxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Oleg, Please see inline [TR1] From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Monday, February 17, 2014 11:59 PM To: Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-= third-party-authz-00.txt Hi Tiru please see below as [Oleg]: On Mon, Feb 17, 2014 at 3:10 AM, Tirumaleswar Reddy (tireddy) > wrote: Hi Oleg, Thanks for the review. Please see inline [TR] From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Sunday, February 16, 2014 10:31 AM To: Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-= third-party-authz-00.txt Hi Tiru I have some comments: 1) Section 4. Obtaining a Token Using OAuth, figure 4 I believe that the sequence of messages is incorrect. The TURN server most = probably will contact the Authorization server AFTER it gets the Allocate r= equest. But on the figure 4, it looks like it somehow can predict the incom= ing request. The correct sequence must be, in the general case: Access Token Request (1) from client to Auth server Access Token + Session Key (2) from Auth server to client Allocate request from client to TURN server (3) Get Token from TURN Server to Auth server (4) Token metadata from Auth Server to TURN server (5) Allocate response from TURN server to the client (6) [TR] Good catch, fixed it. It got messed when we were changing from self-co= ntained to handle token. The sequence shown on the figure 4 is possible only is the Auth Server and = TURN server are somehow closely integrated and that is unnecessary. [TR] Yes, the AS and TURN server have to be integrated. There may be ways t= o standardize this, but this is not in the scope of this doc right away. [Oleg]: I am afraid that if we require that AS and TURN to be provided by t= he same company, it may affect the adoption of this approach. [TR1] Agreed, it may be true in few cases that the same company provides AS= and TURN. 2) The document is saying that the client when communicating to the Auth Se= rver uses HTTP requests with JSON (REST API ?). May be it would be helpful = if the communication protocol between TURN server and Auth server would be = mentioned, too. [TR] Drafts in OAuth WG like https://tools.ietf.org/html/draft-richer-oauth= -introspection-04 discuss the communication mechanism b/w Resource Server a= nd Authorization server. You may also want to look into http://www.ietf.or= g/mail-archive/web/oauth/current/msg08607.html which discusses such communi= cation mechanism already implemented but for a different purpose. I guess i= t all worked because Resource server and Authorization server are developed= by the same company but with this use case we may have to discuss if stand= ardization is required for the communication mechanism. [Oleg]: As I said, if the AS and TURN in practice will have to be provided = by the same company, then that may be a problem - it will affect the standa= rd adoption by the WebRTC community. I'll have to explore the current situa= tion with the open-source OAuth servers - whether they provide a viable "in= trospection" protocol. I hope some protocol recommendations can be provided= for third-party AS communications. [TR1] Agreed. 3) Section 7.2: OAuth does not impose any limitation on the length of the access token b= ut since STUN messages cannot exceed 548 bytes (Section 7.1 of [RFC5389]), access token length needs to be restricted to fit within the maximum STUN message size. I am not sure that the STUN (Binding ?) max message size is relevant here a= nd worth mentioning at all - because this doc is about TURN, and the TURN m= essages are often much larger than 548 bytes (especially when carrying the = video traffic). So I see no relevance of the 548 limit to the new authentic= ation standard. And that limitation of 548 bytes is applicable only to the = cases when we suspect that the path MTU is really really low and that is an= extremely rare case. [TR] Good point. But RFC 5766 recommends to restrict the size (Section 2.7 = Avoiding Fragmentation) As a guideline, sending a maximum of 500 bytes of application data in a single TURN message (by the client on the client-to-server leg) or a UDP datagram (by the peer on the peer-to-server leg) will generally avoid IP fragmentation. [Oleg]: We recently had a discussion about that in WebRTC forum, with Justi= n. He is saying that the WebRTC client tools (Chrome) assume the minimum pr= actical MTU as 1280 and that limit is used for media traffic. And he is rig= ht that this MTU is a real modern practical limit. [TR1] And depending on the initial number of allocations (let's say X) it w= ould consume that much additional bandwidth (X*Length of the token) 4) Are we sure that we want to limit the OAuth applicability only to the lo= ng-term credentials mechanism ? I see no technical or philosophical reasons= why not to use it for short-term credentials mechanism, too. It would be a= more "symmetric" approach. [TR] what is the use case for short-term credential mechanism with TURN ? [Oleg]: Currently WebRTC uses only the long-term credentials mechanism but = still there is a TURN standard for the short-term mechanism. While I cannot= provide any concrete example, I suppose there are some. And I believe that= OAuth is orthogonal to the TURN auth mechanism used - they can be combined= either way. So I see that coupling OAuth with the long-term mechanism is r= ather artificial. [TR1] May be I am missing something Are you referring to short-term mechanism defined in STUN ? (I don't see an= y discussion in http://tools.ietf.org/html/rfc5766 about this short-term me= chanism) The token given to the client has a lifetime and after the call is terminat= ed the WebRTC server can revoke the token. This way the resources on the TU= RN server are no longer used by the client for some other purpose when not = using WebRTC server. This way it's short-term usage of the token only. 5) I'd put more definite wording how TURN server handles the token lifetime= . What happens in the middle of the TURN session, is the auth token expires= while the session is still active ? There may be two possible cases: - the token lifetime is applicable only to the session initiation proced= ure. When the TURN session has been already established, it can go indefini= tely while the client is refreshing the session properly. - in second case when the token expires, the server rejects new requests= from the client (in the same TURN session) until the client sends the new = token data in re-authentication exchange. I'd suggest the first case as an eisier case for the implementation. [TR] The client MUST obtain a new token after the previously used one expir= es. As you point out an already established TURN session can continue, the = new token is applicable for new requests. [Oleg]: Tiru, I'd still like to hear a more definite language: what about "= new requests" within the existing session ? They are allowed to use the old= token - right ? When you are saying "new requests" you mean "new session a= llocation requests", right ? [TR1] These are my initial thoughts (we probably need more discussion on this top= ic): [a] New token is definitely applicable for "new session allocation requests= ". If the client uses the token after its lifetime then the TURN server MU= ST return error that the token is invalid which is in line with the steps d= efined in http://tools.ietf.org/html/rfc6749#section-1.5 [b] For "new request" within the existing session why not use the new token= ? This way the client has to maintain only one token. We can clarify in t= he draft that Refresh request can carry the new access token. [c The actual lifetime provided by the server in the Allocate/refresh respo= nse should be less than or equal to the lifetime of the token. Cheers, -Tiru. Regards, Oleg --_000_913383AAA69FF945B8F946018B75898A242C01CBxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Oleg,

 <= /p>

Please see inline [TR1]

 <= /p>

From: Oleg Mos= kalenko [mailto:m= om040267@gmail.com]
Sent: Monday, February 17, 2014 11:59 PM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.or= g
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tra= m-turn-third-party-authz-00.txt

 

Hi Tiru

please see below as [= Oleg]:

 

On Mon, Feb 17, 2014 at 3:10 AM, Tirumaleswar Reddy = (tireddy) <tiredd= y@cisco.com> wrote:

Hi Oleg,

Thanks for the review. Please see inline [TR]

From: Oleg Moskalenko [mailto:mom040= 267@gmail.com]
Sent: Sunday, February 16, 2014 10:31 AM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.org
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-= third-party-authz-00.txt


Hi Tiru
I have some comments:
1) Section 4. Obtaining a Token Using OAuth, figure 4

I believe that the sequence of messages is incorrect. The TURN server most = probably will contact the Authorization server AFTER it gets the Allocate r= equest. But on the figure 4, it looks like it somehow can predict the incom= ing request. The correct sequence must be, in the general case:
   Access Token Request (1) from client to Auth server
   Access Token + Session Key (2) from Auth server to client<= br>    Allocate request from client to TURN server (3)
   Get Token from TURN Server to Auth server (4)
   Token metadata from Auth Server to TURN server (5)
   Allocate response from TURN server to the client (6)

[TR] Good catch, fixed it. It got messed when we wer= e changing from self-contained to handle token.


The sequence shown on the figure 4 is possible only is the Auth Server and = TURN server are somehow closely integrated and that is unnecessary.

[TR] Yes, the AS and TURN server have to be integrat= ed. There may be ways to standardize this, but this is not in the scope of = this doc right away.

 

[Oleg]: I am afraid that if we require that AS and T= URN to be provided by the same company, it may affect the adoption of this = approach.

 

[TR1] Agreed, it may be t= rue in few cases that the same company provides AS and TURN.

 

 <= /p>


2) The document is saying that the client when communicating to the Auth Se= rver uses HTTP requests with JSON (REST API ?). May be it would be helpful = if the communication protocol between TURN server and Auth server would be = mentioned, too.

[TR] Drafts in OAuth WG like https://tools.ietf.org/html/draft-richer-oauth-introspection-04 discuss= the communication mechanism b/w Resource Server and Authorization server. =  You may also want to look into http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html which = discusses such communication mechanism already implemented but for a differ= ent purpose. I guess it all worked because Resource server and Authorizatio= n server are developed by the same company but with this use case we may have to discuss if standardization i= s required for the communication mechanism.

 

[Oleg]: As I said, if the AS and TURN in practice wi= ll have to be provided by the same company, then that may be a problem - it= will affect the standard adoption by the WebRTC community. I'll have to ex= plore the current situation with the open-source OAuth servers - whether they provide a viable "introspect= ion" protocol. I hope some protocol recommendations can be provided fo= r third-party AS communications. 

 <= /p>

[TR1] Agreed.<= /span>

 


3) Section 7.2:

   OAuth does not impose any limitation on the length of the acce= ss token but since
   STUN messages cannot exceed 548 bytes (Section 7.1 of [RFC5389= ]),
   access token length needs to be restricted to fit within the m= aximum
   STUN message size.

I am not sure that the STUN (Binding ?) max message size is relevant here a= nd worth mentioning at all - because this doc is about TURN, and the TURN m= essages are often much larger than 548 bytes (especially when carrying the = video traffic). So I see no relevance of the 548 limit to the new authentication standard. And that limitation o= f 548 bytes is applicable only to the cases when we suspect that the path M= TU is really really low and that is an extremely rare case.

[TR] Good point. But RFC 5766 recommends to restrict= the size (Section 2.7 Avoiding Fragmentation)

<snip>

   As a guideline, sending a maximum of 500 bytes of application = data in
   a single TURN message (by the client on the client-to-server l= eg) or
   a UDP datagram (by the peer on the peer-to-server leg) will ge= nerally
   avoid IP fragmentation.

</snip>

 

[Oleg]: We recently had a discussion about that in W= ebRTC forum, with Justin. He is saying that the WebRTC client tools (Chrome= ) assume the minimum practical MTU as 1280 and that limit is used for media= traffic. And he is right that this MTU is a real modern practical limit.

 

[TR1] And depending on th= e initial number of allocations (let’s say X) it would consume that m= uch additional bandwidth (X*Length of the token)

 



4) Are we sure that we want to limit the OAuth applicability only to the lo= ng-term credentials mechanism ? I see no technical or philosophical reasons= why not to use it for short-term credentials mechanism, too. It would be a= more "symmetric" approach.

[TR] what is the use case for short-term credential = mechanism with TURN ?

 

[Oleg]: Currently WebRTC uses only the long-term cre= dentials mechanism but still there is a TURN standard for the short-term me= chanism. While I cannot provide any concrete example, I suppose there are s= ome. And I believe that OAuth is orthogonal to the TURN auth mechanism used - they can be combined either way. So I se= e that coupling OAuth with the long-term mechanism is rather artificial.

 <= /p>

[TR1] May be I am missing= something

Are you referring to shor= t-term mechanism defined in STUN ? (I don’t see any discussion in http://t= ools.ietf.org/html/rfc5766 about this= short-term mechanism)

The token given to the cl= ient has a lifetime and after the call is terminated the WebRTC server can = revoke the token. This way the resources on the TURN server are no longer used by the client for some other purpose when not using Web= RTC server. 

This way it’s short= -term usage of the token only.  


5) I'd put more definite wording how TURN server handles the token lifetime= . What happens in the middle of the TURN session, is the auth token expires= while the session is still active ? There may be two possible cases:
   - the token lifetime is applicable only to the session initiat= ion procedure. When the TURN session has been already established, it can g= o indefinitely while the client is refreshing the session properly.
   - in second case when the token expires, the server rejects ne= w requests from the client (in the same TURN session) until the client send= s the new token data in re-authentication exchange.

I'd suggest the first case as an eisier case for the implementation.

[TR] The client MUST obtain a new token after the pr= eviously used one expires. As you point out an already established TURN ses= sion can continue, the new token is applicable for new requests.  

 

[Oleg]: Tiru, I'd still like to hear a more definite= language: what about "new requests" within the existing session = ? They are allowed to use the old token - right ? When you are saying "= ;new requests" you mean "new session allocation requests", right ?

 <= /p>

[TR1]

These are my initial thou= ghts (we probably need more discussion on this topic):

[a] New token is definite= ly applicable for “new session allocation requests”.  If t= he client uses the token after its lifetime then the TURN server MUST retur= n error that the token is invalid which is in line with the steps defined in= htt= p://tools.ietf.org/html/rfc6749#section-1.5

[b] For “new reques= t” within the existing session why not use the new token ? This way t= he client has to maintain only one token.  We can clarify in the draft that Refresh request can carry the new access token. 

[c The actual lifetime pr= ovided by the server in the Allocate/refresh response should be less than o= r equal to the lifetime of the token.

Cheers,   =  

-Tiru.<= /p>

 <= /p>

Regards,
Oleg

 

--_000_913383AAA69FF945B8F946018B75898A242C01CBxmbrcdx10ciscoc_-- From nobody Mon Feb 17 22:10:07 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02851A0358 for ; Mon, 17 Feb 2014 22:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 chVjJ0I-P2vc for ; Mon, 17 Feb 2014 22:10:04 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 84C601A05EB for ; Mon, 17 Feb 2014 22:09:50 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kx10so16163940pab.21 for ; Mon, 17 Feb 2014 22:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=36zZ0ONyKFmGxkc8Ecs7yQTErqq7g1WCpWsSR9ClBp0=; b=L8tOyE5aA56kbWjBjQpkl9f4SMod+lqWpv2pMvMHXWTA+/mr3D70jxIJ4RLAxsvHU4 yupPQGlzCpb8Yu+1wlBWpEayDvY89DvbD4wGrA5kuihZ+lq/911Z/GEvd+poaC2oczRl 4xNeb5GJP40v9Ac1qv/EbTKZYtIKEtD8gk/NJE4+Dd7R2hJbUUYacwSqPD4vvKUBuUjK UoOSFL2V00DYGGeBaUC+XJSaWfauMxCCVcmhDniKP6rUI2w35qPCcuFHjPAkVSE79UMt /hSQGRY3vC80GqtEnypNY8n22dn2uiZxtXYeghN2WUZFAH74eDRTNgxJddX3ED8JeI2j pefw== MIME-Version: 1.0 X-Received: by 10.66.144.227 with SMTP id sp3mr31276867pab.100.1392703787797; Mon, 17 Feb 2014 22:09:47 -0800 (PST) Received: by 10.68.147.131 with HTTP; Mon, 17 Feb 2014 22:09:47 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A242C01CB@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242C01CB@xmb-rcd-x10.cisco.com> Date: Mon, 17 Feb 2014 22:09:47 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7b6d82708c913504f2a81ebd Archived-At: http://mailarchive.ietf.org/arch/msg/tram/OpF3WjXqKwQibeUZNGc7Hrqa5Cg Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 06:10:06 -0000 --047d7b6d82708c913504f2a81ebd Content-Type: text/plain; charset=ISO-8859-1 Hi Tiru regarding the authentication mechanisms: yes, I am talking about section 10.1 of STUN RFC 5389: http://tools.ietf.org/search/rfc5389#section-10.1 STUN defines both short-term mechanism and long-term mechanism. They differ in the ways how the INTEGRITY field is calculated, and in some other minor details. The names are somewhat unfortunate and confusing; the "short-term mechanism" is NOT about short-lived ephemeral identities. The proposed token-based authorization is equally applicable to both short-term and long-term mechanisms - taking into account different INTEGRITY calculation algorithms. >From the pure technical point of view, I think that the token authorization is equally applicable to the short-term mechanism than to the long-term mechanism. Of course the short-term mechanism is not very important in this context because this proposed standard is mostly about WebRTC. But it would be "cleaner" if the token authorization will be applied to the whole STUN/TURN specs, not to a particular case of WebRTC. And may be some day WebRTC will decide to adopt the short-term mechanism... Regards, Oleg --047d7b6d82708c913504f2a81ebd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tiru

regarding the authenticatio= n mechanisms: yes, I am talking about section 10.1 of STUN RFC 5389:
http://tools= .ietf.org/search/rfc5389#section-10.1

STUN defines both short-term mechanism and long-term mechanism. They di= ffer in the ways how the INTEGRITY field is calculated, and in some other m= inor details. The names are somewhat unfortunate and confusing; the "s= hort-term mechanism" is NOT about short-lived ephemeral identities. Th= e proposed token-based authorization is equally applicable to both short-te= rm and long-term mechanisms - taking into account different INTEGRITY calcu= lation algorithms.

From the pure technical point of view, I think that the toke= n authorization is equally applicable to the short-term mechanism than to t= he long-term mechanism.

Of course the short-term mechanis= m is not very important in this context because this proposed standard is m= ostly about WebRTC. But it would be "cleaner" if the token author= ization will be applied to the whole STUN/TURN specs, not to a particular c= ase of WebRTC. And may be some day WebRTC will decide to adopt the short-te= rm mechanism...

Regards,
Oleg
--047d7b6d82708c913504f2a81ebd-- From nobody Mon Feb 17 22:24:08 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3A41A05E8 for ; Mon, 17 Feb 2014 22:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 v4rJm8posZ3X for ; Mon, 17 Feb 2014 22:24:04 -0800 (PST) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACE71A0363 for ; Mon, 17 Feb 2014 22:24:04 -0800 (PST) Received: by mail-pd0-f181.google.com with SMTP id y10so15651893pdj.26 for ; Mon, 17 Feb 2014 22:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZXbDLsJYaTnRKiOY5XqIbWSYjuh4wz9hrqJXS/i8AVs=; b=Jki7XjUaqh6PQkt+oZCx9keOLqNolNzhK1ZbLwwII0eFDDmAwk7a8MLsQVUG5e5LE6 SXBLbCS+R5QwEAK3P2OD4UGd+LsXgqQbEC1pgBurFlvC10UNLNDJt0wrYECYsqMPMZKB ymjeLf84Hyh7iKoSqgIys5Het1ja8opF8q/7erjXgbifhiZ54z+vnOrtSaMnFfGsFImT E0GrCkfdZFMQSmNmiP2u0QEHDIntaOLVeEugtAZH9/bsnWnBBVMWdkx1sqGdN+wuOg8d MEEeqGqeqfUqbFdJa3Bnggxk5kdq4FR9uty39qIEwnNOMO9BR0VqbXdeOB9dLpSWKH8a Ygwg== MIME-Version: 1.0 X-Received: by 10.66.160.2 with SMTP id xg2mr30739899pab.23.1392704641755; Mon, 17 Feb 2014 22:24:01 -0800 (PST) Received: by 10.68.147.131 with HTTP; Mon, 17 Feb 2014 22:24:01 -0800 (PST) In-Reply-To: <913383AAA69FF945B8F946018B75898A242C01CB@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A242C01CB@xmb-rcd-x10.cisco.com> Date: Mon, 17 Feb 2014 22:24:01 -0800 Message-ID: From: Oleg Moskalenko To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=047d7bacb47c72ef0904f2a851ea Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Nmr60jqLrM_YL2Jqy4aFgRMYD-I Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 06:24:07 -0000 --047d7bacb47c72ef0904f2a851ea Content-Type: text/plain; charset=ISO-8859-1 Hi Tiru regarding the refresh requests, please below: On Mon, Feb 17, 2014 at 9:34 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > [Oleg]: Tiru, I'd still like to hear a more definite language: what > about "new requests" within the existing session ? They are allowed to use > the old token - right ? When you are saying "new requests" you mean "new > session allocation requests", right ? > > > > [TR1] > > These are my initial thoughts (we probably need more discussion on this > topic): > > [a] New token is definitely applicable for "new session allocation > requests". If the client uses the token after its lifetime then the TURN > server MUST return error that the token is invalid which is in line with > the steps defined in http://tools.ietf.org/html/rfc6749#section-1.5 > > [b] For "new request" within the existing session why not use the new > token ? This way the client has to maintain only one token. We can clarify > in the draft that Refresh request can carry the new access token. > > [c The actual lifetime provided by the server in the Allocate/refresh > response should be less than or equal to the lifetime of the token. > > > I re-read the appropriate section of STUN RFC 5389: http://tools.ietf.org/search/rfc5389#section-10.2.2 and I have a feeling that the password in the existing TURN clients and TURN servers is supposed to be cached for the lifetime of the session. If we allow the token to be valid for the lifetime of the session that was established with that token (for this particular session only) then probably the draft specs will be easier to implement and it will be more directly related to the original STUN RFC 5389. But I have no strong opinion on that, it can be both ways. Regards, Oleg --047d7bacb47c72ef0904f2a851ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tiru

regarding the refresh requests, = please below:


On Mon, Feb 17, 2014 at 9:34 PM, Tirumaleswar Reddy (tireddy)= <tireddy@cisco.com> wrote:

[Oleg]: Tiru, I'd still like to hear a more defi= nite language: what about "new requests" within the existing sess= ion ? They are allowed to use the old token - right ? When you are saying &= quot;new requests" you mean "new session allocation requests"= ;, right ?

 =

[TR1]

These are my initial= thoughts (we probably need more discussion on this topic):

[a] New token is def= initely applicable for “new session allocation requests”. = If the client uses the token after its lifetime then the TURN server MUST = return error that the token is invalid which is in line with the steps defined in= http://tools.ietf.org/html/rfc6749#section-1.5

[b] For “new r= equest” within the existing session why not use the new token ? This = way the client has to maintain only one token.  We can clarify in the = draft that Refresh request can carry the new access token.  <= /span>

[c The actual lifeti= me provided by the server in the Allocate/refresh response should be less t= han or equal to the lifetime of the token.



I re-read the appropriate section of S= TUN RFC 5389:

http://tools.ietf.org/search/rfc5389#section-10.2.2

and I have a feeling that the password in the ex= isting TURN clients and TURN servers is supposed to be cached for the lifet= ime of the session. If we allow the token to be valid for the lifetime of t= he session that was established with that token (for this particular sessio= n only) then probably the draft specs will be easier to implement and it wi= ll be more directly related to the original STUN RFC 5389.

But I have no strong opinion on that, = it can be both ways.

Regards,
Ol= eg



--047d7bacb47c72ef0904f2a851ea-- From nobody Mon Feb 17 22:49:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E92C1A0366 for ; Mon, 17 Feb 2014 22:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 aEzt8pwgwzV9 for ; Mon, 17 Feb 2014 22:49:04 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3C83A1A042D for ; Mon, 17 Feb 2014 22:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13644; q=dns/txt; s=iport; t=1392706141; x=1393915741; h=from:to:cc:subject:date:message-id:mime-version; bh=tkwgcBh1+txYcOXaZxAHoTe4Wse4n/Mkn5+3C0qGFxg=; b=lWwdZrX0o7hzX/LRGT9ePswFHwGlQ5UaSo2wPDZ0r8GrhkJPDAg5dpo1 74i6+bTyieoFtDTrPTUxaCnTYGYRvOybmY2BH+w9yu4ObPHInWlISNJtt cAK5y2m2HeMXhcSX7oxZJZVcjrX4awAOt8P8BNGYIIhRybpc/Z6QJR/4o Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4GADcBA1OtJV2c/2dsb2JhbABZgkJEOFeqb5RfgRQWdIIlAQEBBC1KAhIBCA4DBAEBCx0oERQIAQkBBA4FCAGHaAMRDcMCDYgPF4xngUkBAR4tBAaDJYEUBJZAgx6LLIVFgW+BPoFxOQ X-IronPort-AV: E=Sophos; i="4.97,500,1389744000"; d="scan'208,217"; a="21179865" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 18 Feb 2014 06:49:00 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1I6n0E3006419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 06:49:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 00:49:00 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt Thread-Index: Ac8sdX3TMieZnzYhT5uLjwFOIolCjg== Date: Tue, 18 Feb 2014 06:48:59 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242C02A9@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.68.192] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242C02A9xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/5FDCVLvvndLpslj77gTZhf55hFY Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 06:49:07 -0000 --_000_913383AAA69FF945B8F946018B75898A242C02A9xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Oleg, OAuth is a framework and we are only using it's concepts in the TURN third = party authorization draft. There are vendors who have implemented and deplo= yed OAuth for authentication and authorization. If standardization is requi= red we can have a separate draft for the communication mechanism b/w the TU= RN server and Authorization server. But only after there is WG consensus th= at handle token better suites TURN third party authorization problem than s= elf-contained token. I see good progress happening in the OAuth WG, for any other generic concer= ns about OAuth it would be fair to include OAuth IETF WG. Cheers, -Tiru From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Tuesday, February 18, 2014 10:42 AM To: Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-= third-party-authz-00.txt Hi Tiru I went thru the OAuth interoperability links which you suggested (see below= ): On Mon, Feb 17, 2014 at 10:29 AM, Oleg Moskalenko > wrote: [TR] Drafts in OAuth WG like https://tools.ietf.org/html/draft-richer-oauth= -introspection-04 discuss the communication mechanism b/w Resource Server a= nd Authorization server. You may also want to look into http://www.ietf.or= g/mail-archive/web/oauth/current/msg08607.html which discusses such communi= cation mechanism already implemented but for a different purpose. I guess i= t all worked because Resource server and Authorization server are developed= by the same company but with this use case we may have to discuss if stand= ardization is required for the communication mechanism. The links provide meaningful suggestions - but the drafts did not result in= definite standards. The current situation in OAuth is that it is a pretty = fragmented and balkanized field... and it is not moving toward a definite i= nteroperability standard. As of now, OAuth is actually not a standard - it is more a framework. So we= have a logical conflict - the TURN specs are definitely a standard, not a = framework, but we introduce a dependency on something that is just a framew= ork. That would be inconsistent. Each OAuth server provider defines its own proprietary API for the Resource= Server. That does not sounds very attractive. In practice, every TURN serv= er provider will have to provide its own OAuth server, too. That will lead = to further fragmentation. Overall, OAuth is a heated minefield full of emotions and from the outside,= it seems to be going nowhere in terms of interoperability. The lead develo= per of OAuth withdrew himself: http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ As a TURN server developer, I'd be very hesitant to tie, closely, the imple= mentation to OAuth. I'd rather suggest to look at other alternatives, givin= g the current state of OAuth - or wait till the things will be clarified an= d OAuth will get more interoperability. Of course we can develop our own OAuth server but that would be a rather un= fortunate outcome of the standardization process. I am not saying that from the technical point of view this draft specs is a= bad idea. The TURN field is ready for something like that; but I see that = OAuth is not ready - and I have concerns on being dependent on OAuth. Tiru, can you address my concerns ? Thanks, Oleg --_000_913383AAA69FF945B8F946018B75898A242C02A9xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Oleg,<= /p>

 

OAuth is a framework and we= are only using it’s concepts in the TURN third party authorization d= raft. There are vendors who have implemented and deployed OAuth for authentication and authorization. If standardization is required we ca= n have a separate draft for the communication mechanism b/w the TURN server= and Authorization server. But only after there is WG consensus that handle= token better suites TURN third party authorization problem than self-contained token. <= /p>

 

I see good progress happeni= ng in the OAuth WG, for any other generic concerns about OAuth it would be = fair to include OAuth IETF WG.

 

Cheers,

-Tiru

 <= /p>

From: Oleg Mos= kalenko [mailto:m= om040267@gmail.com]
Sent: Tuesday, February 18, 2014 10:42 AM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.or= g
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tra= m-turn-third-party-authz-00.txt

 

Hi Tiru

I went thru the OAuth interoperability links which y= ou suggested (see below):

 

On Mon, Feb 17, 2014 at 10:29 AM, Oleg Moskalenko &l= t;mom040267@gmail.= com> wrote:

[TR] Drafts in OAuth WG like https://tools.ietf.org/html/draft-richer-oauth-introspection-04 discuss= the communication mechanism b/w Resource Server and Authorization server. =  You may also want to look into http://www.ietf.org/mail-archive/web/oauth/current/msg08607.html which = discusses such communication mechanism already implemented but for a differ= ent purpose. I guess it all worked because Resource server and Authorizatio= n server are developed by the same company but with this use case we may have to discuss if standardization i= s required for the communication mechanism.

 

 

The links provide mea= ningful suggestions - but the drafts did not result in definite standards. = The current situation in OAuth is that it is a pretty fragmented and balkan= ized field... and it is not moving toward a definite interoperability standard.

As of now, OAuth is actually not a standard - it is = more a framework. So we have a logical conflict - the TURN specs are defini= tely a standard, not a framework, but we introduce a dependency on somethin= g that is just a framework. That would be inconsistent.

 

Each OAuth server pro= vider defines its own proprietary API for the Resource Server. That does no= t sounds very attractive. In practice, every TURN server provider will have= to provide its own OAuth server, too. That will lead to further fragmentation.

Overall, OAuth is a heated minefield full of emotion= s and from the outside, it seems to be going nowhere in terms of interopera= bility. The lead developer of OAuth withdrew himself:

h= ttp://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/=

 

As a TURN server deve= loper, I'd be very hesitant to tie, closely, the implementation to OAuth. I= 'd rather suggest to look at other alternatives, giving the current state o= f OAuth - or wait till the things will be clarified and OAuth will get more interoperability.

Of course we can develop our own OAuth server but th= at would be a rather unfortunate outcome of the standardization process.

 

I am not saying that = from the technical point of view this draft specs is a bad idea. The TURN f= ield is ready for something like that; but I see that OAuth is not ready - = and I have concerns on being dependent on OAuth.

Tiru, can you address my concerns ?

 

Thanks,
Oleg

 

 

--_000_913383AAA69FF945B8F946018B75898A242C02A9xmbrcdx10ciscoc_-- From nobody Tue Feb 18 04:27:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2A61A04B1 for ; Tue, 18 Feb 2014 04:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 7IH8JUfGBFRi for ; Tue, 18 Feb 2014 04:27:05 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA721A04A0 for ; Tue, 18 Feb 2014 04:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9706; q=dns/txt; s=iport; t=1392726422; x=1393936022; h=from:to:cc:subject:date:message-id:mime-version; bh=P+kZPVNSp9DP9nnt2BScAz3vFVbKqaR6mwm6/3mt+p4=; b=CLTA36QV205//rZyqE+fqxpZja861lgEsNxu1uRBgEQkaTUYmdf7LTDU L4ZKV975YK/utJ1T/6oe5eA4OH4N35VfF2kfj8jomVSXcIMcdfg4XLKA0 R4NphKBgsfdMiM8UIY0zw8Lu/NbiliHM7lmMiX9R2E0jMmVlN7nsWWE7P M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwGACVRA1OtJXG8/2dsb2JhbABZgkJEOFe2d4hZgRUWdIIlAQEBBC1KAhIBCA4DBAEBCwsDDygRFAgBCQEEDgUIh2kDEQ3DKw2IDxeMZ4FpMQYLDoMMgRQElkCDHosshUWBb4E+gio X-IronPort-AV: E=Sophos;i="4.97,501,1389744000"; d="scan'208,217";a="304815168" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 18 Feb 2014 12:27:02 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1ICR1KH003922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 12:27:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 06:27:01 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Oleg Moskalenko Thread-Topic: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt Thread-Index: Ac8spLbVrMRo14D/Q1CjsUPyTnakbw== Date: Tue, 18 Feb 2014 12:27:01 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242C05A3@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.66.212] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242C05A3xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/10y6stNqARC6ztvXZ1OmA4n9KpA Cc: "tram@ietf.org" Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-third-party-authz-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 12:27:08 -0000 --_000_913383AAA69FF945B8F946018B75898A242C05A3xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Oleg, "short-term mechanism" is currently only used for ICE connectivity checks a= nd not used for TURN. I don't see any difference how the INTEGRITY field is= calculated with both the short-term and long-term credential mechanisms key =3D MD5(username ":" realm ":" SASLprep(password)) The only exception is "realm" would always be missing for short-term mechan= ism. Anyways like you have mentioned with third party authorization the session = key (password), kid (username) would change frequently and has similarities= with short-term mechanism. -Tiru From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Tuesday, February 18, 2014 11:40 AM To: Tirumaleswar Reddy (tireddy) Cc: tram@ietf.org Subject: Re: [tram] FW: New Version Notification for draft-reddy-tram-turn-= third-party-authz-00.txt Hi Tiru regarding the authentication mechanisms: yes, I am talking about section 10= .1 of STUN RFC 5389: http://tools.ietf.org/search/rfc5389#section-10.1 STUN defines both short-term mechanism and long-term mechanism. They differ= in the ways how the INTEGRITY field is calculated, and in some other minor= details. The names are somewhat unfortunate and confusing; the "short-term= mechanism" is NOT about short-lived ephemeral identities. The proposed tok= en-based authorization is equally applicable to both short-term and long-te= rm mechanisms - taking into account different INTEGRITY calculation algorit= hms. >From the pure technical point of view, I think that the token authorization= is equally applicable to the short-term mechanism than to the long-term me= chanism. Of course the short-term mechanism is not very important in this context be= cause this proposed standard is mostly about WebRTC. But it would be "clean= er" if the token authorization will be applied to the whole STUN/TURN specs= , not to a particular case of WebRTC. And may be some day WebRTC will decid= e to adopt the short-term mechanism... Regards, Oleg --_000_913383AAA69FF945B8F946018B75898A242C05A3xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Oleg,<= /p>

 

“short-term mechanism= ” is currently only used for ICE connectivity checks and not used for= TURN. I don’t see any difference how the INTEGRITY field is calculat= ed with both the short-term and long-term credential mechanisms

key =3D MD5(username "= :" realm ":" SASLprep(password))

The only exception is ̶= 0;realm” would always be missing for short-term mechanism.=

 

Anyways like you have menti= oned with third party authorization the session key (password), kid (userna= me) would change frequently and has similarities with short-term mechanism.

 

-Tiru

From: Oleg Mos= kalenko [mailto:m= om040267@gmail.com]
Sent: Tuesday, February 18, 2014 11:40 AM
To: Tirumaleswar Reddy (tireddy)
Cc: tram@ietf.or= g
Subject: Re: [tram] FW: New Version Notification for draft-reddy-tra= m-turn-third-party-authz-00.txt

 

Hi Tiru

regarding the authent= ication mechanisms: yes, I am talking about section 10.1 of STUN RFC 5389:<= br>
http://tools.= ietf.org/search/rfc5389#section-10.1

STUN defines both short-term mechanism and long-term mechanism. They differ= in the ways how the INTEGRITY field is calculated, and in some other minor= details. The names are somewhat unfortunate and confusing; the "short= -term mechanism" is NOT about short-lived ephemeral identities. The proposed token-based authorization is equally ap= plicable to both short-term and long-term mechanisms - taking into account = different INTEGRITY calculation algorithms.

From the pure technic= al point of view, I think that the token authorization is equally applicabl= e to the short-term mechanism than to the long-term mechanism.

Of course the short-term mechanism is not very impor= tant in this context because this proposed standard is mostly about WebRTC.= But it would be "cleaner" if the token authorization will be app= lied to the whole STUN/TURN specs, not to a particular case of WebRTC. And may be some day WebRTC will decide to adopt= the short-term mechanism...


Regards,
Oleg

--_000_913383AAA69FF945B8F946018B75898A242C05A3xmbrcdx10ciscoc_-- From nobody Tue Feb 18 08:38:41 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEC01A06A5 for ; Tue, 18 Feb 2014 08:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 loLOhcuq4csE for ; Tue, 18 Feb 2014 08:38:34 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 984271A06B4 for ; Tue, 18 Feb 2014 08:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12738; q=dns/txt; s=iport; t=1392741505; x=1393951105; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=kL5dv63zlptM6tVm/j0UagHMaizFBgYdKUhUo0xF5r4=; b=kxPWCHqvz7PJAA1P4vjf5kanAqgXHLc/BE7LAdWK0HqtjCfkfA7rKVuf KTAr4I2lmS1fZ6gnW1skehuMjAI5esy+GRnoseZu+MYWu4oCkI6pBOqCQ gXvWvRBYT2fNi/p8gjftcuSHG+ZkNlf81CGBfVvcUsURgEIUneOoBeIXC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwGAPOLA1OtJXG8/2dsb2JhbABZgkJEOFe2d4hZgRoWdIIlAQEBBAEBASpBGwIBCBEDAQEBCx0HJwsUCQgCBAESCAGHfA3MDReOKiYgDQoBBoMegRQEmV6LL4VCgy2BaUE X-IronPort-AV: E=Sophos; i="4.97,502,1389744000"; d="scan'208,217"; a="21311181" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 18 Feb 2014 16:38:24 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1IGcOa3014962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Feb 2014 16:38:24 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.93]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 10:38:24 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Alan Johnston , "tram@ietf.org" Thread-Topic: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: AQHPLB2O0UOyW7u8qEubmJ8nULyjIpq7LBbg Date: Tue, 18 Feb 2014 16:38:23 +0000 Message-ID: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.57.3] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE224412306xmbrcdx02ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/dBvJQ-Y1WvUwy8Cw77GqlultuZg Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 16:38:37 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE224412306xmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think a Traffic Type attribute (audio, video, data) in addition to Bandwi= dth would help the TURN server make better decisions about the policies des= cribed in the draft, and in particular to the following one: A TURN server might also wish to limit the use of service to audio-only sessions, or low bandwidth video and audio sessions. It might also help SPs who would like to host TURN servers to provide diffe= rentiated treatment for WebRTC media traffic. Of course, there would have to a discussion on what if the application is l= ying about these.. Muthu From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Tuesday, February 18, 2014 1:44 AM To: tram@ietf.org Subject: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt All, We have written a new I-D on a bandwidth attribute for TURN. The use case = is to allow a TURN client to indicate to the server the bandwidth it expect= s to use for the relayed candidate, or for a TURN server to indicate to the= client the maximum bandwidth before the TURN server might apply rate limit= ing. Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent which = was discussed in the past, but this draft does not propose an ICE use case = for consent. Comments most welcome! - Alan - ---------- Forwarded message ---------- From: > Date: Thu, Feb 13, 2014 at 9:07 PM Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Bandwidth Attribute for TURN Authors : Martin Thomson Bernard Aboba Alan Johnston Oleg Moskalenko Filename : draft-thomson-tram-turn-bandwidth-00.txt Pages : 8 Date : 2014-02-13 Abstract: An attribute is defined for Session Traversal Utilities for NAT (STUN) that allows for declarations of bandwidth limits on the negotiated flow. The application of this attribute is the negotiation of bandwidth between a Traversal Using Relays around NAT (TURN) client and a TURN server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwidth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_E721D8C6A2E1544DB2DEBC313AF54DE224412306xmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think a Traffic Type attribute (audio, video, data) in a= ddition to Bandwidth would help the TURN server make better decisions about= the policies described in the draft, and in particular to the following one:

 

    A TURN server might also wish to limit = the use of service

    to audio-only sessions, or low ban= dwidth video and audio

    sessions.

 

It might also help SPs who would like to host TURN servers= to provide differentiated treatment for WebRTC media traffic.

 

Of course, there would have to a discussion on what if the= application is lying about these..

 

Muthu

 

From: tram [ma= ilto:tram-bounces@ietf.org] On Behalf Of Alan Johnston
Sent: Tuesday, February 18, 2014 1:44 AM
To: tram@ietf.org
Subject: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-0= 0.txt

 

All,

 

We have written a new I-D on a bandwidth attribute f= or TURN.  The use case is to allow a TURN client to indicate to the se= rver the bandwidth it expects to use for the relayed candidate, or for a TU= RN server to indicate to the client the maximum bandwidth before the TURN server might apply rate limiting.

 

Note some of the text is from draft-thomson-mmu= sic-rtcweb-bw-consent which was discussed in the past, but this draft does = not propose an ICE use case for consent.

 

Comments most welcome!

 

- Alan -

---------- Forwarded message ----------
From: <internet-drafts@ietf.= org>
Date: Thu, Feb 13, 2014 at 9:07 PM
Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


        Title           : A Ba= ndwidth Attribute for TURN
        Authors         : Martin Th= omson
                     = ;     Bernard Aboba
                     = ;     Alan Johnston
                     = ;     Oleg Moskalenko
        Filename        : draft-tho= mson-tram-turn-bandwidth-00.txt
        Pages           : 8         Date            := 2014-02-13

Abstract:
   An attribute is defined for Session Traversal Utilities for NA= T
   (STUN) that allows for declarations of bandwidth limits on the=
   negotiated flow.  The application of this attribute is th= e
   negotiation of bandwidth between a Traversal Using Relays arou= nd NAT
   (TURN) client and a TURN server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-thomson-tram-= turn-bandwidth/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-thomson-tram-turn-bandw= idth-00


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

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

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

 

--_000_E721D8C6A2E1544DB2DEBC313AF54DE224412306xmbrcdx02ciscoc_-- From nobody Tue Feb 18 09:53:54 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1DF1A06E8 for ; Tue, 18 Feb 2014 09:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 9GgeBX_v4wjg for ; Tue, 18 Feb 2014 09:53:43 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 19DAF1A06EF for ; Tue, 18 Feb 2014 09:53:42 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id u57so12056958wes.13 for ; Tue, 18 Feb 2014 09:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9PGg/YhwgOxRei8Y71qcMkEZ3wbftVSsi9ZI5DwF9fE=; b=yqU7H7fgWZlzLKJMQn5i8MOVhXGYG7ID3mPpTPKn+Sv/k89fz63YksTONCgKhk2PQV VGph8JiefYuREwK8VnAYs+Y3qFEh3YBJL3RT77P3PXorKH1Y9qPmt92PLXB6I/qIXJ5D 2SPT1ZDfNvZg4GTMGAVPT7AUg31C0vimGFhFBYk5QQjUUpyTcYOy5BeUIsKZma+zr6yn 4LxBpJN7/cGoyeQvuQd1LxzuX58wMIgH1DbWZXZ2cDuRGMY3Zi9q9MWnFUeCN9W4HHlW q7cLYBi9iJu2vJ6VkkqBABmqD6novjibHAg+p+t615okLvzsUpzFcQgm/tkDVKtYhRbr 74rA== MIME-Version: 1.0 X-Received: by 10.194.185.165 with SMTP id fd5mr86317wjc.95.1392746019717; Tue, 18 Feb 2014 09:53:39 -0800 (PST) Received: by 10.217.152.10 with HTTP; Tue, 18 Feb 2014 09:53:39 -0800 (PST) In-Reply-To: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> Date: Tue, 18 Feb 2014 11:53:39 -0600 Message-ID: From: Alan Johnston To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: multipart/alternative; boundary=047d7bdc7e2ac48b7a04f2b1f35d Archived-At: http://mailarchive.ietf.org/arch/msg/tram/bEVXiYkEbz0rX965Ke-sHeb4N9g Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:53:50 -0000 --047d7bdc7e2ac48b7a04f2b1f35d Content-Type: text/plain; charset=ISO-8859-1 Muthu, Thanks for the feedback on the draft. I agree that some kind of traffic type indication could also be useful for the TURN client to indicate to the TURN server the nature of the relayed traffic. The TURN server could do this implicitly based on the bandwidth, although it might have difficulty distinguishing a high quality voice session from a low quality video session. Using this indication for QoS could be problematic as you point out, if TURN clients lie about the nature of the traffic to get a higher priority than they would otherwise. - Alan - On Tue, Feb 18, 2014 at 10:38 AM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: I think a Traffic Type attribute (audio, video, data) in addition to > Bandwidth would help the TURN server make better decisions about the > policies described in the draft, and in particular to the following one: > > > > A TURN server might also wish to limit the use of service > > to audio-only sessions, or low bandwidth video and audio > > sessions. > > > > It might also help SPs who would like to host TURN servers to provide > differentiated treatment for WebRTC media traffic. > > > > Of course, there would have to a discussion on what if the application is > lying about these.. > > > > Muthu > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Alan Johnston > *Sent:* Tuesday, February 18, 2014 1:44 AM > *To:* tram@ietf.org > *Subject:* [tram] Fwd: I-D Action: > draft-thomson-tram-turn-bandwidth-00.txt > > > > All, > > > > We have written a new I-D on a bandwidth attribute for TURN. The use case > is to allow a TURN client to indicate to the server the bandwidth it > expects to use for the relayed candidate, or for a TURN server to indicate > to the client the maximum bandwidth before the TURN server might apply rate > limiting. > > > > Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent which > was discussed in the past, but this draft does not propose an ICE use case > for consent. > > > > Comments most welcome! > > > > - Alan - > > ---------- Forwarded message ---------- > From: > Date: Thu, Feb 13, 2014 at 9:07 PM > Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Bandwidth Attribute for TURN > Authors : Martin Thomson > Bernard Aboba > Alan Johnston > Oleg Moskalenko > Filename : draft-thomson-tram-turn-bandwidth-00.txt > Pages : 8 > Date : 2014-02-13 > > Abstract: > An attribute is defined for Session Traversal Utilities for NAT > (STUN) that allows for declarations of bandwidth limits on the > negotiated flow. The application of this attribute is the > negotiation of bandwidth between a Traversal Using Relays around NAT > (TURN) client and a TURN server. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwidth/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draftdirectories: > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > --047d7bdc7e2ac48b7a04f2b1f35d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Muthu,

Thanks for the feedback on the d= raft.

I agree that some kind of traffic type indic= ation could also be useful for the TURN client to indicate to the TURN serv= er the nature of the relayed traffic. =A0The TURN server could do this impl= icitly based on the bandwidth, although it might have difficulty distinguis= hing a high quality voice session from a low quality video session.

Using this indication for QoS could be problematic as y= ou point out, if TURN clients lie about the nature of the traffic to get a = higher priority than they would otherwise.=A0

- Al= an -


On Tue, Feb 1= 8, 2014 at 10:38 AM, Muthu Arul Mozhi Perumal (mperumal) = <mperumal@cisco.= com> wrote:

I think a Traffic Type attribute (audio, video, data) in a= ddition to Bandwidth would help the TURN server make better decisions about= the policies described in the draft, and in particular to the following one:

=A0

=A0=A0=A0 A TURN server might also wish to limit the use o= f service

=A0=A0=A0=A0to audio-only sessions, or low bandwidth video= and audio

=A0=A0=A0=A0sessions.

=A0

It might also help SPs who would like to host TURN servers= to provide differentiated treatment for WebRTC media traffic.

=A0

Of course, there would have to a discussion on what if the= application is lying about these..

=A0

Muthu

=A0

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Alan Johnston
Sent: Tuesday, February 18, 2014 1:44 AM
To: tram@ietf.org=
Subject: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-0= 0.txt

=A0

All,

=A0

We have written a new I-D on a bandwidth attribute f= or TURN. =A0The use case is to allow a TURN client to indicate to the serve= r the bandwidth it expects to use for the relayed candidate, or for a TURN = server to indicate to the client the maximum bandwidth before the TURN server might apply rate limiting.=

=A0

Note some of the text is from=A0draft-thomson-mmusic= -rtcweb-bw-consent which was discussed in the past, but this draft does not= propose an ICE use case for consent.

=A0

Comments most welcome!

=A0

- Alan -

---------- Forwarded message ----------
From: <int= ernet-drafts@ietf.org>
Date: Thu, Feb 13, 2014 at 9:07 PM
Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
To: i-d-announce= @ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : A Bandwidth Attribute for TURN<= br> =A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Martin Thomson
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bernard Aboba
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Alan Johnston
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Oleg Moskalenko
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-thomson-tram-turn-bandwidth= -00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-02-13

Abstract:
=A0 =A0An attribute is defined for Session Traversal Utilities for NAT
=A0 =A0(STUN) that allows for declarations of bandwidth limits on the
=A0 =A0negotiated flow. =A0The application of this attribute is the
=A0 =A0negotiation of bandwidth between a Traversal Using Relays around NAT=
=A0 =A0(TURN) client and a TURN server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-thomson-tram-= turn-bandwidth/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-thomson-tram-turn-bandw= idth-00


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

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

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

=A0


--047d7bdc7e2ac48b7a04f2b1f35d-- From nobody Tue Feb 18 09:55:50 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E696E1A06EC for ; Tue, 18 Feb 2014 09:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 2mUnQ_Ok26tj for ; Tue, 18 Feb 2014 09:55:39 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 404861A06DE for ; Tue, 18 Feb 2014 09:55:39 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id un15so17042805pbc.4 for ; Tue, 18 Feb 2014 09:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5l+4IEyfLPa9KaGUqVzsoE8nMJjZAN7ETQEFg4BUy1U=; b=zrYrc2IoG1FIjxeEcdO7ZKBKj1KfAfO6TGW6OlStq2GI2HMOVns41ca9zHD1cMBjBL BD66wFWCtflKxlQq+u4Ee6b7SFyiO3aLPgmbpU2UTr6CN+arXrDGsaIkVc2qihuLYPgs dXDmXMvwRE5cFuxNkiq6105L/OAL3k3eZ93NpdZpLke1DZW4E7eL0HL+59WJFo6ci04i spO8BjdBn3yaZR5+FCVDl8AEnr886p0s2CBQ4j1BViTPBjBpfqYFWoYOrYeo8rMxiSpB dH4wUoGdD1uI5mnjeZOCDPTimKymA5XzJDy+wH4Uc39ZSA7RzvJZC5B6MysUfxUvGufr kfJw== MIME-Version: 1.0 X-Received: by 10.68.237.133 with SMTP id vc5mr34602171pbc.92.1392746136334; Tue, 18 Feb 2014 09:55:36 -0800 (PST) Received: by 10.68.147.131 with HTTP; Tue, 18 Feb 2014 09:55:36 -0800 (PST) In-Reply-To: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> Date: Tue, 18 Feb 2014 09:55:36 -0800 Message-ID: From: Oleg Moskalenko To: "Muthu Arul Mozhi Perumal (mperumal)" Content-Type: multipart/alternative; boundary=047d7b338f1db7f91a04f2b1fa70 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/SedwlamgqEvthAY9NWbcnZpbr-U Cc: Alan Johnston , "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 17:55:41 -0000 --047d7b338f1db7f91a04f2b1fa70 Content-Type: text/plain; charset=ISO-8859-1 I am not sure about further detalization of the traffic... the next step would be codec number, type of data (social networks or finance apps), etc - where to stop ? Oleg On Tue, Feb 18, 2014 at 8:38 AM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: > I think a Traffic Type attribute (audio, video, data) in addition to > Bandwidth would help the TURN server make better decisions about the > policies described in the draft, and in particular to the following one: > > > > A TURN server might also wish to limit the use of service > > to audio-only sessions, or low bandwidth video and audio > > sessions. > > > > It might also help SPs who would like to host TURN servers to provide > differentiated treatment for WebRTC media traffic. > > > > Of course, there would have to a discussion on what if the application is > lying about these.. > > > > Muthu > > > > *From:* tram [mailto:tram-bounces@ietf.org] *On Behalf Of *Alan Johnston > *Sent:* Tuesday, February 18, 2014 1:44 AM > *To:* tram@ietf.org > *Subject:* [tram] Fwd: I-D Action: > draft-thomson-tram-turn-bandwidth-00.txt > > > > All, > > > > We have written a new I-D on a bandwidth attribute for TURN. The use case > is to allow a TURN client to indicate to the server the bandwidth it > expects to use for the relayed candidate, or for a TURN server to indicate > to the client the maximum bandwidth before the TURN server might apply rate > limiting. > > > > Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent which > was discussed in the past, but this draft does not propose an ICE use case > for consent. > > > > Comments most welcome! > > > > - Alan - > > ---------- Forwarded message ---------- > From: > Date: Thu, Feb 13, 2014 at 9:07 PM > Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Bandwidth Attribute for TURN > Authors : Martin Thomson > Bernard Aboba > Alan Johnston > Oleg Moskalenko > Filename : draft-thomson-tram-turn-bandwidth-00.txt > Pages : 8 > Date : 2014-02-13 > > Abstract: > An attribute is defined for Session Traversal Utilities for NAT > (STUN) that allows for declarations of bandwidth limits on the > negotiated flow. The application of this attribute is the > negotiation of bandwidth between a Traversal Using Relays around NAT > (TURN) client and a TURN server. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwidth/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draftdirectories: > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7b338f1db7f91a04f2b1fa70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am not sure about further detalization of the traff= ic... the next step would be codec number, type of data (social networks or= finance apps), etc - where to stop ?

Oleg


On Tue, Feb 18, 2014 at 8:38 AM, Muthu A= rul Mozhi Perumal (mperumal) <mperumal@cisco.com> wrote:

I think a Traffic Type attribute (audio, video, data) in a= ddition to Bandwidth would help the TURN server make better decisions about= the policies described in the draft, and in particular to the following one:

=A0

=A0=A0=A0 A TURN server might also wish to limit the use o= f service

=A0=A0=A0=A0to audio-only sessions, or low bandwidth video= and audio

=A0=A0=A0=A0sessions.

=A0

It might also help SPs who would like to host TURN servers= to provide differentiated treatment for WebRTC media traffic.

=A0

Of course, there would have to a discussion on what if the= application is lying about these..

=A0

Muthu

=A0

From: tram [ma= ilto:tram-bounce= s@ietf.org] On Behalf Of Alan Johnston
Sent: Tuesday, February 18, 2014 1:44 AM
To: tram@ietf.org=
Subject: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-0= 0.txt

=A0

All,

=A0

We have written a new I-D on a bandwidth attribute f= or TURN. =A0The use case is to allow a TURN client to indicate to the serve= r the bandwidth it expects to use for the relayed candidate, or for a TURN = server to indicate to the client the maximum bandwidth before the TURN server might apply rate limiting.=

=A0

Note some of the text is from=A0draft-thomson-mmusic= -rtcweb-bw-consent which was discussed in the past, but this draft does not= propose an ICE use case for consent.

=A0

Comments most welcome!

=A0

- Alan -

---------- Forwarded message ----------
From: <int= ernet-drafts@ietf.org>
Date: Thu, Feb 13, 2014 at 9:07 PM
Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
To: i-d-announce= @ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : A Bandwidth Attribute for TURN<= br> =A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Martin Thomson
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Bernard Aboba
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Alan Johnston
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Oleg Moskalenko
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-thomson-tram-turn-bandwidth= -00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 8
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-02-13

Abstract:
=A0 =A0An attribute is defined for Session Traversal Utilities for NAT
=A0 =A0(STUN) that allows for declarations of bandwidth limits on the
=A0 =A0negotiated flow. =A0The application of this attribute is the
=A0 =A0negotiation of bandwidth between a Traversal Using Relays around NAT=
=A0 =A0(TURN) client and a TURN server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-thomson-tram-= turn-bandwidth/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-thomson-tram-turn-bandw= idth-00


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

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

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

=A0


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--047d7b338f1db7f91a04f2b1fa70-- From nobody Tue Feb 18 10:22:31 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9F51A0513 for ; Tue, 18 Feb 2014 10:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 CcIfCPOFG3Rw for ; Tue, 18 Feb 2014 10:22:26 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 178FE1A020C for ; Tue, 18 Feb 2014 10:22:26 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 17DCF41172 for ; Tue, 18 Feb 2014 13:22:23 -0500 (EST) Message-ID: <5303A4DE.8090500@viagenie.ca> Date: Tue, 18 Feb 2014 13:22:22 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/uTK_4ecSB8hT6EcPqr3rjL0YDNI Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 18:22:29 -0000 Le 2014-02-18 11:38, Muthu Arul Mozhi Perumal (mperumal) a écrit : > I think a Traffic Type attribute (audio, video, data) in addition to > Bandwidth would help the TURN server make better decisions about the > policies described in the draft Isn't DSCP already sufficient? Nothing prevents the TURN server from actually using the stuff... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Feb 18 13:12:54 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F141A025C for ; Tue, 18 Feb 2014 13:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 UHmUS7IFyj2k for ; Tue, 18 Feb 2014 13:12:50 -0800 (PST) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id F21121A020D for ; Tue, 18 Feb 2014 13:12:49 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id up15so17381384pbc.0 for ; Tue, 18 Feb 2014 13:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N00Or8R8n2Gj3FRkyJHbDyqAHpxpJVeo6V1icNDEivI=; b=1FWGVbDe2ejpgSATV1gb0csKlUXF90kH9YRJKvAU6aTeOqMk5jKLG0dvOpuooopgcD bX2Cavihkfz06KYf/H8tco08aD9gRC0yU/L1lgPsbL+SY07iCi+0MQ8tgxPdJGVoSGn+ lxoGY/VNiYYBRmEoA3xopa/QfUkZamzuzpNROhI6YV/Vnne7xSaCo0jPMMH2y6ZT8old QqPK5DXLEKIpZppKjFqlqNyNGg8PWcCN77ymTR49JtRJK32WUNsj4wPCbSeO6Ty5Zdom jmCTh1lnuD7D5Nvn+XGO36PP8Umurf6BEBSKWkJXyfTGXEkDseMc4IskhB7zIlFwk8PM 9/NA== MIME-Version: 1.0 X-Received: by 10.66.228.37 with SMTP id sf5mr35453726pac.19.1392757967118; Tue, 18 Feb 2014 13:12:47 -0800 (PST) Received: by 10.68.147.131 with HTTP; Tue, 18 Feb 2014 13:12:46 -0800 (PST) In-Reply-To: <5303A4DE.8090500@viagenie.ca> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> Date: Tue, 18 Feb 2014 13:12:46 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b111dd9e363ce04f2b4bb50 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/K5NIqbOYuPmkWGNsQ6hb6dEIFF4 Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:12:52 -0000 --047d7b111dd9e363ce04f2b4bb50 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable How to handle the DS and ECN fields is a part of TURN server RFC (see the section 12): http://tools.ietf.org/search/rfc5766#section-12 And a good TURN server is supposed to implement that. Regards, Oleg On Tue, Feb 18, 2014 at 10:22 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-02-18 11:38, Muthu Arul Mozhi Perumal (mperumal) a =E9crit : > > I think a Traffic Type attribute (audio, video, data) in addition to > > Bandwidth would help the TURN server make better decisions about the > > policies described in the draft > > Isn't DSCP already sufficient? Nothing prevents the TURN server from > actually using the stuff... > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b111dd9e363ce04f2b4bb50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
How to handle the DS and ECN fields is a part of= TURN server RFC (see the section 12):

http://tools.ietf.org/search/rfc5766#section= -12

And a good TURN server is supposed to implement that.

Regards,
Oleg


<= br>
On Tue, Feb 18, 2014 at 10:22 AM, Simon Perre= ault <simon.perreault@viagenie.ca> wrote:
Le 2014-02-18 11:38, Muthu Arul Mozhi Peruma= l (mperumal) a =E9crit :
> I think a Traffic Type attribute (audio, video, data= ) in addition to
> Bandwidth would help the TURN server make better decisions about the > policies described in the draft

Isn't DSCP already sufficient? Nothing prevents the TURN server f= rom
actually using the stuff...

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b111dd9e363ce04f2b4bb50-- From nobody Tue Feb 18 13:33:08 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256481A025A for ; Tue, 18 Feb 2014 13:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 7esXVE068pqe for ; Tue, 18 Feb 2014 13:33:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id E0DCC1A0081 for ; Tue, 18 Feb 2014 13:33:03 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B5003403CE for ; Tue, 18 Feb 2014 16:33:00 -0500 (EST) Message-ID: <5303D18C.5030705@viagenie.ca> Date: Tue, 18 Feb 2014 16:33:00 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oC6W6yBkp8JOU_vStK3xVrnbE1c Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:33:06 -0000 Le 2014-02-18 16:12, Oleg Moskalenko a écrit : > How to handle the DS and ECN fields is a part of TURN server RFC (see > the section 12): > > http://tools.ietf.org/search/rfc5766#section-12 > > And a good TURN server is supposed to implement that. Well, the RFC just says that the TURN server should copy the DSCP from one side to the other when doing en/de-capsulation. It doesn't say that the server should actually do QoS based on the DSCP. My point is that there's nothing preventing the server from actually doing it. Anyway, I was expecting responses along the lines of "DiffServ doesn't work on the Internet in general." To which I would have replied: "then couldn't we define a STUN attribute for transporting the DSCP in the payload?" Instead of inventing a new taxonomy (audio, video, slides, etc.), why not reuse DSCP? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Feb 18 13:46:53 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D8A1A0276 for ; Tue, 18 Feb 2014 13:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 QqpxnoucHNz8 for ; Tue, 18 Feb 2014 13:46:51 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 650081A02B9 for ; Tue, 18 Feb 2014 13:46:51 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id uo5so17256223pbc.41 for ; Tue, 18 Feb 2014 13:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iewIIszo43dkQdoZ6yFIfzJF9hhcbt+hfyTs0RbKyo0=; b=u/TVATdPG07Jo1D/3E5aKNF5BL906YCI0bEPeRjFQfP7TWqsI3gepmUrCC8PIu2Khu gyYS3cKPLz9AKq6PhJmZ0vUnBgzUIJsbsd/MiVN+cz7pY4fyLHSXbSP7mgp1vGQUhzut scqhA0WdAVqVjyROW2NF7hTad/SktvQnHHb2S5odV200XbhqGZFgSZDbABZ4U7hP2xfm Lgi+rT/j8lVLyxothj4YLrT0D6nFcJKvsswmwAT7mOj2fJ8+BtsKG0b2lLcri2TYENS8 CrtZrvT6BCT6gJesrG6U73ptcLmD+M2wQBa6TmmJr8vGk6nR5UEqdwxIODuSIFylYlnJ p6VA== MIME-Version: 1.0 X-Received: by 10.68.212.161 with SMTP id nl1mr17575332pbc.142.1392760008540; Tue, 18 Feb 2014 13:46:48 -0800 (PST) Received: by 10.68.147.131 with HTTP; Tue, 18 Feb 2014 13:46:48 -0800 (PST) In-Reply-To: <5303D18C.5030705@viagenie.ca> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> Date: Tue, 18 Feb 2014 13:46:48 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=e89a8ff1c89c910ad104f2b5355f Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RiAPqRKiESq6gSgO1l3pYXYW_uw Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 21:46:52 -0000 --e89a8ff1c89c910ad104f2b5355f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Feb 18, 2014 at 1:33 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-02-18 16:12, Oleg Moskalenko a =E9crit : > > > Anyway, I was expecting responses along the lines of "DiffServ doesn't > work on the Internet in general." To which I would have replied: "then > couldn't we define a STUN attribute for transporting the DSCP in the > payload?" Instead of inventing a new taxonomy (audio, video, slides, > etc.), why not reuse DSCP? > > > That would make sense - as s solution that does not require the TURN server to be too smart but that allows some "easy" traffic engineering. --e89a8ff1c89c910ad104f2b5355f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 18, 2014 at 1:33 PM, Simon Perreault = <simon.= perreault@viagenie.ca> wrote:
Le 2014-02-18 16:12, Oleg Moskalenko a =E9cr= it :


Anyway, I was expecting responses along the lines of "DiffServ doesn&#= 39;t
work on the Internet in general." To which I would have replied: "= ;then
couldn't we define a STUN attribute for transporting the DSCP in the payload?" Instead of inventing a new taxonomy (audio, video, slides, etc.), why not reuse DSCP?



That would make sense - as= s solution that does not require the TURN server to be too smart but that = allows some "easy" traffic engineering.

--e89a8ff1c89c910ad104f2b5355f-- From nobody Tue Feb 18 14:04:13 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93FD1A0547 for ; Tue, 18 Feb 2014 14:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 BKSI_oewa9l5 for ; Tue, 18 Feb 2014 14:04:08 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 97FB01A0404 for ; Tue, 18 Feb 2014 14:04:05 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Tq0h1n0020cZkys5By42XN; Tue, 18 Feb 2014 22:04:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id Ty421n00B3ZTu2S3Wy4216; Tue, 18 Feb 2014 22:04:02 +0000 Message-ID: <5303D8D2.5080003@alum.mit.edu> Date: Tue, 18 Feb 2014 17:04:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392761042; bh=A8zLP3gQtw8jQGqJd/cLYYJpv9WbLsedpRvgJWo6iao=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=bty/9YXoPrYDw0Rh3sgiymIZ5+cnBnukULK0QMIDQ8e5E8T9dhzH6ZtFrwC2ZDRWP nW4VKB380fCLC9uHwiBKFwheLJIiSn2sTi2g2jA5uzaxAAGzLQWVHEFjDnr+Wufcsx 4DIYpGG6d9+/EIJsdaPwRkGUOJn0XhYSDiYqLO9of/Ic3xvPv/4X4+0zUIVD5xowlH EH95A9fmb3wRfTDI2tL8ZEIqP8TJui9Yu01BCBqWgFyZtr93Cdczp26AgqAtrUGX08 KxqKq6DgfYpuB+aQ+T9H8WTdFfxTjaCRAbi3b/iXgMoLLNdXRfn6qb5zNth3jNm8k0 rib4JAtZ/BhjQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/uNnO0v_HeikUZ9frL59i_HTTC_4 Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 22:04:11 -0000 On 2/18/14 4:46 PM, Oleg Moskalenko wrote: > > > > On Tue, Feb 18, 2014 at 1:33 PM, Simon Perreault > > wrote: > > Le 2014-02-18 16:12, Oleg Moskalenko a écrit : > > > Anyway, I was expecting responses along the lines of "DiffServ doesn't > work on the Internet in general." To which I would have replied: "then > couldn't we define a STUN attribute for transporting the DSCP in the > payload?" Instead of inventing a new taxonomy (audio, video, slides, > etc.), why not reuse DSCP? > > > > That would make sense - as s solution that does not require the TURN > server to be too smart but that allows some "easy" traffic engineering. There is draft-ietf-mmusic-traffic-class-for-sdp-04 (recently expired). It would have to be adapted to be fitted into TURN, but it provides a taxonomy. Thanks, Paul From nobody Tue Feb 18 14:08:44 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97051A0470 for ; Tue, 18 Feb 2014 14:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Gc_4m5d-55nP for ; Tue, 18 Feb 2014 14:08:41 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id B4AA11A0404 for ; Tue, 18 Feb 2014 14:08:41 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kx10so17212885pab.21 for ; Tue, 18 Feb 2014 14:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QEEsbeltQqhFHcnl4Zf5Wiq+n4b35h4CYNVy6uAbF28=; b=Dr2Yy+y88dTUXAXRzLrokQYMbzYTOx+cVaK90u60etnxjpwWMUnpEtzxvJF/b/kAsI Xw+alzGH40d89dJkohkwGEJoxsg0RS1ZUd/Ab2Wmg0iJEk1J/Io78JR3YErxPKTOKj2w zGUOof8RVu2K5rYQ0P+Cwade7cTvr3WCnAejZrKSzQm/XcBkEDxT7vhe/3pVBWj/V+oJ yplm+HjRTN0BZASI10US3v/abF6uSFh3Lej9ynoXgXXaukzRqHWyB3JkW4jwFzxA3vSZ W5LlfIA0pC+5w4BiT5n3epw1n2AH/CyyIdtcI1OgdTeDyHkiPurzyNKDfp20C2uYtcGU SNZQ== MIME-Version: 1.0 X-Received: by 10.66.160.2 with SMTP id xg2mr35363503pab.23.1392761318881; Tue, 18 Feb 2014 14:08:38 -0800 (PST) Received: by 10.68.147.131 with HTTP; Tue, 18 Feb 2014 14:08:38 -0800 (PST) In-Reply-To: <5303D8D2.5080003@alum.mit.edu> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> <5303D8D2.5080003@alum.mit.edu> Date: Tue, 18 Feb 2014 14:08:38 -0800 Message-ID: From: Oleg Moskalenko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7bacb47cab3eef04f2b58387 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/pglyOn-5XxD8NF7cZqrkvFYADSs Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 22:08:43 -0000 --047d7bacb47cab3eef04f2b58387 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable TURN/STUN has been a binary protocol, so far... bringing SDP into the picture would make it too complicated. Thanks Oleg On Tue, Feb 18, 2014 at 2:04 PM, Paul Kyzivat wrote= : > On 2/18/14 4:46 PM, Oleg Moskalenko wrote: > >> >> >> >> On Tue, Feb 18, 2014 at 1:33 PM, Simon Perreault >> > wrote= : >> >> Le 2014-02-18 16:12, Oleg Moskalenko a =E9crit : >> >> >> Anyway, I was expecting responses along the lines of "DiffServ doesn= 't >> work on the Internet in general." To which I would have replied: "th= en >> couldn't we define a STUN attribute for transporting the DSCP in the >> payload?" Instead of inventing a new taxonomy (audio, video, slides, >> etc.), why not reuse DSCP? >> >> >> >> That would make sense - as s solution that does not require the TURN >> server to be too smart but that allows some "easy" traffic engineering. >> > > There is draft-ietf-mmusic-traffic-class-for-sdp-04 (recently expired). > > It would have to be adapted to be fitted into TURN, but it provides a > taxonomy. > > Thanks, > Paul > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7bacb47cab3eef04f2b58387 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
TURN/STUN has been a binary protocol, so far... bring= ing SDP into the picture would make it too complicated.

Thanks=
Oleg


On Tue, Feb 18, 2014 at 2:04 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
On 2/18/14 4:46 PM, Oleg Moskalenko wrote:



On Tue, Feb 18, 2014 at 1:33 PM, Simon Perreault
<simon.= perreault@viagenie.ca <mailto:simon.perreault@viagenie.ca>> w= rote:

=A0 =A0 Le 2014-02-18 16:12, Oleg Moskalenko a =E9crit :


=A0 =A0 Anyway, I was expecting responses along the lines of "DiffServ= doesn't
=A0 =A0 work on the Internet in general." To which I would have replie= d: "then
=A0 =A0 couldn't we define a STUN attribute for transporting the DSCP i= n the
=A0 =A0 payload?" Instead of inventing a new taxonomy (audio, video, s= lides,
=A0 =A0 etc.), why not reuse DSCP?



That would make sense - as s solution that does not require the TURN
server to be too smart but that allows some "easy" traffic engine= ering.

There is draft-ietf-mmusic-traffic-class-for-sdp-04 (recently expire= d).

It would have to be adapted to be fitted into TURN, but it provides a taxon= omy.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7bacb47cab3eef04f2b58387-- From nobody Tue Feb 18 14:35:10 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68FC1A0296 for ; Tue, 18 Feb 2014 14:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 OjBOG7EQLiUb for ; Tue, 18 Feb 2014 14:35:08 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 09B691A0268 for ; Tue, 18 Feb 2014 14:35:07 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA11.westchester.pa.mail.comcast.net with comcast id Tpgg1n00617dt5G5Byb4NZ; Tue, 18 Feb 2014 22:35:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id Tyb41n00k3ZTu2S3Zyb4An; Tue, 18 Feb 2014 22:35:04 +0000 Message-ID: <5303E018.6040405@alum.mit.edu> Date: Tue, 18 Feb 2014 17:35:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Oleg Moskalenko References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> <5303D8D2.5080003@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392762904; bh=tqx8xMXOQj/tMl9vb9mkoXN0KBTlnn6MMbKSBcegtlU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sK8wD1qPw9IrnUcvRajLue/ooN4TnWiOM+CWlN7qYAeZvdsAeEJis/Ef48GD0B47+ S2hJrCWLUmc7ZVLwWiHJG2NSma58yHbgGDbVq8DxehWvRoUeYyZ18o+UpZ0TS/yndt fqrAryxsWZ5U1IMgL1rF6aeMN/sWAot9C3C+oshkzp+z8InPxmFHHbalcKWpMqzpnj yb06Os9th2hKIM6MAY5505Jo+Ukbw124WCzD1/nJpSZmhUluLEY/E3wGSArkCNfUkA Tp2n7trM2OzEWftvyqr9+k2ut20p6TUrwA/jaM38YnlE6SnuYidXj9wrGIm6q4qYR/ S/v7YMEGW+c4Q== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/6x-Ri9KnAD9NmCVPfs-eGw-xfiw Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 22:35:10 -0000 On 2/18/14 5:08 PM, Oleg Moskalenko wrote: > TURN/STUN has been a binary protocol, so far... bringing SDP into the > picture would make it too complicated. I didn't mean that. I just meant that the taxonomy could potentially be adopted in some way. (Whether that is a good idea is another story. I haven't followed the work closely. It isn't obvious to me that the particular taxonomy is well justified.) Thanks, Paul > Thanks > Oleg > > > On Tue, Feb 18, 2014 at 2:04 PM, Paul Kyzivat > wrote: > > On 2/18/14 4:46 PM, Oleg Moskalenko wrote: > > > > > On Tue, Feb 18, 2014 at 1:33 PM, Simon Perreault > > >> wrote: > > Le 2014-02-18 16:12, Oleg Moskalenko a écrit : > > > Anyway, I was expecting responses along the lines of > "DiffServ doesn't > work on the Internet in general." To which I would have > replied: "then > couldn't we define a STUN attribute for transporting the > DSCP in the > payload?" Instead of inventing a new taxonomy (audio, > video, slides, > etc.), why not reuse DSCP? > > > > That would make sense - as s solution that does not require the TURN > server to be too smart but that allows some "easy" traffic > engineering. > > > There is draft-ietf-mmusic-traffic-__class-for-sdp-04 (recently > expired). > > It would have to be adapted to be fitted into TURN, but it provides > a taxonomy. > > Thanks, > Paul > > > _________________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/__listinfo/tram > > > From nobody Tue Feb 18 19:52:46 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4CC1A0310 for ; Tue, 18 Feb 2014 19:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 wPWgJ8c26lLC for ; Tue, 18 Feb 2014 19:52:38 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 94DF21A0321 for ; Tue, 18 Feb 2014 19:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20582; q=dns/txt; s=iport; t=1392781955; x=1393991555; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oCSG1eMFdUok+Xb+byEoMmesTe3FWaaNlDC6+Z8Fheo=; b=Eo29WHrhGkreP6mIZA2IuKl4u0E886QIgh7F1FkHMxmr/n10xFR9LR/S 0Mmk3EnO4MLL+G6PQg2lR8HDYOljy7+HLN5Sj/RPcaEJ3i1egblLhnmO9 rTyByRwkaLv9Nrz45BNCvs8voTO3o4ymepfOLKEOjSLfPuNoo7hGwSNSV w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As4FADMqBFOtJXHA/2dsb2JhbABZgkJEOFe3cIhWgSIWdIIlAQEBBAEBASpBCxACAQgRAwEBAQsdBycLFAkIAgQBDQUIAYd8Dc0VF44NJiANBAYBBgODG4EUBJliiy+FQ4MtgWlB X-IronPort-AV: E=Sophos; i="4.97,503,1389744000"; d="scan'208,217"; a="21459944" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-2.cisco.com with ESMTP; 19 Feb 2014 03:52:34 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1J3qYXa010510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 03:52:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 21:52:34 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Alan Johnston , "Muthu Arul Mozhi Perumal (mperumal)" Thread-Topic: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: AQHPLB2K/OFKlBXv7US7eZzxspNAEZq7nAeAgAAVCICAAD7KgA== Date: Wed, 19 Feb 2014 03:52:33 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242C0E78@xmb-rcd-x10.cisco.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.59.38] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A242C0E78xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/mlRKnoZVE8MsRxHKSkMwScwQqzg Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 03:52:43 -0000 --_000_913383AAA69FF945B8F946018B75898A242C0E78xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alan, Inline [TR] From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Tuesday, February 18, 2014 11:24 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.t= xt Muthu, Thanks for the feedback on the draft. I agree that some kind of traffic type indication could also be useful for = the TURN client to indicate to the TURN server the nature of the relayed tr= affic. The TURN server could do this implicitly based on the bandwidth, al= though it might have difficulty distinguishing a high quality voice session= from a low quality video session. Using this indication for QoS could be problematic as you point out, if TUR= N clients lie about the nature of the traffic to get a higher priority than= they would otherwise. [TR] Since TURN authentication is always used. TURN server can enforce per = user limits and even if the application lies saying all the flows need high= priority it would only impact the user's bandwidth and it should not impac= t other users. -Tiru - Alan - On Tue, Feb 18, 2014 at 10:38 AM, Muthu Arul Mozhi Perumal (mperumal) > wrote: I think a Traffic Type attribute (audio, video, data) in addition to Bandwi= dth would help the TURN server make better decisions about the policies des= cribed in the draft, and in particular to the following one: A TURN server might also wish to limit the use of service to audio-only sessions, or low bandwidth video and audio sessions. It might also help SPs who would like to host TURN servers to provide diffe= rentiated treatment for WebRTC media traffic. Of course, there would have to a discussion on what if the application is l= ying about these.. Muthu From: tram [mailto:tram-bounces@ietf.org] On = Behalf Of Alan Johnston Sent: Tuesday, February 18, 2014 1:44 AM To: tram@ietf.org Subject: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt All, We have written a new I-D on a bandwidth attribute for TURN. The use case = is to allow a TURN client to indicate to the server the bandwidth it expect= s to use for the relayed candidate, or for a TURN server to indicate to the= client the maximum bandwidth before the TURN server might apply rate limit= ing. Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent which = was discussed in the past, but this draft does not propose an ICE use case = for consent. Comments most welcome! - Alan - ---------- Forwarded message ---------- From: > Date: Thu, Feb 13, 2014 at 9:07 PM Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Bandwidth Attribute for TURN Authors : Martin Thomson Bernard Aboba Alan Johnston Oleg Moskalenko Filename : draft-thomson-tram-turn-bandwidth-00.txt Pages : 8 Date : 2014-02-13 Abstract: An attribute is defined for Session Traversal Utilities for NAT (STUN) that allows for declarations of bandwidth limits on the negotiated flow. The application of this attribute is the negotiation of bandwidth between a Traversal Using Relays around NAT (TURN) client and a TURN server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwidth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_913383AAA69FF945B8F946018B75898A242C0E78xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alan,<= /p>

 

Inline [TR]

 <= /p>

From: tram [ma= ilto:tram-bounces@ietf.org] On Behalf Of Alan Johnston
Sent: Tuesday, February 18, 2014 11:24 PM
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: tram@ietf.org
Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwid= th-00.txt

 

Muthu,

 

Thanks for the feedback on the draft.

 

I agree that some kind of traffic type indication co= uld also be useful for the TURN client to indicate to the TURN server the n= ature of the relayed traffic.  The TURN server could do this implicitl= y based on the bandwidth, although it might have difficulty distinguishing a high quality voice session from a low qua= lity video session.

 

Using this indication for QoS could be problematic a= s you point out, if TURN clients lie about the nature of the traffic to get= a higher priority than they would otherwise. 

 <= /p>

[TR] Since TURN authentication is always used. TURN server can enfor= ce per user limits and even if the application lies saying all the flows need= high priority it would only impact the user’s bandwidth and it shoul= d not impact other users.

 

-Tiru

 

- Alan -

 

On Tue, Feb 18, 2014 at 10:38 AM, Muthu Arul Mozhi P= erumal (mperumal) <mperumal@cisco.com> wrote:

 

I think a Traffic Type attribute (audio, video, data) = in addition to Bandwidth would help the TURN server make better decisions about the policies described in the draft, and in particular to = the following one:

 

    A TURN server might also wish to li= mit the use of service

    to audio-only sessions, or low= bandwidth video and audio

    sessions.

 

It might also help SPs who would like to host TURN ser= vers to provide differentiated treatment for WebRTC media traffic.

 

Of course, there would have to a discussion on what if= the application is lying about these..

 

Muthu

 

From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Alan Johnston
Sent: Tuesday, February 18, 2014 1:44 AM
To: tram@ietf.org=
Subject: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-0= 0.txt

 

All,

 

We have written a new I-D on a bandwidth attribute for TURN.  = ;The use case is to allow a TURN client to indicate to the server the bandw= idth it expects to use for the relayed candidate, or for a TURN server to indicate to the client the maximum bandwidth befor= e the TURN server might apply rate limiting.

 

Note some of the text is from draft-thomson-mmusic-rtcweb-bw-= consent which was discussed in the past, but this draft does not propose an= ICE use case for consent.

 

Comments most welcome!

 

- Alan -

---------- Forwarded message ----------
From: <int= ernet-drafts@ietf.org>
Date: Thu, Feb 13, 2014 at 9:07 PM
Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
To: i-d-announce= @ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


        Title           : A Ba= ndwidth Attribute for TURN
        Authors         : Martin Th= omson
                     = ;     Bernard Aboba
                     = ;     Alan Johnston
                     = ;     Oleg Moskalenko
        Filename        : draft-tho= mson-tram-turn-bandwidth-00.txt
        Pages           : 8         Date            := 2014-02-13

Abstract:
   An attribute is defined for Session Traversal Utilities for NA= T
   (STUN) that allows for declarations of bandwidth limits on the=
   negotiated flow.  The application of this attribute is th= e
   negotiation of bandwidth between a Traversal Using Relays arou= nd NAT
   (TURN) client and a TURN server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-thomson-tram-= turn-bandwidth/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-thomson-tram-turn-bandw= idth-00


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

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

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

 

 

--_000_913383AAA69FF945B8F946018B75898A242C0E78xmbrcdx10ciscoc_-- From nobody Tue Feb 18 20:19:45 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342E01A0129 for ; Tue, 18 Feb 2014 20:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 s588wemc1hQR for ; Tue, 18 Feb 2014 20:19:40 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id E7ED11A0325 for ; Tue, 18 Feb 2014 20:19:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6552; q=dns/txt; s=iport; t=1392783577; x=1393993177; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dVJ2cjca9eTrGuMJ5SRZq6Z2d0rn7J8djJMZak+cKNs=; b=ZuuuxoknLvH3FMVbL/4+5Lv1949dX597dbPq7wxlX7F0Vq6jsaB+TPZS BkOZUTzW82lAiFKBk+z9fUumHYhAxEaV392nstLFD0jSBX9JRp9g1N/OR eS7USXmmQsOG+743nZ/EdvwkaeTair73J1SSB9QtgjQ0YL1ZLhiZBUwKg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFAAwwBFOtJXHB/2dsb2JhbABZgkJEOFfARYEbFnSCJQEBAQQtOhIQAgEIDgMEAQELHQcyFAkIAgQBDQUIE4dqzS0Xjg0mMQYBgySBFASJEKFEgy2BaUE X-IronPort-AV: E=Sophos; i="4.97,503,1389744000"; d="scan'208,217"; a="21472474" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-8.cisco.com with ESMTP; 19 Feb 2014 04:19:36 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1J4JaPP006806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 04:19:36 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.93]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 18 Feb 2014 22:19:36 -0600 From: "Muthu Arul Mozhi Perumal (mperumal)" To: Oleg Moskalenko , Simon Perreault Thread-Topic: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: AQHPLB2O0UOyW7u8qEubmJ8nULyjIpq7LBbggABYFa+AAGotAIAAA9sA///+uDA= Date: Wed, 19 Feb 2014 04:19:35 +0000 Message-ID: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.163.208.170] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE224413A26xmbrcdx02ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/FQW-QCh-G8rdEi4i3BGW7Nd1nSY Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 04:19:42 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE224413A26xmbrcdx02ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-rtcweb-qos defines the recommended DSCP values for browsers to u= se for various classes of traffic. If the TURN server can use that, great. = If on the other hand, the OS doesn't allow the browser to set it or the val= ue gets reset, defining a STUN attribute on the same lines makes sense. I j= ust realized draft-martinsen-tram-discuss (DISCUSS) already does that. The = difference being it doesn't limit those attributes to TURN messages alone, = but can certainly be carried in a TURN Allocate request and used by the TUR= N server. Muthu From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Wednesday, February 19, 2014 3:17 AM To: Simon Perreault Cc: tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.t= xt On Tue, Feb 18, 2014 at 1:33 PM, Simon Perreault > wrote: Le 2014-02-18 16:12, Oleg Moskalenko a =E9crit : Anyway, I was expecting responses along the lines of "DiffServ doesn't work on the Internet in general." To which I would have replied: "then couldn't we define a STUN attribute for transporting the DSCP in the payload?" Instead of inventing a new taxonomy (audio, video, slides, etc.), why not reuse DSCP? That would make sense - as s solution that does not require the TURN server= to be too smart but that allows some "easy" traffic engineering. --_000_E721D8C6A2E1544DB2DEBC313AF54DE224413A26xmbrcdx02ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

draft-ietf-rtcweb-qos defines the recommended DSCP values = for browsers to use for various classes of traffic. If the TURN server can = use that, great. If on the other hand, the OS doesn't allow the browser to set it or the value gets reset, defining a ST= UN attribute on the same lines makes sense. I just realized draft-martinsen= -tram-discuss (DISCUSS) already does that. The difference being it doesn't = limit those attributes to TURN messages alone, but can certainly be carried in a TURN Allocate request and used by= the TURN server.

 

Muthu

 

From: tram [ma= ilto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Wednesday, February 19, 2014 3:17 AM
To: Simon Perreault
Cc: tram@ietf.org
Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwid= th-00.txt

 

 

 

On Tue, Feb 18, 2014 at 1:33 PM, Simon Perreault <= ;simon.per= reault@viagenie.ca> wrote:

Le 2014-02-18 16:12, Oleg Moskalenko a =E9crit :


Anyway, I was expecting responses along the lines of "DiffServ doesn't=
work on the Internet in general." To which I would have replied: "= ;then
couldn't we define a STUN attribute for transporting the DSCP in the
payload?" Instead of inventing a new taxonomy (audio, video, slides, etc.), why not reuse DSCP?

 

 

That would make sense - as s solution that does not = require the TURN server to be too smart but that allows some "easy&quo= t; traffic engineering.

 

--_000_E721D8C6A2E1544DB2DEBC313AF54DE224413A26xmbrcdx02ciscoc_-- From nobody Wed Feb 19 01:48:08 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BC61A012B for ; Wed, 19 Feb 2014 01:48:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Pbot4wfmPTdB for ; Wed, 19 Feb 2014 01:48:00 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6777A1A00B7 for ; Wed, 19 Feb 2014 01:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2999; q=dns/txt; s=iport; t=1392803275; x=1394012875; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Wjxxvm+wjRtaD8ULO31v9xGW6+/vKMdxi5Q7eprGv54=; b=PsBIVT355yBef4Ds62e9Q+CkXimlVHBILY6GGI6waqxH3x0kD/h5vyED CNO0ZsLB3EBQxYsA81DSDJwMD07It/czpiv/5cpXaJpy3srbDs8VExDFr DvAGSPXHGbNXc/yXaK9XI7h3W4ElrvC4S+lT2Bgai2skm1JxndXKfivyU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJF9BFOtJV2Y/2dsb2JhbABZgwaBD790gRwWdIImAQEEeRACAQhGMiUCBA4gh2rNQheOAy4zB4MkgRQEmDCSJIMtgWlB X-IronPort-AV: E=Sophos;i="4.97,504,1389744000"; d="scan'208";a="21512573" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP; 19 Feb 2014 09:47:55 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1J9ltw3028596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 09:47:55 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 03:47:54 -0600 From: "Pal Martinsen (palmarti)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: AQHPLVepL0ox0vNFkUCS65m4/NS1Cw== Date: Wed, 19 Feb 2014 09:47:54 +0000 Message-ID: <6BAD559F-A526-4215-A566-9A21632AED08@cisco.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.70] Content-Type: text/plain; charset="Windows-1252" Content-ID: <94487ACD54F65C4AA0D06D89FCA59EA8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ZPd4njk9T6JCKGqmsk7-fJj-xwM Cc: "Muthu Arul Mozhi Perumal \(mperumal\)" , Oleg Moskalenko , Simon Perreault Subject: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 09:48:04 -0000 Hi, I like the idea of a bandwidth attribute telling the TURN server what to ex= pect from that particular allocation. Especially when it comes to allocatio= ns that carry for example RTCP, BFCP and other =93low chatter=94 data proto= cols. When it comes to more =93elastic=94 media protocols (video especially= ) a static bandwidth attribute can be a bit problematic. This is somewhat d= escribed in the draft that burst above the maximum should be expected. But = due to very good video encoding efficiency in for example a talking head on= ly scenario, the bandwidth usage may be significantly lower than the maximu= m bandwidth the agent signalled in the allocation message.=20 So how is this bandwidth attribute useful for the TURN server when signalle= d from the allocating agent? What can it do when the bandwidth is exceeded,= and when does it know that the bandwidth is exceeded? There might be diffe= rent network paths to the TURN server. One path may be congested well befor= e any TURN bandwidth is exceeded.=20 I am trying to argue that the possible choke point in the network is not ne= cessarily where the TURN server is placed, and that reduces the usefulness = of a bandwidth attribute in some scenarios. When it comes to draft-thomson-= tram-turn-bandwidth we must be careful to explain what problems it solves. = I am afraid that this attribute might be (miss?)used as a QoS solution on t= he entire media path.=20 One possible use case for this draft to solve is to get better pr session/c= all/?? bandwidth utilisation. If for example a user pays to get 3Mbit thro= ugh the TURN server. The users endpoint is capable of sending 1 audio and 3= video (Head, room and slides) streams and one BFCP stream. The agent needs= to do 9 allocations (4xRTP, 4xRTCP, 1xBFCP), 5 of those allocations are ve= ry low bandwidth. The agent itself knows best how to utilise the remaining = bandwidth, but how should we cope with changing needs. How do we signal; I = know that I have 3Mbit available, and I am dynamically going to use that ba= ndwidth over those 4 allocations, and by the way I have 5 more allocations = that only needs a packet sent now and then.. (And yes I know of BUNDLE, but= the media streams may not have the same src/dst IP) When it comes to DSCP and ECN, as Simon point out putting them in a STUN at= tribute would help getting the values transported unmangled over the Intern= et. This is especially important in this scenario as a NAT sitting between = the agent and the TURN server might ignore those bits when forwarding the p= ackets. The remaining problem with DSCP is that there is no strict defining= of what the bits actually means. Some definitions can be found in draft-dh= esikan-tsvwg-rtcweb-qos, but it is likely that different ISPs or networks w= ill use different values. As Muthu pointed out, this is essentially the mot= ivation for the draft-martinsen-tram-discuss draft. .-. P=E5l-Erik From nobody Wed Feb 19 03:21:37 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF0F1A058A for ; Wed, 19 Feb 2014 03:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 T3Toa_Z08WJC for ; Wed, 19 Feb 2014 03:21:27 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 290231A0466 for ; Wed, 19 Feb 2014 03:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=173271; q=dns/txt; s=iport; t=1392808883; x=1394018483; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HcQvKZB0UMFSEb8ms7YmNszMBM0yFHCNtW3HvkcwpTE=; b=YOMQpJXOdr1ArBvE2IhZIvLtusCgsIi8zrmjVi+6bAefaZDUoGlf/u2I 0klmhQi5GY3NiEW8XMEYCoh4Jz8CGiIAxDGPIZVV7VlUGmAyDqEg6r1v/ tX/tn1nlLmUEGIiPr7sSRB/ASr6Fmbco2wVeb0rW8SLboCwrs0gAgNfyN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4GALmSBFOtJV2Z/2dsb2JhbABPCoJCRDhXqjqMZYgHT4EcFnSCJQEBAQMBAQEBFwEMQAUCBAQDBQsCAQgRBAEBIQECBAchBgsUCQgCBAoEBQkSh1YDCQgNxSsNh34XjE+BKQoGBAEFAgEBLB0BBAYBBgODG4EUBIVYjm+BfYFsgTKLLIVGgW+BPoFoAQgXIg X-IronPort-AV: E=Sophos; i="4.97,505,1389744000"; d="scan'208,217"; a="21530304" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP; 19 Feb 2014 11:21:18 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1JBLIgr001669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 11:21:18 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 05:21:17 -0600 From: "Pal Martinsen (palmarti)" To: Karl Stahl Thread-Topic: QoS for RTC over the Internet, DISCUSS: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPK+GsGlWR8bzsTUukQ41JgJobVpq809cA Date: Wed, 19 Feb 2014 11:21:16 +0000 Message-ID: References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> <006701cf28af$9c2a27f0$d47e77d0$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A242AD996@xmb-rcd-x10.cisco.com> <03d901cf2be1$a4b78400$ee268c00$@stahl@intertex.se> In-Reply-To: <03d901cf2be1$a4b78400$ee268c00$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.70] Content-Type: multipart/alternative; boundary="_000_D5104301CDA8424894B9364F4FA3E5B9ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/vpx0of2aAFf9Da5lNgHuupc9Rpw Cc: "Dan Wing \(dwing\)" , "Tirumaleswar Reddy \(tireddy\)" , "tram@ietf.org" Subject: Re: [tram] QoS for RTC over the Internet, DISCUSS: Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 11:21:36 -0000 --_000_D5104301CDA8424894B9364F4FA3E5B9ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 17 Feb 2014, at 14:10 pm, Karl Stahl > wrote: Tiru > I did not did not understand how TURN server will identify if it=92s= WebRTC media streams or gaming traffic or some other data traffic relayed = through it to set the diffserv bits correctly ! --- I think you do understand=85 =96 but I will spell out that DISCUSS/MALI= CE does it better and with useful detail :) P=E5l, Tiru, Dan and you other thinking about these things: What has been discussed by me here so far, to give us quality of real-time = traffic over the Internet (not a small task) is: 1) To direct the real-time traffic to where the network can handle such tra= ffic (using a network offered TURN servers) (which is not within the scope = of DISCUSS) I can se the usefulness of a TURN server to OTT service providers that have= their own backhaul network to transport the packets. Using such a provider= might enable a user to avoid =93hot potato=94 routing problems that might = occur on the Internet. If you quickly want to get your packets into such a = OTT network service TURN is a good alternative. But, in such a scenario I w= ould like the ICE agent to actually be able to detect that this is the best= path. We currently miss a few bits to be able to do this. The discuss draf= t might help with some of that, but there are still bits missing. To me this is not a QoS feature, it is a way to avoid potential =93hot pota= to=94 routing problems. 2) When such a TURN server flow is allocated, it can ASSUME that it is goin= g to used for real-time traffic and instruct the network (e g via setting d= iffserve bits) to prioritize the assumed real-time traffic. (Giving the sam= e prioritization to all TURN traffic works quite well. =96 Only if we fill = the whole pipe with prioritized traffic (best effort totally pushed off) is= it important that e.g. voice if prioritized higher than video). I think to assume that TURN equals real-time traffic is wrong. It is a gene= ric relay service and should be treated like that. 3) When the TURN server sees the flow coming in (Note: in both directions) = it can do smarter guesswork of what traffic it is (like a DPI-box), e.g. wh= at is RTP and what is data channel to instruct the network better. Yes. The would be able to see most of the traffic and may make smart correl= ations. But again there is no guarantee in the future that the traffic will= be as symmetric as it is today. As long as you have set the permissions c= orrect, the TURN server would forward you the packets. Now after browsing http://tools.ietf.org/html/draft-martinsen-tram-discuss-= 00 4) DISCUSS transfers information directly from the application to the netwo= rk at the time of setup of the STUN or TURN(?) server, which it therefore c= an do with better detail and prediction. This is valuable, also for reservi= ng bandwidth in non diffserve networks like Cable and Mobile where one res= erves bandwidth rather than use diffserve for QoS. Yes. But the values are expected to change, so the network should be able to pic= k up any STUN messages carrying this information even after the sessions es= tablished. We want to limit the information exchange during the ICE connect= ivity check to a bare minimum, but still be able to possibly take smarter p= ath decisions once the connectivity checks are finished. Once the session i= s established some security can probably be relaxed and we have more time t= o actually signal more detailed information. 5) Isn=92t DISCUSS usable with TURN? Maybe even better! And it can be used = with 1) above :) You can transfer the same information in the TURN allocate request as in th= e STUN binding request, can=92t you?. I searched for =93TURN=94 in the DISC= USS draft, but could not see it spelled out. TURN is an extension to STUN, = so maybe it is just obvious? =96 I have not checked details in the specs so= P=E5l, Tiru or Dan knowing better, please confirm or correct! Yes. The discuss draft only defines a se of new STUN attributes. They can b= e used in any STUN/TURN message. But there are some interesting pitfalls though. TURN allocation messages ar= e sent during the ICE candidate discovery phase. Once the connectivity che= cks commences we will have some STUN Binding Request tunnelled over the all= ocation in Send and Data indication messages. Some thought should be done = on how the network element between the TURN agent and TURN server should tr= eat such messages if both of them contain some discuss attributes. (How = =93deep=94 should it search for STUN packets containing discuss attributes,= and what would they tell you) I will try to write something describing this in the next version of the di= scuss draft. Some observations: a. In DISCUSS using STUN, the network element doing the diffserv or reserva= tion settings WOULD be in the default gateway. b. In DISCUSS using TURN, the TURN server doing the diffserv or reservation= settings COULD be in the default gateway. (The auto-discovery of the TURN = server would simply point out the default gateway.) Sound very similar: Could not DISCUSS over TURN always be used? Sure discuss attributes can be used with TURN allocation and session refres= h messages to inform possible discuss aware network elements on that path w= hat is going on. c. With DISCUSS using TURN, the application would directly talk to the netw= ork device doing the diffserve settings etc. (instead of through it, where = typically the default gateway would snope that talk). Would that not easy s= ome of the concerns in the draft left for further discussion? Adding discuss attributes to TURN messages would help between the agent and= the TURN server. Those messages would not go end to end, and would not hel= p other network elements to =93do the right thing=94. This is useful, but a= limiting factor. d. Can we add info in the response? E.g. if the network device is only will= ing to give 1 Mbps instead of needed 3 Mbps, so the application can be info= rmed to reduce his video resolution? Would be a nice mechanism when RTC alo= ne starts filling our pipes. (I saw a similar idea by P=E5l in the previous= email I just commented.) There is a ECN like response in discuss that allows you to faster rate limi= t instead of waiting for the RTCP reports to do the trick. Reporting available bandwidth consistently from a network element is tricky= . It varies from device to device that it can report. Is it the entire down= link speed, or maximum bandwidth pr user/ip or pr application. If we can fi= gure out a consistent way to report that, it would be very useful to the IC= E state machine when choosing the path. 6) Please add to the DISCUSS draft that it also could reserve bandwidth in = bandwidth reservation type of networks like Cable and Mobile networks! We have on purpose avoided wording like reservation. It implies user authen= tication and that opens up another can of worms. But reusing some of the di= scuss attributes and adding functionality to do reservation in another draf= t makes sense. The discuss draft have a very limited scope. We want to keep it simple to i= mplement for both applications and network elements. If it brings any real = value needs more discussion. Hopefully those discussion can happen here in = TRAM. .-. P=E5l-Erik A few more things are needed for the ultimate goal, bringing end-to-end QoS= or QoE for real-time communication to Best Effort Internet (which does not= seem impossible, but quite doable now :) ) remains though. I=92ll come bac= k to those. It will e.g. relate to how to do with INCOMING traffic, especially in reser= vation type of networks, and the wild changing/stripping of diffserve bits = between ISPs. You may want to check this old discussion to see if this useful: http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html /Karl Fr=E5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Skickat: den 13 februari 2014 17:47 Till: Karl Stahl Kopia: tram@ietf.org =C4mne: RE: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server auto-= discovery mechanism for enterprise and ISPs Hi Karl, I did not understand how TURN server will identify if it=92s WebRTC media s= treams or gaming traffic or some other data traffic relayed through it to s= et the diffserv bits correctly ! -Tiru. From: Karl Stahl [mailto:karl.stahl@intertex.se] Sent: Thursday, February 13, 2014 5:05 PM To: Tirumaleswar Reddy (tireddy); 'Hutton, Andrew'; 'Justin Uberti'; Muthu = Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; 'Simon Perreault'; 'Oleg= Moskalenko'; tram@ietf.org; 'Marc Blanchet'; Dan Win= g (dwing) Subject: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server auto-dis= covery mechanism for enterprise and ISPs On the side of this TRAM-list, I also got this question: > Regarding the enterprise case, I am not sure I follow your argument. > Do you mean that by setting up an enterprise TURN server, and open the fi= rewall for media over UDP from/to TURN server be the solution? ---- As we all realize, that would of course not help or improve things The intended solution in the enterprise case has not yet been spelled out i= n this TRAM-list discussion, so for better understanding, let me copy a few= things from the discussion in September/October on the RTCWEB-list and wha= t is (since long) spelled out in the draft-ietf-rtcweb-use-cases-and-requir= ements. For better understanding, I also want to point out that a TURN can have two= interfaces (acting like a router for media between different networks). Th= is allows to easier understand that can TURN servers can direct a best medi= a path (rather than just thinking that a TURN service is a device which med= ia just bounces against at one interface). And, we can also hope for that a TURN server becomes a (common) component o= f a firewall, which would allow the firewall to understand that the media d= irected to it is RTC and should be prioritized whereby the firewall can tra= ffic shaped (back-off data traffic that may be filling its Internet pipe) a= s well as e.g. set diffserve bits or take other measures to assist proper q= uality handling thought the network. (These are common mechanisms available= and used in firewalls/NATs/access routers, but TURN servers are not yet in= cluded such devices.) The same goes for access routers/default gateways, DP= Is in the transport network itself =96 TURN servers included in such points= were media can pass and quality measures applied may/will be very useful t= o get us WebRTC media with through networks without quality destruction. >From the RTCWEB mailing list September 20th (by me): An enterprise network that want to keep a restrictive firewall not allowing= UDP traffic, could provide a real-time path using a TURN server parallelin= g the firewall, instead of tunneling RTP through always open http or https = ports resulting in RTP media over TCP =96 with severe quality problems from= TCP retransmissions of dropped packets. The TURN server address is most ea= sily provided in the same way as the IP address and DNS address. (That woul= d also put the right party in control =96 The network provider (here the en= terprise) decides what is allowed on his network.) The browser should select which available TURN server address to use in the= following priority order, where ICE could be used to try several: 1) TURN server address configured in the browser by the user (special cases= , normally not used) 2) TURN server address configured by the network administrator via an =93ad= min policy template=94 3) TURN server address supplied by DHCP or similar automatic network method 4) TURN server address being supplied by the web application" And from yesterdays(!) http://tools.ietf.org/html/draft-ietf-rtcweb-use-cas= es-and-requirements-14 these enterprise things and necessity are spelled ou= t in: F19 The browser must be able to use several STUN and TURN servers ---------------------------------------------------------------- A22 3.3.5. Simple Video Communication Service, enterprise aspec= ts 3.3.5.1. Description This use-case is similar to the Simple Video Communication Service use-case (Section 3.3.1). What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use-case. An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application sessions used from inside the company towards any external peer. To be able to do this they deploy a TURN server that straddles the boundary between the internal and the external network. The firewall will block all attempts to use STUN with an external destination unless they go to the enterprise auditing TURN server. In cases where employees are using RTCWEB applications provided by an external service provider they still want the traffic to stay inside their internal network and in addition not load the straddling TURN server, thus they deploy a STUN server allowing the RTCWEB client to determine its server reflexive address on the internal side. Thus enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possible to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to achieve by auto-configuration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. 3.3.5.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F20 The browser must support the use of STUN and TURN servers that are supplied by entities other than the web application (i.e. the network provider). ---------------------------------------------------------------- There are further requirement listed, helping us to understand the need for= auto discovery and a network provided TURN-server should be used to ENFORC= E that media takes that path (and thus, other paths e.g. suggested by the r= emote MUST not happen to be used). This is related to the mobility aspect (= valid even without the roaming idea): 3.3.6. Simple Video Communication Service, access change 3.3.6.1. Description This use-case is almost identical to the Simple Video Communication Service use-case (Section 3.3.1). The difference is that the user changes network access during the session. The communication device used by one of the users has several network adapters (Ethernet, WiFi, Cellular). The communication device is accessing the Internet using Ethernet, but the user has to start a trip during the session. The communication device automatically changes to use WiFi when the Ethernet cable is removed and then moves to cellular access to the Internet when moving out of WiFi coverage. The session continues even though the access method changes. 3.3.6.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- 3.3.7. Simple Video Communication Service, QoS 3.3.7.1. Description This use-case is almost identical to the Simple Video Communication Service, access change use-case (Section 3.3.6). The use of Quality of Service (QoS) cap= abilities is added: The user in the previous use case that starts a trip is behind a common residential router that supports prioritization of traffic. In addition, the user's provider of cellular access has QoS support enabled. The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular. 3.3.7.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- F22 The browser must be able to receive streams and data from multiple peers concurrently. ---------------------------------------------------------------- Further from the RTCWEB mailing list September 20th (by me): There are several reasons for a network service provider to supply a TURN s= erver as part of his offered access: - to keep media paths short, specifically not sending media outside its own= network to some distant application provided TURN server - to support mobility, i.e. you may want to move from a LAN with a configur= ed TURN server to accessing via WiFi or 3G/4G OTT channels - to offer a media path with better quality (than best effort data traffic)= . Getting =93WebRTC-ready=94 access and we look forward to telepresence for e= veryone. I hope this (a bit lengthy) summary of already thought-out and discussed as= pects/requirements will help us understand that the auto-discovered TURN se= rver is an ORDER from the enterprise and/or the NSP/ISP to send the media = through this TURN path, and that other media paths that may exist MUST NOT = BE USED. (That is why we especially have to watch/advice that workable medi= a paths proposed by the remote party not becomes used =93by accident=94. /Karl Fr=E5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] Skickat: den 13 februari 2014 04:37 Till: Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Kopia: tireddy@icisco.com; Simon Perreault; Oleg= Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing (= dwing); Karl Stahl =C4mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for en= terprise and ISPs Hi Andy, There are other ways to solve the problem for example using PCP. Can you cl= arify how deploying a TURN server in the Enterprise protects the users and = the network ? -Tiru. From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Thursday, February 13, 2014 1:00 AM To: Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; Oleg Mo= skalenko; tram@ietf.org; Marc Blanchet; Dan Wing (dwi= ng); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for e= nterprise and ISPs The case where the TURN server is the only option may become common within = enterprise networks and that might be deliberate enterprise policy because = it provides the better path (UDP through the F/W) and protects the users an= d the network. Andy From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 12 February 2014 17:46 To: Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; Oleg Mo= skalenko; tram@ietf.org; Marc Blanchet; Dan Wing (dwi= ng); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for e= nterprise and ISPs Agree. If TURN is indeed being provided for the user's benefit, the client'= s ICE logic (based on RTT or similar) should result in it preferring the TU= RN path. On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) > wrote: Yes, I believe the second case is rare, but would be better than a rat race= b/w administrators trying to block p2p traffic and force it through a TURN= server and apps/endpoints finding smarter ways to bypass them. Muthu From: Oleg Moskalenko [mailto:mom040267@gmail.com] Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Si= mon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for e= nterprise and ISPs The TURN server has to be used when it is either the only option, or if it = provides a better path (I guess the second case is rather rare). On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) > wrote: +1 Forcing all traffic through a TURN server and expecting it would provide th= e best user experience doesn't look the right approach. Instead, if a path = through a TURN server exists and does provide lower RTT, jitter etc, being = able to detect and use (or switch to) that path might be desirable.. Muthu From: tram [mailto:tram-bounces@ietf.org] On = Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf= .org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for e= nterprise and ISPs Inline. On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl > wrote: Listening to this thread, I am afraid we are missing the very point and nec= essity for this milestone! - There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the tu= rn client (the WebRTC browser) There are ways, not only: Enterprises or ISPs wishing to provide their own = TURN server, in an attempt to reduce so-called "triangle routing",need a ne= w auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path where t= he bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for pri= oritized RTC (Real Time Communication) traffic. - Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete with d= ata traffic. Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own optimal T= URN server This leads us into =93TURN=85to identify WebRTC flows=94 etc! It is not a = mistake, but the very need for this milestone! Again, it has not been demonstrated why TURN is the right technology here, = compared to a more transparent flow identification tool like MALICE. We don= 't force all HTTP requests to locate a HTTP proxy via anycast, I don't see = why we need to do the same for WebRTC. What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong tech= nology to solve the problem It is correct that ICE/STUN/TURN was designed to address the NAT/Firewall t= raversal problem associated with real-time communication (SIP at that time)= . However, its largest flaw/problem is that quality things were not (could = not be?) considered. The method=92s very idea (like all similar methods for= getting RTC through ordinary NAT/Firewalls) is to fool the media through a= NAT/Firewall that is unaware of what is happening. Thus, this is root of q= uality issues (and bandwidth allocation optimization) that needs to be deal= t with: Real-time traffic fighting with a data traffic crowded congestion p= oint. I think that "fooling" is an incorrect description. The NAT is supposed to = be transparent to the client. But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate req= uest for a suitable pipe for quality demanding real time traffic. :) ICE is a pre-protocol you use because you want a path for real-time media b= etween parties. Here: The browser says knock knock, I want to get media thr= ough (and of course with as good quality as required and possible). If the NAT/Firewall owner and network owner are allowed to see these reques= ts, they can help/assist in achieving the good media path. If they are not = aware, they cannot help! Hope this made it understandable on an overview level how this can become = =93TURN=85to identify WebRTC flows=94 It is also the ONLY way I can see to achieve what we want to achieve and sh= ould be the aim and requirement of this milestone. I am talking about general usage of WebRTC over Internet/mobile OTT (not fe= eding WebRTC into application specific networks like IMS where other method= s may exist). This is good, not evil! If the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues =93because it is all about bandwidt= h=94, =93it will resolve itself with time=94 etc., I strongly object! That = is wrong and will be very detrimental for WebRTC usage. We already see it a= nd I can give numerous examples of how much less quality demanding VoIP is/= is not handled quality wise and that it matters. And, what would be bad con= sidering quality issues and allowing/encouraging methods to deal with them? If the hesitations are raised, because of suspicion that the methods we may= recommend may be misused to stop/block/destroy WebRTC usage (e.g. to prote= ct income from carrier telephony traffic), I could understand and would fig= ht the same battle. But hopefully, those days are (soon) over =96 At least = forward thinking carrier=92s realize that already. Web RTC will happen. Whi= ch customers want to pay for an access with blocked WebRTC? The carrier=92s= offering/assuring good WebRTC will rather get the customers and income :).= (Maybe the Web browser can detect and encourage this=85) If there are technical concerns of bad result, or better methods allowing n= etwork providers and LAN managers to offer and inform the browser that ther= e are good media paths to be used, and that the web browser automatically c= an chose those, then let us all understand those, so we can achieve what sh= ould be achieved by this milestone. Skype, Hangouts, Facetime are doing billions of minutes per week and the In= ternet has not melted yet. If we need to do flow identification to allow tr= affic to be prioritized, fine (see above regarding my preferred approach), = but forcing all WebRTC traffic through a MITM (TURN server) is a much bigge= r jump that I don't yet see the justification for. In short: TURN is a technology that is supposed to fade away with the move = to IPv6. I don't think we want to make it a critical element of WebRTC. /Karl Fr=E5n: Dan Wing [mailto:dwing@cisco.com] Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; Karl S= tahl; tram@ietf.org; Simon Perreault =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for en= terprise and ISPs On Feb 11, 2014, at 9:08 AM, Marc Blanchet > wrote: Le 2014-02-11 =E0 00:39, Dan Wing >= a =E9crit : On Feb 10, 2014, at 5:30 PM, Justin Uberti > wrote: Good to see there is a lot of interest for this milestone. But based on the= description here, it seems like we want to use TURN primarily to identify = WebRTC flows, as opposed to using it as a NAT traversal tool. This makes me= concerned that we may be using the wrong technology to solve the problem. +1. I would prefer allowing flows to establish themselves using their 'best' pa= th, and the best path is seldom through a TURN server. When we imagine IPv= 6 in our future, we don't want to force an application-level proxy (TURN) s= erver on the path solely for traversing an IPv6 firewall. It seems this thread is conflating all the possible reasons / justification= s for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping NAT= s) * firewall traversal (firewall blocks UDP) * enhancing privacy Unfortunately the TURN server nor the endpoint really know which of those u= se-cases is desired (by the user or by the IT network administrator) or nec= essary (for the call to work at all). Dan, while I agree in principle, I doubt that a user could ever say "I want= mobility or I want NAT traversal". I think the user only want the call to = succeed, whatever the properties of its network point of attachment are. So what can we do? Should the TURN server provide any and all services the= TURN client might possibly want, as that is what a robust TURN server will= do, and the endpoint should prefer TURN candidates over all others because= there might be some functionality / usefulness of TURN that the user might= gain through TURN (e.g., enhanced privacy)? -d This seems problematic. Perhaps we need a way to signal the desired use-c= ase ("trait"), or as Justin suggests, using a different technology for some= of these use-cases. -d On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl > wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto:tram-bounces@ietf.org] F= =F6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for en= terprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =E9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =93automatically=94 does this.) I understand the STUN vs TURN priority issue. But I don't see how anycast a= ffects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is pro= vided and discovered, CURRENT usage of ICE may suggest a candidate from the= remote party that will make a connection without the need/usage of the TUR= N server (that we wanted to be used for the good purposes listed). The only way we found around this, was to stop STUN through the IP default = gateway (like a restrictive Enterprise firewall does inhibiting ICE connect= ivity, which others are concerned about...). Since the provisioning of auto= -discovery using the anycast mechanism, would be adding a route in a defaul= t gateway, adding a firewall rule to eat STUN packets would assure that the= provisioned TURN server actually becomes used (and not bypassed "by accide= nt"). (That was the thought behind the =93automatically=94 within quotes.) BUT, since you brought up the question, assuming that we have the power to = enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-di= scovered TURN server instead of STUN, would solve the same problem. However= , thinking further (in relation to your next question - "anyone could set u= p a badly-maintained" - enforcing such ICE usage may not be good.) > - 3^rd The Anycast method below =96 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =96 The anycast discovered TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would this = not be subject to the same service quality issues that plagued 6to4? That i= s, anyone could set up a badly-maintained, under-provisioned TURN server an= d announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can we = prevent triangle routing? There is nothing guaranteeing that the anycast se= rver you see is being provided to you by your ISP, rather than a server sit= ting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready answer= ... An auto-discovered TURN server must be trusted (whatever method it is disco= vered by). We are trusting the one providing us with an IP address and defa= ult gateway anyway. It would be easy if we could reuse that trust, instead = of another mechanisms. Is there a good way for the browser to check that the anycast address is no= t handled beyond the network service provider's default gateway? Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_D5104301CDA8424894B9364F4FA3E5B9ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5BAB483CE65E3744B1BF7A1FC73DC9EF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 17 Feb 2014, at 14:10 pm, Karl Stahl <karl.stahl@intertex.se> wrote:

Tiru > I did not did not understand how = TURN server will identify if it=92s WebRTC media streams or gaming traffic = or some other data traffic relayed through it to set the diffserv bits correctly !
--- I think you do understand=85 =96 but I will spell out= that DISCUSS/MALICE does it better and with useful detail J  
P=E5l, Tiru, Dan and you other thinking about these thing= s:
 
What has been discussed by me here so far, to give us qua= lity of real-time traffic over the Internet (not a small task) is:
 
1) To direct the real-time traffic to where the network c= an handle such traffic (using a network offered TURN servers) (which is not= within the scope of DISCUSS)
 
I can se the usefulness of a TURN server to OTT service providers that= have their own backhaul network to transport the packets. Using such a pro= vider might enable a user to avoid =93hot potato=94 routing problems that m= ight occur on the Internet. If you quickly want to get your packets into such a OTT network service TURN is a good al= ternative. But, in such a scenario I would like the ICE agent to actually b= e able to detect that this is the best path. We currently miss a few bits t= o be able to do this. The discuss draft might help with some of that, but there are still bits missing.

To me this is not a QoS feature, it is a way to avoid potential =93hot= potato=94 routing problems. 

2) When such a TURN server flow is allocated, it can ASSU= ME that it is going to used for real-time traffic and instruct the network = (e g via setting diffserve bits) to prioritize the assumed real-time traffic. (Giving the same prioritization = to all TURN traffic works quite well. =96 Only if we fill the whole pipe wi= th prioritized traffic (best effort totally pushed off) is it important tha= t e.g. voice if prioritized higher than video).

I think to assume that TURN equals real-time traffic is wrong. It is a= generic relay service and should be treated like that. 

 
3) When the TURN server sees the flow coming in (Note: in= both directions) it can do smarter guesswork of what traffic it is (like a= DPI-box), e.g. what is RTP and what is data channel to instruct the network better.
 
Yes. The would be able to see most of the traffic and may make smart c= orrelations. But again there is no guarantee in the future that the traffic= will be as symmetric as it is today.  As long as you have set the per= missions correct, the TURN server would forward you the packets.

 
4) DISCUSS transfers information directly from the applic= ation to the network at the time of setup of the STUN or TURN(?) server, wh= ich it therefore can do with better detail and prediction. This is valuable, also for reserving bandwidth in n= on diffserve networks like Cable and  Mobile where one reserves bandwi= dth rather than use diffserve for QoS.
Yes.

But the values are expected to change, so the network should be able t= o pick up any STUN messages carrying this information even after the sessio= ns established. We want to limit the information exchange during the ICE co= nnectivity check to a bare minimum, but still be able to possibly take smarter path decisions once the connect= ivity checks are finished. Once the session is established some security ca= n probably be relaxed and we have more time to actually signal more detaile= d information. 

 
5) Isn=92t DISCUSS usable with TURN? Maybe even better! A= nd it can be used with 1) above = J
You can transfer the same information in the TURN allocat= e request as in the STUN binding request, can=92t you?. I searched for =93T= URN=94 in the DISCUSS draft, but could not see it spelled out. TURN is an extension to STUN, so maybe it is just obvi= ous? =96 I have not checked details in the specs so P=E5l, Tiru or Dan know= ing better, please confirm or correct!
 
Yes. The discuss draft only defines a se of new STUN attributes. They = can be used in any STUN/TURN message.

But there are some interesting pitfalls though. TURN allocation messag= es are sent during the ICE candidate discovery phase.  Once the connec= tivity checks commences we will have some STUN Binding Request tunnelled ov= er the allocation in Send and Data indication messages.  Some thought should be done on how the network element bet= ween the TURN agent and TURN server should treat such messages if both of t= hem contain some discuss attributes.  (How =93deep=94 should it search= for STUN packets containing discuss attributes, and what would they tell you)

I will try to write something describing this in the next version of t= he discuss draft. 

Some observations:
 
a. In DISCUSS using STUN, the network element doing the d= iffserv or reservation settings WOULD be in the default gateway.=
b. In DISCUSS using TURN, the TURN server doing the diffs= erv or reservation settings COULD be in the default gateway. (The auto-disc= overy of the TURN server would simply point out the default gateway.)
 
Sound very similar: Could not DISCUSS over TURN always be= used?
 
Sure discuss attributes can be used with TURN allocation and session r= efresh messages to inform possible discuss aware network elements on that p= ath what is going on. 

c. With DISCUSS using TURN, the application would directl= y talk to the network device doing the diffserve settings etc. (instead of = through it, where typically the default gateway would snope that talk). Would that not easy some of the concerns i= n the draft left for further discussion?
 
Adding discuss attributes to TURN messages would help between the agen= t and the TURN server. Those messages would not go end to end, and would no= t help other network elements to =93do the right thing=94. This is useful, = but a limiting factor. 

d. Can we add info in the response? E.g. if the network d= evice is only willing to give 1 Mbps instead of needed 3 Mbps, so the appli= cation can be informed to reduce his video resolution? Would be a nice mechanism when RTC alone starts filling = our pipes. (I saw a similar idea by P=E5l in the previous email I just comm= ented.)
 
There is a ECN like response in discuss that allows you to faster rate= limit instead of waiting for the RTCP reports to do the trick. 

Reporting available bandwidth consistently from a network element is t= ricky. It varies from device to device that it can report. Is it the entire= downlink speed, or maximum bandwidth pr user/ip or pr application. If we c= an figure out a consistent way to report that, it would be very useful to the ICE state machine when choosin= g the path. 

 
6) Please add to the DISCUSS draft that it also could res= erve bandwidth in bandwidth reservation type of networks like Cable and &nb= sp;Mobile networks!
 
We have on purpose avoided wording like reservation. It implies user a= uthentication and that opens up another can of worms. But reusing some of t= he discuss attributes and adding functionality to do reservation in another= draft makes sense. 

The discuss draft have a very limited scope. We want to keep it simple= to implement for both applications and network elements. If it brings any = real value needs more discussion. Hopefully those discussion can happen her= e in TRAM.
.-.
P=E5l-Erik

 
A few more things are needed for the ultimate goal, bringing end-to-end QoS or QoE for real-time communication to Best Effort Internet (which does= not seem impossible, but quite doable now J ) remains though. I=92ll come back to those.
 
It will e.g. relate to how to do with INCOMING traffic, e= specially in reservation type of networks, and the wild changing/stripping = of diffserve bits between ISPs.
 
You may want to check this old discussion to see if this = useful:
 
/Karl
 
 
Fr=E5n:&nbs= p;Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.= com] 
Skickat: den 13 fe= bruari 2014 17:47
Till: Karl Stahl Kopia: = tram@ietf.org
=C4mne: RE: IMPORT= ANT CLARIFICATIONS: [tram] Milestone 3: TURN server auto-discovery mechanis= m for enterprise and ISPs
 
Hi Karl,
 
I did not understand how TURN server will i= dentify if it=92s WebRTC media streams or gaming traffic or some other data= traffic relayed through it to set the diffserv bits correctly !
 
-Tiru.
From: = Karl Stahl [mailto:karl.stahl@intertex.se] 
Sent: Thursday, Fe= bruary 13, 2014 5:05 PM
To: Tirumaleswar R= eddy (tireddy); 'Hutton, Andrew'; 'Justin Uberti'; Muthu Arul Mozhi Perumal= (mperumal)
Cc:  tram@ietf.org; 'Marc Blanchet'; Dan Wing (dwing)
Subject: IMPORTANT= CLARIFICATIONS: [tram] Milestone 3: TURN server auto-discovery mechanism f= or enterprise and ISPs
 
On the side of this TRAM-list, I also got this question:<= o:p>
> Regarding the = enterprise case, I am not sure I follow your argument.
> Do you mean th= at by setting up an enterprise TURN server, and open the firewall for media= over UDP from/to TURN server be the solution?
---- As we all realize, that would of course not help or = improve things
 
The intended solution in the enterprise case has not yet = been spelled out in this TRAM-list discussion, so for better understanding,= let me copy a few things from the discussion in September/October on the RTCWEB-list and what is (since long) spelled o= ut in the draft-ietf-rtcweb-use-cases-and-requirements.
 
For better understanding, I also want to point out that a= TURN can have two interfaces (acting like a router for media between diffe= rent networks). This allows to easier understand that can TURN servers can direct a best media path (rather than= just thinking that a TURN service is a device which media just bounces aga= inst at one interface).
 
And, we can also hope for that a TURN server becomes a (c= ommon) component of a firewall, which would allow the firewall to understan= d that the media directed to it is RTC and should be prioritized whereby the firewall can traffic shaped (back-of= f data traffic that may be filling its Internet pipe) as well as e.g. set d= iffserve bits or take other measures to assist proper quality handling thou= ght the network. (These are common mechanisms available and used in firewalls/NATs/access routers, but TURN s= ervers are not yet included such devices.) The same goes for access routers= /default gateways, DPIs in the transport network itself =96 TURN servers in= cluded in such points were media can pass and quality measures applied may/will be very useful to get us WebRTC= media with through networks without quality destruction.=
 
From the RTCWEB mailing list September 20th (by me):<= /div>
An= enterprise network that want to keep a restrictive firewall not allowing U= DP traffic, could provide a real-time path using a TURN server paralleling = the firewall, instead of tunneling RTP through always open http or https ports resulting in RTP media over TCP = =96 with severe quality problems from TCP retransmissions of dropped packet= s. The TURN server address is most easily provided in the same way as the I= P address and DNS address. (That would also put the right party in control =96 The network provider (here the ent= erprise) decides what is allowed on his network.)
&n= bsp;
Th= e browser should select which available TURN server address to use in the f= ollowing priority order, where ICE could be used to try several:=
&n= bsp;
1)= TURN server address configured in the browser by the user (special cases, = normally not used)
2)= TURN server address configured by the network administrator via an =93admi= n policy template=94
3)= TURN server address supplied by DHCP or similar automatic network method
4)= TURN server address being supplied by the web application"=
 
 
And from yesterdays(!) http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requiremen= ts-14 these enterprise things and necessity are spelled out in:
 
F19  &nbs= p;  The browser must be able to use several STUN and TURN servers=
   ------= ----------------------------------------------------------
 
A22
3.3.5.  Simple Video Communication Service, enterprise aspects
3.3.5.1.  Description
   This u= se-case is similar to the Simple Video Communication Service
   use-ca= se (Section 3.3.1).
 
   What i= s added is aspects when using the service in enterprises.  ICE
   is ass= umed in the further description of this use-case.
 
   An ent= erprise that uses a RTCWEB based web application for
   commun= ication desires to audit all RTCWEB based application sessions
   used f= rom inside the company towards any external peer.  To be able
   to do = this they deploy a TURN server that straddles the boundary
   betwee= n the internal and the external network.
 
   The fi= rewall will block all attempts to use STUN with an external
   destin= ation unless they go to the enterprise auditing TURN server.
   In cas= es where employees are using RTCWEB applications provided by an<= /span>
   extern= al service provider they still want the traffic to stay inside
   their = internal network and in addition not load the straddling TURN
   server= , thus they deploy a STUN server allowing the RTCWEB client to
   determ= ine its server reflexive address on the internal side.  Thus
   enabli= ng cases where peers are both on the internal side to connect
   withou= t the traffic leaving the internal network.  It must be
   possib= le to configure the browsers used in the enterprise with<= /div>
   networ= k specific STUN and TURN servers.  This should be possible to
  achieve= by auto-configuration methods.  The RTCWEB functionality will
   need t= o utilize both network specific STUN and TURN resources and
   STUN a= nd TURN servers provisioned by the web application.
3.3.5.2.  Additional Requirements
   ------= ----------------------------------------------------------
   REQ-ID=       DESCRIPTION
   ------= ----------------------------------------------------------
   F20&nb= sp;    The browser must support the use of STUN and TURN
   &= nbsp;       servers that are supplied by enti= ties other than
   &= nbsp;       the web application (i.e. the net= work provider).
   ------= ----------------------------------------------------------
 
There are further requirement listed, helping us to under= stand the need for auto discovery and a network provided TURN-server should= be used to ENFORCE that media takes that path (and thus, other paths e.g. suggested by the remote MUST not hap= pen to be used). This is related to the mobility aspect (valid even without= the roaming idea):

3.3.6.  Simple Video Communication Service, access change

.=   Description
   This use-case is almost identica=
l to the
   Simple Video Communication Servi=
ce use-case (Section 3.3.1).  The
   difference is that the user chan=
ges network access during the
   session.
 
   The communication device used by=
 one of the users has several network
   adapters (Ethernet, WiFi, Cellul=
ar).  The communication device is
   accessing the Internet using Eth=
ernet, but the user has to start a
   trip during the session.  T=
he communication device automatically
   changes to use WiFi when the Eth=
ernet cable is removed and then moves
   to cellular access to the Intern=
et when moving out of WiFi coverage.
   The session continues even thoug=
h the access method changes.
.=   Additional Requirements
   --------------------------------=
--------------------------------
   REQ-ID    &n=
bsp; DESCRIPTION
   --------------------------------=
--------------------------------
   F17     The =
communication session must survive across a
       &nb=
sp;   change of the network interface used by the
       &nb=
sp;   session
   --------------------------------=
--------------------------------

3.3.7.  Simple Video Communication Service, QoS

.=   Description
   This use-case is almost identica=
l to the
   Simple Video Communication Servi=
ce, access change use-case
   (Section 3.3.6).  T=
he use of Quality of Service (QoS) capabilities is
   added:
 
   The user in the previous use cas=
e that starts a trip is behind a
   common residential router that s=
upports prioritization of traffic.
   In addition, the user's provider=
 of cellular access has QoS support
   enabled.  The user is able =
to take advantage of the QoS support both
   when accessing via the residenti=
al router and when using cellular.
.=   Additional Requirements
   --------------------------------=
--------------------------------
   REQ-ID    &n=
bsp; DESCRIPTION
   --------------------------------=
--------------------------------
   F17     The =
communication session must survive across a
        &n=
bsp;  change of the network interface used by the
       &nb=
sp;   session
   --------------------------------=
--------------------------------
   F22     The =
browser must be able to receive streams and
       &nb=
sp;   data from multiple peers concurrently.

   --------------------------------=
--------------------------------



 



Further from the RTCWEB mailing list September 20th<=
/sup> (by me):=




 



Th=
ere are several reasons for a network service provider to supply a TURN ser=
ver as part of his offered access:



- =
to keep media paths short, specifically not sending media outside its own n=
etwork to some distant application provided TURN server


- =
to support mobility, i.e. you may want to move from a LAN with a configured=
 TURN server to accessing via WiFi or 3G/4G OTT channels<=
/div>


- =
to offer a media path with better quality (than best effort data traffic).<=
o:p>



Ge=
tting =93WebRTC-ready=94 access and we look forward to telepresence for eve=
ryone.



 



 



I hope this (a bit lengthy) summary of already thought-ou=
t and discussed aspects/requirements will help us understand that the auto-=
discovered TURN server is an ORDER from
 the enterprise and/or the NSP/ISP  to send the media through this TUR=
N path, and that other media paths that may exist MUST NOT BE USED. (That i=
s why we especially have to watch/advice that workable media paths proposed=
 by the remote party not becomes used
 =93by accident=94.



 



/Karl



 



 







Fr=E5n:&nbs=
p;Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.=
com] 

Skickat: den 13 fe=
bruari 2014 04:37

Till: Hutton, Andr=
ew; Justin Uberti; Muthu Arul Mozhi Perumal (mperumal)

Kopia: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org;
 Marc Blanchet; Dan Wing (dwing); Karl Stahl

=C4mne: RE: [tram]=
 Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs<=
o:p>







 



Hi Andy,



 



There are other ways to solve the problem f=
or example using PCP. Can you clarify how deploying a TURN server in the En=
terprise protects the users and the
 network ?



 



-Tiru.









From: =
tram [mailto:tram-bounces@ietf.org] On
 Behalf Of Hutton, An=
drew

Sent: Thursday, Fe=
bruary 13, 2014 1:00 AM

To: Justin Uberti;=
 Muthu Arul Mozhi Perumal (mperumal)

Cc:  tram@ietf.org;
 Marc Blanchet; Dan Wing (dwing); Karl Stahl

Subject: Re: [tram=
] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs=








 



The case where the TURN server is the only =
option may become common within enterprise networks and that might be delib=
erate enterprise policy because it provides
 the better path (UDP through the F/W) and protects the users and the netwo=
rk.



 



Andy



 



 









From: =
tram [mailto:tram-bounces@ietf=
.org] On
 Behalf Of Justin Ube=
rti

Sent: 12 February =
2014 17:46

To: Muthu Arul Moz=
hi Perumal (mperumal)

Cc: tireddy@icisco.com;
 Simon Perreault; Oleg Moskalenko;&nb=
sp;tram@ietf.org Re: [tram=
] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs=








 





Agree. If TURN is indeed being provided for the user's=
 benefit, the client's ICE logic (based on RTT or similar) should result in=
 it preferring the TURN path.







 





On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Peru=
mal (mperumal) <mperumal@cisco.com=
> wrote:





Yes, I believe the second case is rare, but would be better than a rat rac=
e b/w administrators trying to block p2p traffic and force it through a TUR=
N server and apps/endpoints finding
 smarter ways to bypass them.=




 



Muthu



 









From: =
Oleg Moskalenko [mailto:mom040267@gmail.com] 

Sent: Wednesday, F=
ebruary 12, 2014 1:07 PM

To: Muthu Arul Moz=
hi Perumal (mperumal)

Cc: Justin Uberti;=
 Karl Stahl; tireddy@icisco.com;
 Marc Blanchet; tram@ietf.org;
 Dan Wing (dwing); Simon Perreault







Subject: Re: [tram=
] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs=












 





The TURN server has to be used when it is either the o=
nly option, or if it provides a better path (I guess the second case is rat=
her rare).





 





On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Per=
umal (mperumal) <mperumal@cisco.com> wrote:





+1



 



Forcing all traffic through a TURN server and expecting it would provide t=
he best user experience doesn't look the right approach. Instead, if a path=
 through a TURN server exists and does
 provide lower RTT, jitter etc, being able to detect and use (or switch to)=
 that path might be desirable..



 



Muthu



 









From: =
tram [mailto:tram-bounces@ietf.org] On
 Behalf Of Justin Ube=
rti

Sent: Wednesday, F=
ebruary 12, 2014 11:43 AM

To: Karl Stahl

Cc: tireddy@icisco.com=
;
 Marc Blanchet; tram@ietf.org;
 Dan Wing (dwing); Simon Perreault

Subject: Re: [tram=
] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs=










 





Inline.





 





On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> wrote:<=
/o:p>





Listening to this thread, I am afraid we are missing the =
very point and necessity for this milestone!



- There are severe NAT traversal and quality issues that =
should and can be dealt with by a good auto-discovery mechanism and the rig=
ht usage by the turn client (the WebRTC
 browser)



 


There are ways, not only: Enterprises or ISPs
 wishing to provide their own TURN server, in an attempt to reduce so-calle=
d "triangle routing",need a new auto-discovery mechanism



But also: - NSPs (Network Service Providers) want to prov=
ide a path where the bandwidth of WebRTC is better coped with.





- NSPs or Enterprises want to offer an Internet access qu=
ality pipe for prioritized RTC (Real Time Communication) traffic.



- Enterprises having restrictive firewalls, want to provi=
de a UDP-path for WebRTC and possibly also for better quality where RTC do =
not compete with data traffic.





Also considering





- Mobility; It is common to move from a LAN to accessing =
via WiFi or 3G/4G OTT channels, all should be able to automatically offer t=
heir own optimal TURN server<=
/div>


 




This leads us into&=
nbsp; =93TURN=85to identify WebRTC
 flows=94 etc! It is not a mistake, but the very need for this mileston=
e!







 







Again, it has not been demonstrated why TURN is the ri=
ght technology here, compared to a more transparent flow identification too=
l like MALICE. We don't force all HTTP requests to locate a HTTP proxy via =
anycast, I don't see why we need to
 do the same for WebRTC. 







 


What are the hesitations raised here?





> TURN primarily to identify WebRTC flows, as opposed to using i=
t as a NAT traversal tool. This makes me concerned that we may be using the=
 wrong technology to solve the problem





It is correct that ICE/STUN/TURN was designed to address =
the NAT/Firewall traversal problem associated with real-time communication =
(SIP at that time). However, its largest
 flaw/problem is that quality things were not (could not be?) considered. T=
he method=92s very idea (like all similar methods for getting RTC through o=
rdinary NAT/Firewalls) is to fool the media through a NAT/Firewall that is =
unaware of what is happening. Thus,
 this is root of quality issues (and bandwidth allocation optimization) tha=
t needs to be dealt with: Real-time traffic fighting with a data traffic cr=
owded congestion point.







 







I think that "fooling" is an incorrect descr=
iption. The NAT is supposed to be transparent to the client.







 


But, a BLESSING of ICE/STUN/TURN is that it can be seen a=
s a legitimate request for a suitable pipe for quality demanding real time =
traffic. J


ICE is a pre-protocol you use because you want a path for=
 real-time media between parties. Here: The browser says knock knock, I wan=
t to get media through (and of course
 with as good quality as required and possible).



 


If the NAT/Firewall owner and network owner are allowed t=
o see these requests, they can help/assist in achieving the good media path=
. If they are not aware, they cannot
 help!







 


Hope this made it understandable on an overview level how=
 this can become =
=93TURN=85to
 identify WebRTC flows=94


It is also the ONLY way I can see to achieve what we want=
 to achieve and should be the aim and requirement of this milestone.=




 


I am talking about general usage of WebRTC over Internet/=
mobile OTT (not feeding WebRTC into application specific networks like IMS =
where other methods may exist).



 


This is good, not evil!<=
/o:p>



 


If the hesitations are raised because of a belief/hope/wi=
sh that there are no or will not be severe quality issues =93because it is =
all about bandwidth=94, =93it will resolve
 itself with time=94 etc., I strongly object! That is wrong and will be ver=
y detrimental for WebRTC usage. We already see it and I can give numerous e=
xamples of how much less quality demanding VoIP is/is not handled quality w=
ise and that it matters. And, what
 would be bad considering quality issues and allowing/encouraging methods t=
o deal with them?







 


If the hesitations are raised, because of suspicion that =
the methods we may recommend may be misused to stop/block/destroy WebRTC us=
age (e.g. to protect income from carrier
 telephony traffic), I could understand and would fight the same battle. Bu=
t hopefully, those days are (soon) over =96 At least forward thinking carri=
er=92s realize that already. Web RTC will happen. Which customers want to p=
ay for an access with blocked WebRTC?
 The carrier=92s offering/assuring good WebRTC will rather get the customer=
s and income J.
 (Maybe the Web browser can detect and encourage this=85) 







 


If there are technical concerns of bad result, or better =
methods allowing network providers and LAN managers to offer and inform the=
 browser that there are good media paths
 to be used, and that the web browser automatically can chose those, then l=
et us all understand those, so we can achieve what should be achieved by th=
is milestone.







 







Skype, Hangouts, Facetime are doing billions of minute=
s per week and the Internet has not melted yet. If we need to do flow ident=
ification to allow traffic to be prioritized, fine (see above regarding my =
preferred approach), but forcing all
 WebRTC traffic through a MITM (TURN server) is a much bigger jump that I d=
on't yet see the justification for.







 







In short: TURN is a technology that is supposed to fad=
e away with the move to IPv6. I don't think we want to make it a critical e=
lement of WebRTC.







 


/Karl



 


 






Fr=E5n:&nbs=
p;Dan Wing [mailto:dwing@cisco.com] 

Skickat: den 11 fe=
bruari 2014 18:25

Till: Marc Blanchet<=
br>
Kopia: Justin Uber=
ti; tireddy@icisco.com;
 Karl Stahl; tram@ietf.org;
 Simon Perreault







=C4mne: Re: [tram]=
 Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs<=
span lang=3D"EN-US">











 



 







On Feb 11, 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.=
ca> wrote:




 





Le 2014-02-11 =E0 00:39, Dan Wing <dwing@cisco.com> a =
=E9crit :





 









On Feb 10, 2014, at 5:30 PM, Justin Uberti <=
juberti@google.com=
>
 wrote:





 





Good to=
 see there is a lot of interest for this milestone. But based on the descri=
ption here, it seems like we want to use TURN primarily to identify WebRTC =
flows, as opposed to using it as a
 NAT traversal tool. This makes me concerned that we may be using the wrong=
 technology to solve the problem.







 <=
/span>







+1.=








 <=
/span>







I would=
 prefer allowing flows to establish themselves using their 'best' path, and=
 the best path is seldom through a TURN server.  When we imagine IPv6 =
in our future, we don't want to force an
 application-level proxy (TURN) server on the path solely for traversing an=
 IPv6 firewall.







 <=
/span>







 <=
/span>







It seem=
s this thread is conflating all the possible reasons / justifications for T=
URN:







  =
* mobility







  =
* NAT traversal (both endpoints are behind endpoint-dependent mapping NATs)=








  =
* firewall traversal (firewall blocks UDP)=








  =
* enhancing privacy







 <=
/span>







Unfortu=
nately the TURN server nor the endpoint really know which of those use-case=
s is desired (by the user or by the IT network administrator) or necessary =
(for the call to work at all).









 







Dan, while I agree in principle, I doubt that a user could ever say "I=
 want mobility or I want NAT traversal". I think the user only want th=
e call to succeed, whatever the properties of its network point of attachme=
nt are.











 







So what can we do?  Should the TURN server provide any and all service=
s the TURN client might possibly want, as that is what a robust TURN server=
 will do, and the endpoint should prefer TURN candidates over all others be=
cause there might be some functionality
 / usefulness of TURN that the user might gain through TURN (e.g., enhanced=
 privacy)?







 







-d







 







 









 







 T=
his seems problematic.  Perhaps we need a way to signal the desired us=
e-case ("trait"), or as Justin suggests, using a different techno=
logy for some of these use-cases.







 <=
/span>







-d







 <=
/span>







 <=
/span>





 





 <=
/span>





On Mon,=
 Feb 10, 2014 at 3:18 PM, Karl Stahl <<=
a href=3D"mailto:karl.stahl@intertex.se" target=3D"_blank" style=3D"color: =
purple; text-decoration: underline;">karl.stahl@intertex.se=
=
> wrote:



Simon,<=
br>


Good questions - see inline below --> .

Some more thought is required!



/Karl



-----Ursprungligt meddelande-----

Fr=E5n: tram [mailto:tram-bounces@ietf.org]
 F=F6r Simon Perreault

Skickat: den 10 februari 2014 15:16

Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com

=C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for en=
terprise and ISPs







Karl,



It is great to see such enthusiasm! Thanks!



I have a couple technical questions...



Le 2014-02-08 08:11, Karl Stahl a =E9crit :

> - Note that to achieve some of the above points, TURN must be favored<=
br>
> over STUN to enforce that the TURN-path actually is used. (The Anycast=


> method suggested below, =93automatically=94 does this.)



I understand the STUN vs TURN priority issue. But I don't see how anycast a=
ffects it in any way. Can you please explain?





--- Goo=
d point - I was a bit quick here (maybe too quick)

We have given this quite bit of thought, since even if a TURN server is pro=
vided and discovered, CURRENT usage of ICE may suggest a candidate from the=
 remote party that will make a connection without the need/usage of the TUR=
N server (that we wanted to be used
 for the good purposes listed).



The only way we found around this, was to stop STUN through the IP default =
gateway (like a restrictive Enterprise firewall does inhibiting ICE connect=
ivity, which others are concerned about...). Since the provisioning of auto=
-discovery using the anycast mechanism,
 would be adding a route in a default gateway, adding a firewall rule to ea=
t STUN packets would assure that the provisioned TURN server actually becom=
es used (and not bypassed "by accident"). (That was the thought b=
ehind the =93automatically=94 within quotes.)



BUT, since you brought up the question, assuming that we have the power to =
enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-di=
scovered TURN server instead of STUN, would solve the same problem. However=
, thinking further (in relation
 to your next question - "anyone could set up a badly-maintained"=
 - enforcing such ICE usage may not be good.)









> - 3^rd The Anycast method below =96 I see no problem

>

> It also has the advantage of encouraging (but not requiring) the

> STUN/TURN to be built in the default gateway or NAT/firewall/access
> router itself, with a second interface to a public IP address on the
> WAN side. (Current volume deployed, low cost NSP triple play modems
> usually have a quality assured level 2 or level 3 WAN pipe for just
> voice (and another for IPTV) =96 The anycast discovered TURN-server ca=
n

> be the access gateway to such quality pipe for WebRTC media, in a

> single NSP provided CPE, scaling from residential and up.)



Suppose we define well-known anycast TURN server addresses. How would this =
not be subject to the same service quality issues that plagued 6to4? That i=
s, anyone could set up a badly-maintained, under-provisioned TURN server an=
d announce it over BGP to the world,
 as it was done for

6to4 relays. Or just bad BGP outbound filter configuration. And how can we =
prevent triangle routing? There is nothing guaranteeing that the anycast se=
rver you see is being provided to you by your ISP, rather than a server sit=
ting on the other side of the planet.





--- Goo=
d point - needs to be resolved. For this I don't have a ready answer...

An auto-discovered TURN server must be trusted (whatever method it is disco=
vered by). We are trusting the one providing us with an IP address and defa=
ult gateway anyway. It would be easy if we could reuse that trust, instead =
of another mechanisms.



Is there a good way for the browser to check that the anycast address is no=
t handled beyond the network service provider's default gateway? Ideas?











Thanks,

Simon

--

DTN made easy, lean, and smart --> http://postellation.viagenie.ca

NAT64/DNS64 open-source        --> http://ecdysis.via=
genie.ca

STUN/TURN server               -->&nb=
sp;http:=
//numb.viagenie.ca

_______________________________________________

tram mailing list

tram@ietf.org=


https://www.ietf.org/mailman/listinfo/tram



_______________________________________________

tram mailing list

tram@ietf.org=


https://www.ietf.org/mailman/listinfo/tram







 <=
/span>





_______=
________________________________________

tram mailing list

tram@ietf.org=


https://www.ietf.org/mailman/listinfo/tram







_______________________________________________

tram mailing list

tram@ietf.org=


https://www.ietf.org/mailman/listinfo/tram





 







 









 















_______________________________________________

tram mailing list

tram@ietf.org

https://www.ietf.org/mai=
lman/listinfo/tram

--_000_D5104301CDA8424894B9364F4FA3E5B9ciscocom_-- From nobody Wed Feb 19 05:34:23 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B2E1A04BA for ; Wed, 19 Feb 2014 05:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 pB7bn4zUw6L2 for ; Wed, 19 Feb 2014 05:34:21 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 007E21A04B9 for ; Wed, 19 Feb 2014 05:34:20 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A547F403CE for ; Wed, 19 Feb 2014 08:34:17 -0500 (EST) Message-ID: <5304B2D9.6070103@viagenie.ca> Date: Wed, 19 Feb 2014 08:34:17 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> <5303D8D2.5080003@alum.mit.edu> <5303E018.6040405@alum.mit.edu> In-Reply-To: <5303E018.6040405@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/4GIozALJr4TSUurkqS3SalI5RQw Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 13:34:22 -0000 Le 2014-02-18 17:35, Paul Kyzivat a écrit : > On 2/18/14 5:08 PM, Oleg Moskalenko wrote: >> TURN/STUN has been a binary protocol, so far... bringing SDP into the >> picture would make it too complicated. > > I didn't mean that. I just meant that the taxonomy could potentially be > adopted in some way. > > (Whether that is a good idea is another story. I haven't followed the > work closely. It isn't obvious to me that the particular taxonomy is > well justified.) And we need to keep in mind that TURN is a generic traversal mechanism usable by more than just real-time media... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Feb 19 07:32:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A75C1A04F7 for ; Wed, 19 Feb 2014 07:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 Pm5zFrExfH-6 for ; Wed, 19 Feb 2014 07:32:08 -0800 (PST) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 718CA1A05CB for ; Wed, 19 Feb 2014 07:32:08 -0800 (PST) Received: by mail-oa0-f43.google.com with SMTP id h16so590046oag.30 for ; Wed, 19 Feb 2014 07:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=pVhegDc6v13WyNuVfd23+JrpeW5+2pTPE5z4xWPLGk8=; b=M0sPsqvX1OYWBS5mODi9xonT613Vit/a6c8S3QFPEoNzuv1bU6AULFK/fY9/Px7Edl JeO/F0XS/3ivXSWHejw482Rga62Pyy/zkfv1r7nN34mz3cVWqLd4tAFX7cCIP025I9QH ytRPbd2h6sM9lza8W4lT+Hmde0teIj75XR+G9bj4XqODU+oop0wtE5Fb3kT1se3+4lDF QkLy7IjjqZvge+aZMMQXZEl3rwaqY9pGdaFKQr5J1MlpaPomMrPgGXRMNPazQlCcFXET Ab284vsi/Hyvkkmld751xpNP4WV970WA6ZIDoEHTKldtpilVCDlnRjYuradYiyiwlqV4 3UUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=pVhegDc6v13WyNuVfd23+JrpeW5+2pTPE5z4xWPLGk8=; b=doV7rtOWU5rci3PCD/KyAGcfDBMUaORKMUgiRgrfSsc9kFPVJVusjzgfE/ciW4hpO/ 7gU4YT5PCjwbIDhkzIteIvOpQsxuerG0dJUz+lF/OD3NslKogSFH9ywxf7aCF2sMEo7Y PWMhcFfhWrIyc3vb/t5fAkgfZ4JCyKC2G7VT0t0tefARodHzUErB4QgE4Tc75zJrPwxb gOHOSzuUH+uaBKzSRaHntE9o2zb0QJdPcoCm01+el2hqXN7rUetqjgnhFhUJZbz7QRgM 19U1Ha2UXEAlAm8L9JMiysOf0ZrLWbZRzfIP/GYKmX++sBKBPJyvvJG87m7KXJrlQFLH RxjQ== X-Gm-Message-State: ALoCoQnYqtTnZkVAzV9OSU8GL9QWB408ds4MZXB6pB7hY1irx6FDTiEDMuaUOdisNH5le/PKaW2DITfTiQTW0ySpxZo2izVqqryh3AtvWDFcI3vzKZrYf7fZUQ7wu7zq/eWI8mr+JBxPeqBSaYKuAZ9Zy7oxDHJcsYYSSx4amX1SrUPJSblfiFxvfuf6GTryvoOyjWhM1ZHX X-Received: by 10.60.52.101 with SMTP id s5mr32060732oeo.7.1392823925099; Wed, 19 Feb 2014 07:32:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.246.102 with HTTP; Wed, 19 Feb 2014 07:31:44 -0800 (PST) From: Mallinath Bareddy Date: Wed, 19 Feb 2014 07:31:44 -0800 Message-ID: To: tram@ietf.org Content-Type: multipart/alternative; boundary=001a11330d544a663904f2c41759 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ooLHQihvM7eXquHbfu6EpTxo14o Subject: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 15:32:10 -0000 --001a11330d544a663904f2c41759 Content-Type: text/plain; charset=UTF-8 Hi All, >From RFC 5766, Both the server and client keep track of a value known as the 5-TUPLE. At the client, the 5-tuple consists of the client's host transport address, the server transport address, and the transport protocol used by the client to communicate with the server. At the server, the 5-tuple value is the same except that the client's host transport address is replaced by the client's server-reflexive address, since that is the client's address as seen by the server. I have a scenario where Turn client is sending IPv4 and a IPv6 (using REQUESTED-ADDRESS-FAMILY attribute) allocation requests from the same host transport address. The reason to send IPv6 allocation request is to connect to a IPv6 only client. >From above definition both allocation requests will result in same 5-tuple at the server. How does TURN server demux requests from client, leading to the proper allocation object? Regards, Mallinath --001a11330d544a663904f2c41759 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

>From RFC 5766,=C2=A0
=C2=A0 =C2=A0 =C2= =A0Both the server and client keep track of a value known as the
= 
   5-TUPLE.  At the client, the 5-tuple consists of the client'=
s host
   transport address, the server transport address, and the transport
   protocol used by the client to communicate with the server.  At the
   server, the 5-tuple value is the same except that the client's host
   transport address is replaced by the client's server-reflexive
   address, since that is the client's address as seen by the server.


I have a scenario where Turn cl=
ient is sending IPv4 and a IPv6 (using REQUESTED-ADDRESS-FAMILY=C2=A0attribute) allocation requests from the same host transport addre=
ss. The reason to send IPv6 allocation request is to connect to a IPv6 only=
 client.



=


From above definiti=
on both allocation requests will result in same 5-tuple at the server. How =
does TURN server demux requests from client, leading to the proper allocati=
on object?




Regards,



Mallinath
--001a11330d544a663904f2c41759-- From nobody Wed Feb 19 07:42:09 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6837F1A0206 for ; Wed, 19 Feb 2014 07:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 8bpuo2O1Roql for ; Wed, 19 Feb 2014 07:42:06 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7931A01DE for ; Wed, 19 Feb 2014 07:42:06 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 26EC7403C0 for ; Wed, 19 Feb 2014 10:42:03 -0500 (EST) Message-ID: <5304D0CA.9020201@viagenie.ca> Date: Wed, 19 Feb 2014 10:42:02 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/pbki1u-EE-6z9cLDNG085VPCeFI Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 15:42:08 -0000 Le 2014-02-19 10:31, Mallinath Bareddy a écrit : > Hi All, > >>From RFC 5766, > Both the server and client keep track of a value known as the > > 5-TUPLE. At the client, the 5-tuple consists of the client's host > transport address, the server transport address, and the transport > protocol used by the client to communicate with the server. At the > server, the 5-tuple value is the same except that the client's host > transport address is replaced by the client's server-reflexive > address, since that is the client's address as seen by the server. > > > > I have a scenario where Turn client is sending IPv4 and a IPv6 (using REQUESTED-ADDRESS-FAMILY attribute) allocation requests from the same host transport address. The reason to send IPv6 allocation request is to connect to a IPv6 only client. > > > > From above definition both allocation requests will result in same 5-tuple at the server. No. There can be only one allocation per 5-tuple. > How does TURN server demux requests from client, leading to the proper allocation object? Have the client use a different source port. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Feb 19 07:45:14 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB821A032A for ; Wed, 19 Feb 2014 07:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1c97W6p3-4J8 for ; Wed, 19 Feb 2014 07:45:08 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9492C1A01DE for ; Wed, 19 Feb 2014 07:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1664; q=dns/txt; s=iport; t=1392824705; x=1394034305; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=ntUOIG4CJJw393AZhd7TreWtoILblPcYdPe6CpsqGnQ=; b=CrojzvnLawf76rL4fAu9Rvr3pTZydYnojGhF+JRYqkUpI8+5by984utG FnJuB69khbYtuau425fRXi0vEB01mHZDGKAvvCmxFHUWx2KmhUM7NWJLM 7091dwBcT9WT2x0fvDf3L2IU5zcu6mfRDEmTS5Mm72g1MFk6OGS9PVOGw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFANnQBFOtJV2c/2dsb2JhbABZgwY4V795gRcWdIIlAQEBAwEBAQEkRxAHBgEIEQQBAQsdLgsUCQkBBAESCId1CA3NdBeOMz6DHoEUBIkQkFKQcoMtgio X-IronPort-AV: E=Sophos;i="4.97,506,1389744000"; d="scan'208";a="21593857" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 19 Feb 2014 15:45:05 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1JFj5oG025390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 15:45:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 09:45:04 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: Ac8tiYxikG6+dmzjRpOGDUg+RqIkaw== Date: Wed, 19 Feb 2014 15:45:04 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242C128F@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.164] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/5nR0a6LuUfh1EP45-0m-oTE7jT4 Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 15:45:12 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Wednesday, February 19, 2014 3:03 AM > To: tram@ietf.org > Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00= .txt >=20 > Le 2014-02-18 16:12, Oleg Moskalenko a =E9crit : > > How to handle the DS and ECN fields is a part of TURN server RFC (see > > the section 12): > > > > http://tools.ietf.org/search/rfc5766#section-12 > > > > And a good TURN server is supposed to implement that. >=20 > Well, the RFC just says that the TURN server should copy the DSCP from on= e side > to the other when doing en/de-capsulation. It doesn't say that the server= should > actually do QoS based on the DSCP. My point is that there's nothing preve= nting > the server from actually doing it. >=20 > Anyway, I was expecting responses along the lines of "DiffServ doesn't wo= rk on > the Internet in general."=20 Yes, the other problem is some OS like Windows (http://support.microsoft.co= m/kb/248611) do not support setting DSCP. -Tiru > To which I would have replied: "then couldn't we define > a STUN attribute for transporting the DSCP in the payload?" Instead of in= venting > a new taxonomy (audio, video, slides, etc.), why not reuse DSCP? >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 19 07:48:14 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6601A01DE for ; Wed, 19 Feb 2014 07:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 sxoNp_63CvAS for ; Wed, 19 Feb 2014 07:48:07 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 16D831A01D5 for ; Wed, 19 Feb 2014 07:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2178; q=dns/txt; s=iport; t=1392824884; x=1394034484; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=EGNMXoTYOY14fganwIo8twbzQ7j8bHc64+9nklqDhRw=; b=XEzPMkQPr6lRORcsXqmvqosWKzxFqFLg5IkuTp3sUodIt/7o5/cWoqMd uBcI/OUXGPM5TT1+Tl3X6i2gLW7QN/eJzba7C9gI+H2YOtj5cWXN/WNgn ftPEKPt2inZ0GueuLH7GeptdD+7qqpOCZXIoOuGe0pGl/541cTXWiRLnt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAIbRBFOtJV2a/2dsb2JhbABZgwY4V795gRcWdIIlAQEBAwEBAQEkRxcGAQgRBAEBAQodLgsUCQkBBAEJCQiHdQgNzXUXjjM+gx6BFASJEJBSkHKDLYIq X-IronPort-AV: E=Sophos;i="4.97,506,1389744000"; d="scan'208";a="305107150" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 19 Feb 2014 15:48:03 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1JFm3wv007265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 15:48:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.67]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 09:48:03 -0600 From: "Tirumaleswar Reddy (tireddy)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: Ac8tifVs8hZxWIUuSWm3NGfIH8+YAA== Date: Wed, 19 Feb 2014 15:48:02 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A242C12A4@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.41.164] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7bm9lWj-lE9isBxHOi9FcCg78tA Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 15:48:10 -0000 > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Wednesday, February 19, 2014 7:04 PM > To: tram@ietf.org > Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00= .txt >=20 > Le 2014-02-18 17:35, Paul Kyzivat a =E9crit : > > On 2/18/14 5:08 PM, Oleg Moskalenko wrote: > >> TURN/STUN has been a binary protocol, so far... bringing SDP into the > >> picture would make it too complicated. > > > > I didn't mean that. I just meant that the taxonomy could potentially > > be adopted in some way. > > > > (Whether that is a good idea is another story. I haven't followed the > > work closely. It isn't obvious to me that the particular taxonomy is > > well justified.) >=20 > And we need to keep in mind that TURN is a generic traversal mechanism us= able > by more than just real-time media... Good point and explicitly signaling Audio, Video, Data channels, file tran= sfer etc. could cause to keep enhancing the list in future with avatar, sm= ellovision etc. http://tools.ietf.org/search/rfc5897#section-6.3 Consider the following example. Several providers get together and standardize on a bunch of service identifiers. One of these uses audio and video (say, "multimedia conversation"). This service is successful and is widely utilized. Endpoints look for this identifier to dispatch calls to the right software applications, and the network looks for it to invoke features, perform accounting, and provide QoS. A new provider gets the idea for a new service (say, "avatar-enhanced multimedia conversation"). In this service, there is audio and video, but there is a third stream, which renders an avatar. -Tiru >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 19 08:38:08 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904681A055A for ; Wed, 19 Feb 2014 08:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 3KivTiJuG1mj for ; Wed, 19 Feb 2014 08:38:03 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7F21A04E4 for ; Wed, 19 Feb 2014 08:38:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2254; q=dns/txt; s=iport; t=1392827880; x=1394037480; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lpNe2f2WmdiY+xku9yRbAnoLEWZue046i+PR+Yaa30U=; b=JjC+Av3Ze3VW9/KaWOghIe/ztNODybTOsnB1D2X4UySssNTpR46HWcqb VQRMDug5Uw8CbBCs6DrGcQniYt/ehLUx+VCfDhxyHhXBtVsRnfBlc+quT IqHdPMFlydgyeQij1RZM1w2hzGHZPSsJahqLBtJ1u1+S4t01JhzvkGAZY o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIzcBFOtJV2d/2dsb2JhbABZgwY4V795gRcWdIIlAQEBAwEBAQEkRwsFCwIBCEYnCyUCBA4Fh30IDc1mF44xMweDJIEUBJgwgTKQcoMtgio X-IronPort-AV: E=Sophos;i="4.97,506,1389744000"; d="scan'208";a="21601121" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP; 19 Feb 2014 16:38:00 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1JGbx9r013788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 16:38:00 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 10:37:59 -0600 From: "Pal Martinsen (palmarti)" To: Simon Perreault Thread-Topic: [tram] IPv4 and IPv6 allocations Thread-Index: AQHPLYfCF1sa7J708UqHyNHj1pugzJq9G8kAgAAPoQA= Date: Wed, 19 Feb 2014 16:37:59 +0000 Message-ID: References: <5304D0CA.9020201@viagenie.ca> In-Reply-To: <5304D0CA.9020201@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.70] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1437B02249CB3446A32540BBD5981D31@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/SjjPhl0eJXAcOormvnsy4gf_1K8 Cc: "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 16:38:05 -0000 On 19 Feb 2014, at 16:42 pm, Simon Perreault = wrote: > Le 2014-02-19 10:31, Mallinath Bareddy a =E9crit : >> Hi All, >>=20 >>> From RFC 5766,=20 >> Both the server and client keep track of a value known as the >>=20 >> 5-TUPLE. At the client, the 5-tuple consists of the client's host >> transport address, the server transport address, and the transport >> protocol used by the client to communicate with the server. At the >> server, the 5-tuple value is the same except that the client's host >> transport address is replaced by the client's server-reflexive >> address, since that is the client's address as seen by the server. >>=20 >>=20 >>=20 >> I have a scenario where Turn client is sending IPv4 and a IPv6 (using RE= QUESTED-ADDRESS-FAMILY attribute) allocation requests from the same host tr= ansport address. The reason to send IPv6 allocation request is to connect t= o a IPv6 only client. >>=20 >>=20 >>=20 >> From above definition both allocation requests will result in same 5-tup= le at the server. >=20 > No. There can be only one allocation per 5-tuple. >=20 >> How does TURN server demux requests from client, leading to the proper a= llocation object? >=20 > Have the client use a different source port. >=20 IMHO this would make a good optimisation. Endpoints can discover how to rea= ch the TURN server well before a call is made, webRTC is a bit more tricky = but Ill guess there are room for some sort of =93pre call=94 discovery ther= e as well. The agent can thus lock down to a specific IP address family tal= king to the TURN server. To further reduce chatter it would be nice to be a= ble to allocate two types of IP RELAY addresses with one allocation messag= e. Writing up draft describing that would not be to hard unless I miss some= thing. .-. P=E5l-Erik > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 19 08:44:23 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA6571A04E7 for ; Wed, 19 Feb 2014 08:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 cjUKNZoEscV7 for ; Wed, 19 Feb 2014 08:44:20 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1391A04B8 for ; Wed, 19 Feb 2014 08:44:20 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 882F7403C0; Wed, 19 Feb 2014 11:44:16 -0500 (EST) Message-ID: <5304DF60.7020200@viagenie.ca> Date: Wed, 19 Feb 2014 11:44:16 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" References: <5304D0CA.9020201@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/gBURMYp6k1MVldaxagUt1_gRcdk Cc: "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 16:44:22 -0000 Le 2014-02-19 11:37, Pal Martinsen (palmarti) a écrit : > IMHO this would make a good optimisation. Endpoints can discover how > to reach the TURN server well before a call is made, webRTC is a bit > more tricky but Ill guess there are room for some sort of “pre call” > discovery there as well. The agent can thus lock down to a specific > IP address family talking to the TURN server. To further reduce > chatter it would be nice to be able to allocate two types of IP > RELAY addresses with one allocation message. Writing up draft > describing that would not be to hard unless I miss something. I think it would be super hard, as in it would require completely redesigning TURN. :) All the TURN messages rely on there being a single allocation per 5-tuple. For example, in a Send indication, you don't tell the server out of which allocation (i.e., external port) to send the actual packet. So you would need to add an "allocation ID" attribute to just about everything: Send, Data, Refresh, etc. Then we need to think about channels. By this point we are fairly discouraged, and we still need to think about TURN-TCP. Yuck. One allocation per 5-tuple. I don't think we're changing this anytime soon. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Feb 19 08:49:26 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C051A04EF for ; Wed, 19 Feb 2014 08:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 eL5n4hX-8YP1 for ; Wed, 19 Feb 2014 08:49:22 -0800 (PST) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 849281A057F for ; Wed, 19 Feb 2014 08:49:22 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id um1so630649pbc.19 for ; Wed, 19 Feb 2014 08:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mkZZvqufr1DvwpjHMEeCs3y9eFShEJR/VqNjzQcRU2c=; b=pCMUii/YkWEUelrl0qQN9VnBtqLylkK2Fq03DkyooDeK9jKHvqEiM7eJjIpk8jv+58 v8AcrdWZLrDx4gjDF3/7hfc9IsJlnTBZB9E1sODJtwzixhJSVUGuV0JGa9khk3X6eHoj zrfI9xMYRqgvMRtZVsjarYL9fUQB1dqDffz9k7wp1nYup8hdhM3DTwyLnIm6VJ+C32V1 i5Jr+abhAtEBSGxoxJdcGs5Uj3qkRiPjwk7Ske0N/O6cGYsvihishHmACqW4KuzMIKYf rtkaBqhu918KkVySHg820H1IXciiyy5N8cAXJzWFPcyDEaMdPmO9wGQLZwORtSsUzGVW oNZw== MIME-Version: 1.0 X-Received: by 10.68.139.100 with SMTP id qx4mr3306100pbb.144.1392828559283; Wed, 19 Feb 2014 08:49:19 -0800 (PST) Received: by 10.68.147.131 with HTTP; Wed, 19 Feb 2014 08:49:19 -0800 (PST) In-Reply-To: <5304DF60.7020200@viagenie.ca> References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> Date: Wed, 19 Feb 2014 08:49:19 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c361d2825c8d04f2c52bbb Archived-At: http://mailarchive.ietf.org/arch/msg/tram/wLe4zDOnruurgZyoN-_3SlSYRN0 Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 16:49:25 -0000 --001a11c361d2825c8d04f2c52bbb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If we allow two allocations per session that would be unnecessary complication that does not serve any immediate purpose that cannot be served in another way and it would encourage waste of resources. I do not think that would be a good idea. Oleg On Wed, Feb 19, 2014 at 8:44 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-02-19 11:37, Pal Martinsen (palmarti) a =E9crit : > > IMHO this would make a good optimisation. Endpoints can discover how > > to reach the TURN server well before a call is made, webRTC is a bit > > more tricky but Ill guess there are room for some sort of "pre call" > > discovery there as well. The agent can thus lock down to a specific > > IP address family talking to the TURN server. To further reduce > > chatter it would be nice to be able to allocate two types of IP > > RELAY addresses with one allocation message. Writing up draft > > describing that would not be to hard unless I miss something. > > I think it would be super hard, as in it would require completely > redesigning TURN. :) > > All the TURN messages rely on there being a single allocation per > 5-tuple. For example, in a Send indication, you don't tell the server > out of which allocation (i.e., external port) to send the actual packet. > So you would need to add an "allocation ID" attribute to just about > everything: Send, Data, Refresh, etc. Then we need to think about > channels. By this point we are fairly discouraged, and we still need to > think about TURN-TCP. Yuck. > > One allocation per 5-tuple. I don't think we're changing this anytime soo= n. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a11c361d2825c8d04f2c52bbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If we allow two allocations per session that would be unne= cessary complication that does not serve any immediate purpose that cannot = be served in another way and it would encourage waste of resources. I do no= t think that would be a good idea.

Oleg


On Wed, Feb 19, 2014 at 8:44 AM, Simon Perreault <= ;simon.per= reault@viagenie.ca> wrote:
Le 2014-02-19 11:37, Pal Martinsen (palmarti= ) a =E9crit :
> IMHO this would make a good optimisation. Endpoints ca= n discover how
> to reach the TURN server well before a call is made, webRTC is a bit > more tricky but Ill guess there are room for some sort of “pre c= all”
> discovery there as well. The agent can thus lock down to a specific > IP address family talking to the TURN server. To further reduce
> chatter it would be nice to be able to allocate two types of IP
> RELAY addresses with one allocation message. Writing up draft
> describing that would not be to hard unless I miss something.

I think it would be super hard, as in it would require completely
redesigning TURN. :)

All the TURN messages rely on there being a single allocation per
5-tuple. For example, in a Send indication, you don't tell the server out of which allocation (i.e., external port) to send the actual packet. So you would need to add an "allocation ID" attribute to just abo= ut
everything: Send, Data, Refresh, etc. Then we need to think about
channels. By this point we are fairly discouraged, and we still need to
think about TURN-TCP. Yuck.

One allocation per 5-tuple. I don't think we're changing this anyti= me soon.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca=

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--001a11c361d2825c8d04f2c52bbb-- From nobody Wed Feb 19 09:08:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5539E1A04F3 for ; Wed, 19 Feb 2014 09:08:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 TqWEGq9Bh8OQ for ; Wed, 19 Feb 2014 09:08:06 -0800 (PST) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4551A01CE for ; Wed, 19 Feb 2014 09:08:06 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id i7so739920oag.8 for ; Wed, 19 Feb 2014 09:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tHebA8U6Fpkgs+9SgoXonOANdmqCm32vX8zMndqEAwY=; b=bW4GG6U7NXTRZYDve0EByLplEkNGTTRkuYltXHDVX5OVgbxwwtJ7Agukk7vFOW8Ehl AM6X5W8sa7bGfgusQhb0kCYogt000Doi7ME9IFrEy3XpDXniEwtCJkmveORc4m6cAt4H gfml6dkIJ+LWuqXpdVDAIDkNCmrO8ZlwzwLkyPitKrarD8XM+horzgSYY3ll63fTkced zbRfs55erHO5GtV2rdkhaBxLdl2s/8ri1LNC2XFnDaL8OOcrgxuXysb+9RGMR6SALzE9 br35RE26dPWiQJ4IgINBT9kZenkAqGTSqwfvnDNCay2k+bsFrYOLCjFveS2nvSjNYrxr PlvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tHebA8U6Fpkgs+9SgoXonOANdmqCm32vX8zMndqEAwY=; b=h1Khx0T+E+kU3WVqEPImKo2ROMNgX0J1giTHdf+z6YLTBpnx3bRj+FR1jH3g4P0yn4 GOFgfxotAWQlKWLqSvCxYg2Q4AtjLA73TQ+4uc79PmWBu2rAwvQ6lXQh6TCil5hVipbr jeqcgZD+53uMX7MaY1zDl5EOb69gIWfowNLcV2QI2EuMcyNFBNsjKl3C+/xHp2YtOzWW K9SXSLJhHHXHMo/pzlsesyBRWyAeBT64kfEKiVTkkFpLOQGEFVpedbEKQfjn7OjOF1+6 0Xiu2rDWvi9m8qVznSrWdeZKrVHH/UWsGUvXRQxw0MrF74EVTbDh0fc0J4vqmKvUI+2G IVBQ== X-Gm-Message-State: ALoCoQmBhQU1sI+rH1/jbf0rh9Mpgjak0eizhSR5hPQVPC7rNJCuIBoyi+hvfo7VXK1hwWR2HFAragCM+9pM7+SYrobyOqWxE4qv7p3Uen9/1siH2HFhVhf0iJkgy3nXxOh2EIrTn2UWp8tmqx27PMpSBWdlg6gYxogIiPq4ksg2Hj9HDGUWLDonrAucp0bEfa76aiYOU1DG X-Received: by 10.182.158.40 with SMTP id wr8mr1728715obb.86.1392829682928; Wed, 19 Feb 2014 09:08:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.246.102 with HTTP; Wed, 19 Feb 2014 09:07:42 -0800 (PST) In-Reply-To: References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> From: Mallinath Bareddy Date: Wed, 19 Feb 2014 09:07:42 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=089e013d0d6c7be94b04f2c56ee7 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/t5VTVZHXPZQPC19iMHl20RHK5OE Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:08:09 -0000 --089e013d0d6c7be94b04f2c56ee7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Pal, I am not sure how a "pre call" setup will help in this case, as we will not know ahead of time about the peer address type. It's not just reaching the TURN server. On Wed, Feb 19, 2014 at 8:49 AM, Oleg Moskalenko wrote= : > If we allow two allocations per session that would be unnecessary > complication that does not serve any immediate purpose that cannot be > served in another way and it would encourage waste of resources. I do not > think that would be a good idea. > > Oleg > > > On Wed, Feb 19, 2014 at 8:44 AM, Simon Perreault < > simon.perreault@viagenie.ca> wrote: > >> Le 2014-02-19 11:37, Pal Martinsen (palmarti) a =C3=A9crit : >> > IMHO this would make a good optimisation. Endpoints can discover how >> > to reach the TURN server well before a call is made, webRTC is a bit >> > more tricky but Ill guess there are room for some sort of =E2=80=9Cpre= call=E2=80=9D >> > discovery there as well. The agent can thus lock down to a specific >> > IP address family talking to the TURN server. To further reduce >> > chatter it would be nice to be able to allocate two types of IP >> > RELAY addresses with one allocation message. Writing up draft >> > describing that would not be to hard unless I miss something. >> >> I think it would be super hard, as in it would require completely >> redesigning TURN. :) >> >> All the TURN messages rely on there being a single allocation per >> 5-tuple. For example, in a Send indication, you don't tell the server >> out of which allocation (i.e., external port) to send the actual packet. >> So you would need to add an "allocation ID" attribute to just about >> everything: Send, Data, Refresh, etc. Then we need to think about >> channels. By this point we are fairly discouraged, and we still need to >> think about TURN-TCP. Yuck. >> >> One allocation per 5-tuple. I don't think we're changing this anytime >> soon. >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --089e013d0d6c7be94b04f2c56ee7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Pal, I am not sure how a "pre call" setup will h= elp in this case, as we will not know ahead of time about the peer address = type. It's not just reaching the TURN server.


On Wed, Feb 19, 2014 at 8:49 AM, Oleg Mo= skalenko <mom040267@gmail.com> wrote:
If we allow two allocations per session that would be unne= cessary complication that does not serve any immediate purpose that cannot = be served in another way and it would encourage waste of resources. I do no= t think that would be a good idea.

Oleg


On Wed, Feb 19, = 2014 at 8:44 AM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
Le 2014-02-19 11:37, Pal Martinsen (palmarti= ) a =C3=A9crit :
> IMHO this would make a good optimisation. Endpoints can discover = how
> to reach the TURN server well before a call is made, webRTC is a bit > more tricky but Ill guess there are room for some sort of =E2=80=9Cpre= call=E2=80=9D
> discovery there as well. The agent can thus lock down to a specific > IP address family talking to the TURN server. To further reduce
> chatter it would be nice to be able to allocate two types of IP
> RELAY addresses with one allocation message. Writing up draft
> describing that would not be to hard unless I miss something.

I think it would be super hard, as in it would require completely
redesigning TURN. :)

All the TURN messages rely on there being a single allocation per
5-tuple. For example, in a Send indication, you don't tell the server out of which allocation (i.e., external port) to send the actual packet. So you would need to add an "allocation ID" attribute to just abo= ut
everything: Send, Data, Refresh, etc. Then we need to think about
channels. By this point we are fairly discouraged, and we still need to
think about TURN-TCP. Yuck.

One allocation per 5-tuple. I don't think we're changing this anyti= me soon.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://numb.viagenie.ca=

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--089e013d0d6c7be94b04f2c56ee7-- From nobody Wed Feb 19 09:09:14 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765B81A022F for ; Wed, 19 Feb 2014 09:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 zLhCPTl5W9xu for ; Wed, 19 Feb 2014 09:09:09 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4899F1A0209 for ; Wed, 19 Feb 2014 09:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2924; q=dns/txt; s=iport; t=1392829747; x=1394039347; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WpGgAxkbDtQyPvUjHPQeTIpMJA0XUMnu1QJp1gwpzOI=; b=lxz6EwiWWgabEGlByq1eBlodvpvH8Owv8YR6Gfzj2V0LaG1191kZYrxW i4QR6nomo9zYXwieIUz8wnS6pZX+6ZnoTB/ebBuhIxMWOf0XY71tHQmiW AQiu2myAVTsbq5zHEs6vK8u/pYnmlFuPSjGI2XnGbWPLNPcAswnAW8cEA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAF7kBFOtJXG8/2dsb2JhbABZgwg4VbxNgRkWAXSDfQEBAQMBAQEBJEcLBQsCAQhGJwslAgQOBYd8CA3FTxeOXzMHgyOBEwSYFoEwkGSDK4Iq X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208";a="302076466" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 19 Feb 2014 17:09:06 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1JH95ra029641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 17:09:05 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 11:09:05 -0600 From: "Pal Martinsen (palmarti)" To: Simon Perreault Thread-Topic: [tram] IPv4 and IPv6 allocations Thread-Index: AQHPLYfCF1sa7J708UqHyNHj1pugzJq9G8kAgAAPoQCAAAHCAIAABuuA Date: Wed, 19 Feb 2014 17:09:05 +0000 Message-ID: References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> In-Reply-To: <5304DF60.7020200@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.70] Content-Type: text/plain; charset="Windows-1252" Content-ID: <79B69D63368AD744B779D2CB3E3DA6DD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oAUjFffH3Z0dwy4ndJNgZysUP88 Cc: "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:09:12 -0000 On 19 Feb 2014, at 17:44 pm, Simon Perreault = wrote: > Le 2014-02-19 11:37, Pal Martinsen (palmarti) a =E9crit : >> IMHO this would make a good optimisation. Endpoints can discover how >> to reach the TURN server well before a call is made, webRTC is a bit >> more tricky but Ill guess there are room for some sort of =93pre call=94 >> discovery there as well. The agent can thus lock down to a specific >> IP address family talking to the TURN server. To further reduce >> chatter it would be nice to be able to allocate two types of IP >> RELAY addresses with one allocation message. Writing up draft >> describing that would not be to hard unless I miss something. >=20 > I think it would be super hard, as in it would require completely > redesigning TURN. :) >=20 Wouldn't that be fun.. ;-) > All the TURN messages rely on there being a single allocation per > 5-tuple. For example, in a Send indication, you don't tell the server > out of which allocation (i.e., external port) to send the actual packet. > So you would need to add an "allocation ID" attribute to just about > everything: Send, Data, Refresh, etc. Then we need to think about > channels. By this point we are fairly discouraged, and we still need to > think about TURN-TCP. Yuck. >=20 We are only talking about allocating _one_ IPv4 and _one_ IPv6 address in t= he same allocation message. So the ip addr type of the peer_addr in the send indication message would m= ake it clear from where the TURN server should send the packet. Likewise th= e agent would know the incoming packet arrived at the TURN server by lookin= g at the peer addr in the data indication message.=20 When it comes to binding a channel this is normally done after ICE is finis= hed and the client decides to use the TURN server. We can then discard on= e of the allocated IP addresses to simplify.=20 Still got the feeling I miss something though.. > One allocation per 5-tuple. I don't think we're changing this anytime soo= n. Currently some of our endpoints have 6 media lines, 1x Audio, 2x Video, 1xF= ECC, 1xBFCP and 1xIX(app). Since 4 of those use RTP and RTCP this gives us = 10 TURN allocations pr call. 20 if we want to suport IPv4/IPv6 dual stack v= ia TURN. Our windows soft client ran into some problems regarding the numbe= r of socket one process could open.=20 It would reduce some pain for us, but it is dependant of how simple this wo= uld be to implement on the TURN server side. .-. P=E5l-Erik >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 19 09:12:56 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E72B1A0388 for ; Wed, 19 Feb 2014 09:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 QMBlrvjEGE_h for ; Wed, 19 Feb 2014 09:12:51 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 296811A0241 for ; Wed, 19 Feb 2014 09:12:51 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BC932403C0; Wed, 19 Feb 2014 12:12:47 -0500 (EST) Message-ID: <5304E60F.1020807@viagenie.ca> Date: Wed, 19 Feb 2014 12:12:47 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/s9x85Oi7QG9QOO_kfHRiwSOVOVk Cc: "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:12:53 -0000 Le 2014-02-19 12:09, Pal Martinsen (palmarti) a écrit : >> All the TURN messages rely on there being a single allocation per >> 5-tuple. For example, in a Send indication, you don't tell the server >> out of which allocation (i.e., external port) to send the actual packet. >> So you would need to add an "allocation ID" attribute to just about >> everything: Send, Data, Refresh, etc. Then we need to think about >> channels. By this point we are fairly discouraged, and we still need to >> think about TURN-TCP. Yuck. >> > We are only talking about allocating _one_ IPv4 and _one_ IPv6 address in the same allocation message. > So the ip addr type of the peer_addr in the send indication message would make it clear from where the TURN server should send the packet. Likewise the agent would know the incoming packet arrived at the TURN server by looking at the peer addr in the data indication message. You're right! > When it comes to binding a channel this is normally done after ICE is finished and the client decides to use the TURN server. We can then discard one of the allocated IP addresses to simplify. Sounds good. > Currently some of our endpoints have 6 media lines, 1x Audio, 2x Video, 1xFECC, 1xBFCP and 1xIX(app). Since 4 of those use RTP and RTCP this gives us 10 TURN allocations pr call. 20 if we want to suport IPv4/IPv6 dual stack via TURN. Our windows soft client ran into some problems regarding the number of socket one process could open. !!! > It would reduce some pain for us, but it is dependant of how simple this would be to implement on the TURN server side. In my experience: very easy. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Feb 19 09:16:24 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5341A0241 for ; Wed, 19 Feb 2014 09:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 a_3FktJJF_lV for ; Wed, 19 Feb 2014 09:16:20 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE4B1A01F0 for ; Wed, 19 Feb 2014 09:16:20 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0894D403C0; Wed, 19 Feb 2014 12:16:17 -0500 (EST) Message-ID: <5304E6E0.2010506@viagenie.ca> Date: Wed, 19 Feb 2014 12:16:16 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mallinath Bareddy , Oleg Moskalenko References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Ew1F6ZoOZdO_P0qJaFtkrNb8jlw Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:16:22 -0000 Le 2014-02-19 12:07, Mallinath Bareddy a écrit : > Pal, I am not sure how a "pre call" setup will help in this case, as we > will not know ahead of time about the peer address type. You don't need to know the peer's address type (with ICE, does such a concept exist anyway?). To properly support dual stack, you need to unconditionally create IPv4 and IPv6 relayed candidates. >From RFC 6157: When following the ICE procedures, in addition to local addresses, user agents may need to obtain addresses from relays; for example, an IPv6 user agent would obtain an IPv4 address from a relay. The relay would forward the traffic received on this IPv4 address to the user agent using IPv6. Such user agents MAY use any mechanism to obtain addresses in relays, but, following the recommendations in ICE, it is RECOMMENDED that user agents support STUN relay usage [6] [8] for this purpose. IPv4/IPv6 user agents SHOULD gather both IPv4 and IPv6 addresses using the ICE procedures to generate all their offers. This way, both IPv4-only and IPv6-only answerers will be able to generate a mutually acceptable answer that establishes a session (having used ICE to gather both IPv4 and IPv6 addresses in the offer reduces the session establishment time because all answerers will find the offer valid.) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Feb 19 09:28:25 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182731A05BB for ; Wed, 19 Feb 2014 09:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 InFDaUy8BZae for ; Wed, 19 Feb 2014 09:28:18 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 595E21A04FF for ; Wed, 19 Feb 2014 09:28:18 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0092F403C0 for ; Wed, 19 Feb 2014 12:28:14 -0500 (EST) Message-ID: <5304E9AE.5070202@viagenie.ca> Date: Wed, 19 Feb 2014 12:28:14 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> In-Reply-To: <5304E60F.1020807@viagenie.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/exr746wpJjD9YPwQahyj-WjN1wA Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:28:20 -0000 Here's a crazy idea: why not have servers unconditionally create an IPv4 *and* an IPv6 allocation on any Allocate request? No need for a new parameter. What could go wrong? After all, we want clients to support dual-stack. This could actually help clients do it "by default" without having to create multiple TURN sessions. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Feb 19 09:36:50 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7B81A04EF for ; Wed, 19 Feb 2014 09:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 B1q86mKE9SF4 for ; Wed, 19 Feb 2014 09:36:47 -0800 (PST) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id 04CD61A01CE for ; Wed, 19 Feb 2014 09:36:46 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/19/2014 12:36:42 PM X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-90/SG:2 2/19/2014 12:35:56 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.764384 p=-0.953153 Source White X-Signature-Violations: 0-0-0-6399-c X-Note-419: 15.6003 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/19/2014 12:36:33 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 73558492 for tram@ietf.org; Wed, 19 Feb 2014 12:36:41 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Wed, 19 Feb 2014 11:36:40 -0600 From: Jonathan Lennox To: "tram@ietf.org" Thread-Topic: Sharing nonces across allocations - allowed? Thread-Index: AQHPLZklI/mstGT3gUGmj+XPt51ctQ== Date: Wed, 19 Feb 2014 17:36:40 +0000 Message-ID: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="us-ascii" Content-ID: <76816DEA47BC4B4FB802D16B999D1DED@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/O9EjdYVyaopU-bYNOytryiwzMI4 Subject: [tram] Sharing nonces across allocations - allowed? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:36:49 -0000 So Oleg and I were having an argument in the rfc5766-turn-server bug tracke= r about whether it's valid to share nonces across TURN allocations. (See <= http://code.google.com/p/rfc5766-turn-server/issues/detail?id=3D107>). I argued that this text from RFC 5389 means that a client can (and indeed s= hould) re-use nonces across multiple allocations:=20 If the client has not completed a successful request/response transaction with the server (as identified by hostname, if the DNS procedures of Section 9 are used, else IP address if not), it SHOULD omit the USERNAME, MESSAGE-INTEGRITY, REALM, and NONCE attributes. In other words, the very first request is sent as if there were no authentication or message integrity applied. Once a request/response transaction has completed successfully, the client will have been presented a realm and nonce by the server, and selected a username and password with which it authenticated. The client SHOULD cache the username, password, realm, and nonce for subsequent communications with the server. When the client sends a subsequent request, it SHOULD include the USERNAME, REALM, and NONCE attributes with these cached values. It SHOULD include a MESSAGE- INTEGRITY attribute, computed as described in Section 15.4 using the cached password. Since it says that a client identifies a server by hostname or IP address, = I interpreted this to mean that the client SHOULD use the nonce established= in setting up one allocation to authenticate itself for other allocations = on the same server. However, Oleg's implementation doesn't do this, requiring a separate nonce = for each allocation, and he cites this text from RFC 2617 (cited normativel= y by RFC 5389) as justification: "server is free to construct the nonce such that it may only be used from a particular client, for a particular resource, for a limited period of time or number of uses, or any other restrictions. Doing so strengthens the protection provided against, for example, replay attacks". So -- is Oleg's server indeed within its rights, here? It results in an ex= tra round-trip per allocation, which can be problematic if a client has a l= arge number of allocations it needs to set up. Relatedly: what should a server do when presented with a nonce it's never b= efore encountered? RFC 5389 specifies 438 as the error code when a nonce i= s "no longer valid", but doesn't say what to do when a nonce is one that th= e server has never sent. I argue that this should also result in a 438 -- = with a new nonce -- or else the client state machine can get stuck, but the= spec doesn't currently say this. (rfc5766-turn-server currently returns 4= 01 in this case.) From nobody Wed Feb 19 09:47:10 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305F21A0249 for ; Wed, 19 Feb 2014 09:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 CbxtzdS3GT6l for ; Wed, 19 Feb 2014 09:47:07 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0026B1A03CE for ; Wed, 19 Feb 2014 09:47:06 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAPXsBFOHCzIm/2dsb2JhbABWA4JlIThXv3mBGRZ0giUBAQEBAwEBAQ8VEzQEEwQCAQgNBAQBAQsUCQcnCxQJCAIEARIIGodjAQyhZqwYF44zIRcGC4MTgRQEmWKFPYs1gy2BaCQe X-IronPort-AV: E=Sophos;i="4.97,507,1389762000"; d="scan'208";a="43542366" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Feb 2014 12:47:02 -0500 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 19 Feb 2014 12:34:04 -0500 Received: from AZ-US1EXMB06.global.avaya.com ([fe80::38da:dafb:7358:e6f5]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0174.001; Wed, 19 Feb 2014 12:47:00 -0500 From: "Yoakum, John H (John)" To: Simon Perreault , "tram@ietf.org" Thread-Topic: [tram] IPv4 and IPv6 allocations Thread-Index: AQHPLYfCF1sa7J708UqHyNHj1pugzJq9G8kAgAAPoQCAAAHCAIAABuuA///wSYCAAARSAP//r8pQ Date: Wed, 19 Feb 2014 17:46:59 +0000 Message-ID: <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> In-Reply-To: <5304E9AE.5070202@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/myQnEXfnH-GILcUuSenUyqIbYPE Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 17:47:09 -0000 +1 I love out of the box thinking! Not sure what could go wrong but worth thi= nking about. Also it might be interesting to explore if there is any role = for IPv6 temporary addresses in relation to media flows. Cheers, John AVAYA 1.919.425.8446=20 -----Original Message----- From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault Sent: Wednesday, February 19, 2014 12:28 PM To: tram@ietf.org Subject: Re: [tram] IPv4 and IPv6 allocations Here's a crazy idea: why not have servers unconditionally create an IPv4 *and* an IPv6 allocation on any Allocate request? No need for a new paramet= er. What could go wrong? After all, we want clients to support dual-stack. = This could actually help clients do it "by default" without having to creat= e multiple TURN sessions. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 19 10:04:56 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0DF1A01FB for ; Wed, 19 Feb 2014 10:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 lcA27zCSrHHJ for ; Wed, 19 Feb 2014 10:04:53 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3341A00B8 for ; Wed, 19 Feb 2014 10:04:53 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wo20so834380obc.28 for ; Wed, 19 Feb 2014 10:04:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jqORnr+xzUnmqM87PheXZ3uq+VpZnpa2qvIJFuOTYtU=; b=LXSYOoz7sis3pN1XT9MTFP++WtmNW/1HqLNaGO2xaEDtV9eGWjn695+FUUJa9f6sO9 RyoOOebdsDA2b+6TktI7sn+Q3eHT4cNb0Mz7ofF4EbkCKatISmAu+GwRo3VPhephqNmW 1cgJcY0ZeNt/THxnWK5dpO+NQr6J+7KmgG2aeNh4JRyE+aV2UI6WjVpnQSwLJoblUw+c 5Q2IrkBDZ9viy7Qp1ltrU2NeGmUypWkM3c7PhjpKEW2e1EKSFC5UQOQGFQmsX76DN2S/ QJALHBVQsTQ49QHJ5nH999VI81rgfrUuyim3wCcxeHlSzLMvgxI4vZj9agQV/ce4mzsF m9PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jqORnr+xzUnmqM87PheXZ3uq+VpZnpa2qvIJFuOTYtU=; b=AVFBZcFM3L+H/VG1I92GrPpTL9E/3xtN8q5wKDZSIDX574JQeWTTUFvnHQyMcASPIQ YZuHOi1V00vDOBl5yF6TLrV3PkcebQJARmsqJBKl7fsj5cd1AL04H4dy9Jqn6j6GuP6Z XC368F9hshwauyG8hhK9UAX8mMzsaCUVJg9zzoC/pctLhTI3VEDW4LvguhnPPWzO6vbx iAhrb8XPDMv7JZuZOUDHAzery9gP1xEQCRnUWErFTnGbSK8vFAPrwOw6Qc3TL6tzqRFJ AquLSqD6r2whNCRj8QAVN7XqwdThHTo81ovt8Rt+OcM2Y7rfR10Cm8d2Liv8dD2JmGa1 zY8g== X-Gm-Message-State: ALoCoQnS9Ip6kJ+HHuWqxPI7bCIF8uN4sRqlOPMxJLHoTJKOWUxOPIKkVFoQHOduyBYb/9kc0dhL5l/fwPLN1s71HJCldjT6Qs8jU4f5OZ5X+oDiWOgiZeJuiXCmFKWCWtKjnuv3Sg6+4/eJEaw1lY+/Ky8EMvtbFN1YfchQ+nkmLqTMpXuVZ141yXT2kEfiN846UetBZ+vx X-Received: by 10.182.16.33 with SMTP id c1mr32792677obd.4.1392833089674; Wed, 19 Feb 2014 10:04:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.246.102 with HTTP; Wed, 19 Feb 2014 10:04:29 -0800 (PST) In-Reply-To: <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> From: Mallinath Bareddy Date: Wed, 19 Feb 2014 10:04:29 -0800 Message-ID: To: "Yoakum, John H (John)" Content-Type: multipart/alternative; boundary=f46d04479f938ad91404f2c6395e Archived-At: http://mailarchive.ietf.org/arch/msg/tram/wrL1IIKbr6cCDXzIxpWahMCyqVM Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 18:04:55 -0000 --f46d04479f938ad91404f2c6395e Content-Type: text/plain; charset=UTF-8 +1 On Wed, Feb 19, 2014 at 9:46 AM, Yoakum, John H (John) wrote: > +1 > I love out of the box thinking! Not sure what could go wrong but worth > thinking about. Also it might be interesting to explore if there is any > role for IPv6 temporary addresses in relation to media flows. > > > Cheers, > John > > AVAYA > 1.919.425.8446 > > > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault > Sent: Wednesday, February 19, 2014 12:28 PM > To: tram@ietf.org > Subject: Re: [tram] IPv4 and IPv6 allocations > > Here's a crazy idea: why not have servers unconditionally create an IPv4 > *and* an IPv6 allocation on any Allocate request? No need for a new > parameter. What could go wrong? After all, we want clients to support > dual-stack. This could actually help clients do it "by default" without > having to create multiple TURN sessions. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --f46d04479f938ad91404f2c6395e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1


On Wed, Feb 19, 2014 at 9:46 AM, Yoakum, John H (John) <yo= akum@avaya.com> wrote:
+1
I love out of the box thinking! =C2=A0Not sure what could go wrong but wort= h thinking about. =C2=A0Also it might be interesting to explore if there is= any role for IPv6 temporary addresses in relation to media flows.


Cheers,
John

AVAYA
1.919.425.8446


-----Original Message-----
From: tram [mailto:tram-bounces@ie= tf.org] On Behalf Of Simon Perreault
Sent: Wednesday, February 19, 2014 12:28 PM
To: tram@ietf.org
Subject: Re: [tram] IPv4 and IPv6 allocations

Here's a crazy idea: why not have servers unconditionally create an IPv= 4
*and* an IPv6 allocation on any Allocate request? No need for a new paramet= er. What could go wrong? After all, we want clients to support dual-stack. = This could actually help clients do it "by default" without havin= g to create multiple TURN sessions.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://numb.viagenie.ca=

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--f46d04479f938ad91404f2c6395e-- From nobody Wed Feb 19 10:08:00 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4601A04D8 for ; Wed, 19 Feb 2014 10:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 7tSWWMs-8_Jv for ; Wed, 19 Feb 2014 10:07:53 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id BE5C51A01FB for ; Wed, 19 Feb 2014 10:07:53 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kx10so724041pab.35 for ; Wed, 19 Feb 2014 10:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=im/qF/cyPgQ6PexoQLaZxHMSHNx42IcpHMU3JPmlnUk=; b=K2yv3QSRTeo1/zNrrpkbtlEy0HZsZ8gI0n0oN0oGQKiMYJIjVVGmZGSK5IRcyg0MVx CbpTKPq2Z3SFq6mHcYmkDLTD4B4Q8SEudqpkda0oOszUDQl7Sn/w6XgMkzj4xWrk9Jyb zY6VT9hJ2JjlL5dP1eou1LM4lihNlH2cUJalFmI49pG+ORfnPcUH2tE7G2uluPQkbDB8 QaBJ53EGwNn2mvBFZiGt3j3souQ5lrF8qfCOx5MTvCeL1nmto5ZdFISm77P0sUdgYXef pt6vcVtf19dQuUcQt1F8V/dddiWw7VhJmvi0ap5w/L4cjnuBBw/tqXi9NgZDBm4C+y5u WZhg== X-Received: by 10.66.122.36 with SMTP id lp4mr3890997pab.82.1392833270598; Wed, 19 Feb 2014 10:07:50 -0800 (PST) Received: from [10.182.108.171] (235.sub-70-197-17.myvzw.com. [70.197.17.235]) by mx.google.com with ESMTPSA id yo9sm6273921pab.16.2014.02.19.10.07.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 10:07:49 -0800 (PST) References: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2303FA28-AC7A-4B7A-8E39-40FDF9ED9415@gmail.com> X-Mailer: iPhone Mail (10B350) From: Oleg Moskalenko Date: Wed, 19 Feb 2014 10:07:49 -0800 To: Jonathan Lennox Archived-At: http://mailarchive.ietf.org/arch/msg/tram/KjrgbjYD1UvlQGVYzhoIhnh7Ulo Cc: "tram@ietf.org" Subject: Re: [tram] Sharing nonces across allocations - allowed? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 18:07:56 -0000 Johnathan you cannot violate the wording of the original rfc 2617. That is s= aying "for a particular resource". An allocation is a resource. So we can li= mit nonce to a single allocation.=20 That must not be a problem for a clean client implementation. I believe that= stun-bis must clarify that. With your approach there is a logical inconsistency. What is "client" in you= case ? Same program ? Different program in the same system ? Different syst= em with the same username ? It opens a can of worms. How about different thr= eads, virtual machines etc - are they the same client ? Each allocation must be treated independently from other allocations , that w= ould allow consistent processing. Also, we have to think about security. Your proposal would make the intruder= s tasks easier. Sent from my iPhone On Feb 19, 2014, at 9:36 AM, Jonathan Lennox wrote: > So Oleg and I were having an argument in the rfc5766-turn-server bug track= er about whether it's valid to share nonces across TURN allocations. (See <= http://code.google.com/p/rfc5766-turn-server/issues/detail?id=3D107>). >=20 > I argued that this text from RFC 5389 means that a client can (and indeed s= hould) re-use nonces across multiple allocations:=20 >=20 > If the client has not completed a successful request/response > transaction with the server (as identified by hostname, if the DNS > procedures of Section 9 are used, else IP address if not), it SHOULD > omit the USERNAME, MESSAGE-INTEGRITY, REALM, and NONCE attributes. > In other words, the very first request is sent as if there were no > authentication or message integrity applied. >=20 > Once a request/response transaction has completed successfully, the > client will have been presented a realm and nonce by the server, and > selected a username and password with which it authenticated. The > client SHOULD cache the username, password, realm, and nonce for > subsequent communications with the server. When the client sends a > subsequent request, it SHOULD include the USERNAME, REALM, and NONCE > attributes with these cached values. It SHOULD include a MESSAGE- > INTEGRITY attribute, computed as described in Section 15.4 using the > cached password. >=20 > Since it says that a client identifies a server by hostname or IP address,= I interpreted this to mean that the client SHOULD use the nonce established= in setting up one allocation to authenticate itself for other allocations o= n the same server. >=20 > However, Oleg's implementation doesn't do this, requiring a separate nonce= for each allocation, and he cites this text from RFC 2617 (cited normativel= y by RFC 5389) as justification: >=20 > "server is free to construct the nonce such that it may only be used > from a particular client, for a particular resource, for a limited > period of time or number of uses, or any other restrictions. Doing > so strengthens the protection provided against, for example, replay > attacks". >=20 > So -- is Oleg's server indeed within its rights, here? It results in an e= xtra round-trip per allocation, which can be problematic if a client has a l= arge number of allocations it needs to set up. >=20 >=20 > Relatedly: what should a server do when presented with a nonce it's never b= efore encountered? RFC 5389 specifies 438 as the error code when a nonce is= "no longer valid", but doesn't say what to do when a nonce is one that the s= erver has never sent. I argue that this should also result in a 438 -- with= a new nonce -- or else the client state machine can get stuck, but the spec= doesn't currently say this. (rfc5766-turn-server currently returns 401 in t= his case.) >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 19 10:26:02 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2F11A04E7 for ; Wed, 19 Feb 2014 10:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 KQyZAtFzXOmv for ; Wed, 19 Feb 2014 10:25:58 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA751A01FB for ; Wed, 19 Feb 2014 10:25:57 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id rd3so749672pab.33 for ; Wed, 19 Feb 2014 10:25:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=013ky5fRr1QHqPbZHx+Jzryzltf1+C3Uvv7nBuGtGVc=; b=lm7n5OVWH8M04XpzjCz68gc4o0jtyk+KZoJV73zomg8prLYGWDpBTtWa9fzc9zQNXN FgbyWiqUdbQ94hdIDGzhZp6sJTYPG1io2TpTqghwB49P1dJrZFP70rFZyhF0SjGamyBh fKXW8LcVDd694g7nfNXlJf71TSEfOpOqIGLI2HVpqoeLQ3QLqFZygmEW2kIFciVZec7P cnj5Cul2vomaE423s6HNi5T5htIhPayrzxERUCwdupWzhQtCzh4Th7scLYkkfTGzikVW kJMMvwxBSZh6A4q3fRuJGMc8IWxHjVWJRDQ3tQGhLfzHINP2qwQl+8kGjJuROhAqS23E POtQ== X-Received: by 10.68.247.201 with SMTP id yg9mr3915030pbc.148.1392834354812; Wed, 19 Feb 2014 10:25:54 -0800 (PST) Received: from [10.182.108.171] (235.sub-70-197-17.myvzw.com. [70.197.17.235]) by mx.google.com with ESMTPSA id eo11sm6719506pac.0.2014.02.19.10.25.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 10:25:53 -0800 (PST) References: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B350) From: Oleg Moskalenko Date: Wed, 19 Feb 2014 10:25:52 -0800 To: Jonathan Lennox Archived-At: http://mailarchive.ietf.org/arch/msg/tram/zFQGg56QA9ZfUZ2-6yHWPMWrmAM Cc: "tram@ietf.org" Subject: Re: [tram] Sharing nonces across allocations - allowed? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 18:26:01 -0000 Also consider a situation when an intruder is behind the same nat as the rea= l client. If the nonces can be reused then the intruder can just replay the o= riginal allocation request and get a new allocation.=20 Stronger nonce usage pattern prevent that replay problem. You cannot say tha= t the stun rfc does not allow stronger nonces. Also look at nonces in SIP worlds, for example. There are implementations wi= th unique nonces per session. Sent from my iPhone On Feb 19, 2014, at 9:36 AM, Jonathan Lennox wrote: > So Oleg and I were having an argument in the rfc5766-turn-server bug track= er about whether it's valid to share nonces across TURN allocations. (See <= http://code.google.com/p/rfc5766-turn-server/issues/detail?id=3D107>). >=20 > I argued that this text from RFC 5389 means that a client can (and indeed s= hould) re-use nonces across multiple allocations:=20 >=20 > If the client has not completed a successful request/response > transaction with the server (as identified by hostname, if the DNS > procedures of Section 9 are used, else IP address if not), it SHOULD > omit the USERNAME, MESSAGE-INTEGRITY, REALM, and NONCE attributes. > In other words, the very first request is sent as if there were no > authentication or message integrity applied. >=20 > Once a request/response transaction has completed successfully, the > client will have been presented a realm and nonce by the server, and > selected a username and password with which it authenticated. The > client SHOULD cache the username, password, realm, and nonce for > subsequent communications with the server. When the client sends a > subsequent request, it SHOULD include the USERNAME, REALM, and NONCE > attributes with these cached values. It SHOULD include a MESSAGE- > INTEGRITY attribute, computed as described in Section 15.4 using the > cached password. >=20 > Since it says that a client identifies a server by hostname or IP address,= I interpreted this to mean that the client SHOULD use the nonce established= in setting up one allocation to authenticate itself for other allocations o= n the same server. >=20 > However, Oleg's implementation doesn't do this, requiring a separate nonce= for each allocation, and he cites this text from RFC 2617 (cited normativel= y by RFC 5389) as justification: >=20 > "server is free to construct the nonce such that it may only be used > from a particular client, for a particular resource, for a limited > period of time or number of uses, or any other restrictions. Doing > so strengthens the protection provided against, for example, replay > attacks". >=20 > So -- is Oleg's server indeed within its rights, here? It results in an e= xtra round-trip per allocation, which can be problematic if a client has a l= arge number of allocations it needs to set up. >=20 >=20 > Relatedly: what should a server do when presented with a nonce it's never b= efore encountered? RFC 5389 specifies 438 as the error code when a nonce is= "no longer valid", but doesn't say what to do when a nonce is one that the s= erver has never sent. I argue that this should also result in a 438 -- with= a new nonce -- or else the client state machine can get stuck, but the spec= doesn't currently say this. (rfc5766-turn-server currently returns 401 in t= his case.) >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 19 10:52:36 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B981A04E7 for ; Wed, 19 Feb 2014 10:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 f-XsJ3TMFNYv for ; Wed, 19 Feb 2014 10:52:32 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 69C061A01F0 for ; Wed, 19 Feb 2014 10:52:32 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EEE4B403C0 for ; Wed, 19 Feb 2014 13:52:28 -0500 (EST) Message-ID: <5304FD6C.2010907@viagenie.ca> Date: Wed, 19 Feb 2014 13:52:28 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> In-Reply-To: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/-B_hkexoaK8td3GELRJINYyBAOs Subject: Re: [tram] Sharing nonces across allocations - allowed? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 18:52:34 -0000 Le 2014-02-19 12:36, Jonathan Lennox a écrit : > Since it says that a client identifies a server by hostname or IP address, I interpreted this to mean that the client SHOULD use the nonce established in setting up one allocation to authenticate itself for other allocations on the same server. Well, your client may try it, in an attempt to save a round-trip, but it still has no idea for how long a nonce is going to be valid. The server has absolute authority to declare a nonce stale whenever it wants, and the client must be ready for it. There's also this: For each allocation, the server SHOULD generate a new random nonce when the allocation is first attempted following the randomness recommendations in [RFC4086] I suppose it could be interpreted either way, but I understand the above to mean that previous nonces are expired when the new one is generated. > Relatedly: what should a server do when presented with a nonce it's never before encountered? Servers are not required to remember the nonces they generate. They can use HMAC magic to detect invalid/expired nonces. (FWIW, that's what our server, Numb, does.) I suppose we could define a new "invalid nonce" error code in STUN-bis. However, there would no point to doing that unless it resulted in different client behaviour. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Feb 19 11:47:08 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B201A04D6 for ; Wed, 19 Feb 2014 11:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 lq5fXAv23pDs for ; Wed, 19 Feb 2014 11:47:04 -0800 (PST) Received: from server209.appriver.com (server209c.appriver.com [8.31.233.118]) by ietfa.amsl.com (Postfix) with ESMTP id DD5731A0135 for ; Wed, 19 Feb 2014 11:47:03 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/19/2014 2:46:59 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-126/SG:2 2/19/2014 2:46:19 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.804398 p=-0.952749 Source White X-Signature-Violations: 0-0-0-8663-c X-Note-419: 15.6005 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/19/2014 2:46:49 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 99349346; Wed, 19 Feb 2014 14:46:59 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Wed, 19 Feb 2014 13:46:57 -0600 From: Jonathan Lennox To: Oleg Moskalenko Thread-Topic: [tram] Sharing nonces across allocations - allowed? Thread-Index: AQHPLZklI/mstGT3gUGmj+XPt51ctZq9SW0AgAAWp4A= Date: Wed, 19 Feb 2014 19:46:57 +0000 Message-ID: <2504152D-287E-44DD-8184-8E68EDB08792@vidyo.com> References: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: <62E3E6EC63F5EE4FAC028383728BB92B@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/aYpJ4RviCUehR6URJs09zp-WZpU Cc: "tram@ietf.org" Subject: Re: [tram] Sharing nonces across allocations - allowed? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:47:06 -0000 On Feb 19, 2014, at 1:25 PM, Oleg Moskalenko wrote: > Also consider a situation when an intruder is behind the same nat as the = real client. If the nonces can be reused then the intruder can just replay = the original allocation request and get a new allocation.=20 >=20 > Stronger nonce usage pattern prevent that replay problem. You cannot say = that the stun rfc does not allow stronger nonces. Yes, that=92s a good point =97 thinking about that case, this forces a per-= allocation challenge/response, which does prevent that attack. I agree this needs to be clarified in STUN-bis, though. > Also look at nonces in SIP worlds, for example. There are implementations= with unique nonces per session. >=20 > Sent from my iPhone >=20 > On Feb 19, 2014, at 9:36 AM, Jonathan Lennox wrote: >=20 >> So Oleg and I were having an argument in the rfc5766-turn-server bug tra= cker about whether it's valid to share nonces across TURN allocations. (Se= e ). >>=20 >> I argued that this text from RFC 5389 means that a client can (and indee= d should) re-use nonces across multiple allocations:=20 >>=20 >> If the client has not completed a successful request/response >> transaction with the server (as identified by hostname, if the DNS >> procedures of Section 9 are used, else IP address if not), it SHOULD >> omit the USERNAME, MESSAGE-INTEGRITY, REALM, and NONCE attributes. >> In other words, the very first request is sent as if there were no >> authentication or message integrity applied. >>=20 >> Once a request/response transaction has completed successfully, the >> client will have been presented a realm and nonce by the server, and >> selected a username and password with which it authenticated. The >> client SHOULD cache the username, password, realm, and nonce for >> subsequent communications with the server. When the client sends a >> subsequent request, it SHOULD include the USERNAME, REALM, and NONCE >> attributes with these cached values. It SHOULD include a MESSAGE- >> INTEGRITY attribute, computed as described in Section 15.4 using the >> cached password. >>=20 >> Since it says that a client identifies a server by hostname or IP addres= s, I interpreted this to mean that the client SHOULD use the nonce establis= hed in setting up one allocation to authenticate itself for other allocatio= ns on the same server. >>=20 >> However, Oleg's implementation doesn't do this, requiring a separate non= ce for each allocation, and he cites this text from RFC 2617 (cited normati= vely by RFC 5389) as justification: >>=20 >> "server is free to construct the nonce such that it may only be used >> from a particular client, for a particular resource, for a limited >> period of time or number of uses, or any other restrictions. Doing >> so strengthens the protection provided against, for example, replay >> attacks". >>=20 >> So -- is Oleg's server indeed within its rights, here? It results in an= extra round-trip per allocation, which can be problematic if a client has = a large number of allocations it needs to set up. >>=20 >>=20 >> Relatedly: what should a server do when presented with a nonce it's neve= r before encountered? RFC 5389 specifies 438 as the error code when a nonc= e is "no longer valid", but doesn't say what to do when a nonce is one that= the server has never sent. I argue that this should also result in a 438 = -- with a new nonce -- or else the client state machine can get stuck, but = the spec doesn't currently say this. (rfc5766-turn-server currently return= s 401 in this case.) >>=20 >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >=20 From nobody Wed Feb 19 11:47:29 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58E41A0167 for ; Wed, 19 Feb 2014 11:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 FY6-F7Ks_mTV for ; Wed, 19 Feb 2014 11:47:26 -0800 (PST) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id D2AE21A0135 for ; Wed, 19 Feb 2014 11:47:25 -0800 (PST) X-Note-AR-ScanTimeLocal: 2/19/2014 2:47:22 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-126/SG:2 2/19/2014 2:47:19 PM X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.80444 p=-0.952769 Source White X-Signature-Violations: 0-0-0-4762-c X-Note-419: 0 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 2/19/2014 2:47:09 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.214 X-Note-Reverse-DNS: X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 99349546; Wed, 19 Feb 2014 14:47:22 -0500 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Wed, 19 Feb 2014 13:47:21 -0600 From: Jonathan Lennox To: Simon Perreault Thread-Topic: [tram] Sharing nonces across allocations - allowed? Thread-Index: AQHPLZklI/mstGT3gUGmj+XPt51ctZq9UNsAgAAPVoA= Date: Wed, 19 Feb 2014 19:47:21 +0000 Message-ID: <268FF716-1A3F-49F5-871A-9DBAB7BED28F@vidyo.com> References: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> <5304FD6C.2010907@viagenie.ca> In-Reply-To: <5304FD6C.2010907@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/NA918Ix-GAJN9YOt9GSFPagYopM Cc: "tram@ietf.org" Subject: Re: [tram] Sharing nonces across allocations - allowed? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:47:28 -0000 On Feb 19, 2014, at 1:52 PM, Simon Perreault = wrote: > Le 2014-02-19 12:36, Jonathan Lennox a =E9crit : >> Since it says that a client identifies a server by hostname or IP addres= s, I interpreted this to mean that the client SHOULD use the nonce establis= hed in setting up one allocation to authenticate itself for other allocatio= ns on the same server. >=20 > Well, your client may try it, in an attempt to save a round-trip, but it > still has no idea for how long a nonce is going to be valid. The server > has absolute authority to declare a nonce stale whenever it wants, and > the client must be ready for it. Sure, absolutely. > There's also this: >=20 > For each allocation, the server SHOULD generate a new > random nonce when the allocation is first attempted following the > randomness recommendations in [RFC4086] >=20 > I suppose it could be interpreted either way, but I understand the above > to mean that previous nonces are expired when the new one is generated. That also makes sense to me. >> Relatedly: what should a server do when presented with a nonce it's neve= r before encountered? >=20 > Servers are not required to remember the nonces they generate. They can > use HMAC magic to detect invalid/expired nonces. (FWIW, that's what our > server, Numb, does.) >=20 > I suppose we could define a new "invalid nonce" error code in STUN-bis. > However, there would no point to doing that unless it resulted in > different client behaviour. Right, I think this should be the 438; I can=92t think of any reason to wan= t client behavior to be different for expired nonces and invalid nonces. (= And, as you say, the server can=92t always distinguish them.) But right no= w the spec only says what to do for expired nonces.=20 From nobody Wed Feb 19 11:51:15 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D531A0535 for ; Wed, 19 Feb 2014 11:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 XI634bKuvWOE for ; Wed, 19 Feb 2014 11:51:11 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id C7AEE1A051B for ; Wed, 19 Feb 2014 11:51:11 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rq2so849742pbb.9 for ; Wed, 19 Feb 2014 11:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PDx8Q7M67wB2b31DP6F5gl/CmrCs0nzOYbhQHpuFezY=; b=QF8og14MKTYYaYy7txGbN6ga87jekUHdsZhOwpGicPgveUIXxPCcp/piYCTJzFLjqy DU6Pp+P1UURxmuwjQ9NRj7wljikjqbA9R734rY5JPPYDAETml3w98OS8Avo65JQx087g iJUHZCUKtJJY2Zhr/nliQcLyfq0/MrjoUfu7ljWF0fKSewHUIcctIKr0362Iz0sp2g6W udOFf6nDYXa/rV3RMhJiG++io1o5EFwfn8BwCzkxoyDqswvmKJXA+vWmLEzk7G5FxeFs mg9RGkJLI7t7+saL9+LL+1znnVdlVyGqw2foK4hW/f4brvjd8AN4Nb4yJlDNae0LnIX7 eEUw== MIME-Version: 1.0 X-Received: by 10.68.171.4 with SMTP id aq4mr4311971pbc.150.1392839468597; Wed, 19 Feb 2014 11:51:08 -0800 (PST) Received: by 10.68.147.131 with HTTP; Wed, 19 Feb 2014 11:51:08 -0800 (PST) In-Reply-To: <5304FD6C.2010907@viagenie.ca> References: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> <5304FD6C.2010907@viagenie.ca> Date: Wed, 19 Feb 2014 11:51:08 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7bacbb48c1472004f2c7b500 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/MSxbw6qcArKPRPmP_2i9mvjGV8A Cc: "tram@ietf.org" Subject: Re: [tram] Sharing nonces across allocations - allowed? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:51:14 -0000 --047d7bacbb48c1472004f2c7b500 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Simon for the insight. That was helpful for the clarification. I just checked how the industry is using the nonces. SIP is using the same RFC 2617 guideline. I checked several "blueprint" SIP stack implementations (which are used for the verification of the production SIP implementations). They all are using unique-per-session nonces. SIP uses the same nonce standards as TURN; so I assume that the industry is consolidated behind the more secure nonce option. I've never heard that anybody ever complained about that. The problem is that some older initial TURN server implementations used single nonce per TURN server. And there were several client libraries written which explored that - and which expected that behavior. Now we have a "backward compatibility" problem when the newer TURN servers enforce stricter standards but the client libraries are incompatible. We have had this issue multiple time thru the life of our TURN server, there are endless requests to tweak the implementation so that the older substandard clients can be used. In our TURN server, we do remember the older nonces. But we limit the scope of the nonce per separate session - just like the SIP implementations which I am familiar with. One thing that I can change is that if the client sends a nonce with the initial allocation, we can return the value 438 ("stale nonce"). Currently we just ignore nonce in the initial allocation and we return 401. A new "illegal nonce" code would be more definite outcome but I am not sure that it is necessary. Regards, Oleg On Wed, Feb 19, 2014 at 10:52 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-02-19 12:36, Jonathan Lennox a =E9crit : > > Since it says that a client identifies a server by hostname or IP > address, I interpreted this to mean that the client SHOULD use the nonce > established in setting up one allocation to authenticate itself for other > allocations on the same server. > > Well, your client may try it, in an attempt to save a round-trip, but it > still has no idea for how long a nonce is going to be valid. The server > has absolute authority to declare a nonce stale whenever it wants, and > the client must be ready for it. > > There's also this: > > For each allocation, the server SHOULD generate a new > random nonce when the allocation is first attempted following the > randomness recommendations in [RFC4086] > > I suppose it could be interpreted either way, but I understand the above > to mean that previous nonces are expired when the new one is generated. > > > Relatedly: what should a server do when presented with a nonce it's > never before encountered? > > Servers are not required to remember the nonces they generate. They can > use HMAC magic to detect invalid/expired nonces. (FWIW, that's what our > server, Numb, does.) > > I suppose we could define a new "invalid nonce" error code in STUN-bis. > However, there would no point to doing that unless it resulted in > different client behaviour. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7bacbb48c1472004f2c7b500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Simon for the insight. Tha= t was helpful for the clarification.

I just checked how the i= ndustry is using the nonces. SIP is using the same RFC 2617 guideline. I ch= ecked several "blueprint" SIP stack implementations (which are us= ed for the verification of the production SIP implementations). They all ar= e using unique-per-session nonces. SIP uses the same nonce standards as TUR= N; so I assume that the industry is consolidated behind the more secure non= ce option. I've never heard that anybody ever complained about that.
The problem is that some older initial TURN server implementation= s used single nonce per TURN server. And there were several client librarie= s written which explored that - and which expected that behavior. Now we ha= ve a "backward compatibility" problem when the newer TURN servers= enforce stricter standards but the client libraries are incompatible.

We have had this issue multiple time thru the life of our TURN se= rver, there are endless requests to tweak the implementation so that the ol= der substandard clients can be used.

In our TURN server,= we do remember the older nonces. But we limit the scope of the nonce per s= eparate session - just like the SIP implementations which I am familiar wit= h.

One thing that I can change is that if the client sends a nonce w= ith the initial allocation, we can return the value 438 ("stale nonce&= quot;). Currently we just ignore nonce in the initial allocation and we ret= urn 401. A new "illegal nonce" code would be more definite outcom= e but I am not sure that it is necessary.

Regards,
Oleg




On Wed, Feb= 19, 2014 at 10:52 AM, Simon Perreault <simon.perreault@viagenie= .ca> wrote:
Le 2014-02-19 12:36, Jonathan Lennox a =E9cr= it :
> Since it says that a client identifies a server by h= ostname or IP address, I interpreted this to mean that the client SHOULD us= e the nonce established in setting up one allocation to authenticate itself= for other allocations on the same server.

Well, your client may try it, in an attempt to save a round-trip, but= it
still has no idea for how long a nonce is going to be valid. The server
has absolute authority to declare a nonce stale whenever it wants, and
the client must be ready for it.

There's also this:

=A0 =A0For each allocation, the server SHOULD generate a new
=A0 =A0random nonce when the allocation is first attempted following the =A0 =A0randomness recommendations in [RFC4086]

I suppose it could be interpreted either way, but I understand the above to mean that previous nonces are expired when the new one is generated.

> Relatedly: what should a server do when presented with a nonce it'= s never before encountered?

Servers are not required to remember the nonces they generate. They c= an
use HMAC magic to detect invalid/expired nonces. (FWIW, that's what our=
server, Numb, does.)

I suppose we could define a new "invalid nonce" error code in STU= N-bis.
However, there would no point to doing that unless it resulted in
different client behaviour.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7bacbb48c1472004f2c7b500-- From nobody Wed Feb 19 11:55:19 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11E31A05FA for ; Wed, 19 Feb 2014 11:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 3ovNe6pRsBsN for ; Wed, 19 Feb 2014 11:55:16 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 74CD01A0501 for ; Wed, 19 Feb 2014 11:55:14 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so804536pde.20 for ; Wed, 19 Feb 2014 11:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Rd5uWhCi8BrjF0lD4Ub4PrKrxKNFu9L7NTyQLaMiQ3I=; b=liqHLJDZJXHWvZKC+WNXBiXzdp2zKygXoxC/yYYoi7Ipo77g8s8tS0XGH5TWLq3NBk qDFQaEMnYIkiN1iphmSfGEY6+3Qv5JmPft7jcB/1D0l9orMKxkgYUdPfstDpLwky7AzI v2f5z0Ocq71XVKj/AkSXH7mjyr5iwbqHuXKtSZih3Wg4U3XqEpsUxZcJL2BsN8s/2/SE LUF+CGg4645o4W6OFcBEFxPBgv9OpaNzMUTQNbp5T9KDN/v4RRKm1r/yw7fE2g5PyjXM bEcRhykXTgXoj9IV0ly7QJsZb2Zw2qS1j+YO+C6mY7jDeOOVChRs+QT3RHb2gOYYip4H r0Tw== MIME-Version: 1.0 X-Received: by 10.66.148.134 with SMTP id ts6mr4269227pab.113.1392839711310; Wed, 19 Feb 2014 11:55:11 -0800 (PST) Received: by 10.68.147.131 with HTTP; Wed, 19 Feb 2014 11:55:11 -0800 (PST) In-Reply-To: <268FF716-1A3F-49F5-871A-9DBAB7BED28F@vidyo.com> References: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> <5304FD6C.2010907@viagenie.ca> <268FF716-1A3F-49F5-871A-9DBAB7BED28F@vidyo.com> Date: Wed, 19 Feb 2014 11:55:11 -0800 Message-ID: From: Oleg Moskalenko To: Jonathan Lennox Content-Type: multipart/alternative; boundary=047d7b67830038c8fe04f2c7c4ce Archived-At: http://mailarchive.ietf.org/arch/msg/tram/LQYI8ltf3T4dCsBbn8kZOuNdc0g Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] Sharing nonces across allocations - allowed? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:55:18 -0000 --047d7b67830038c8fe04f2c7c4ce Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 19, 2014 at 11:47 AM, Jonathan Lennox wrote: > > > Right, I think this should be the 438; I can't think of any reason to want > client behavior to be different for expired nonces and invalid nonces. > (And, as you say, the server can't always distinguish them.) But right > now the spec only says what to do for expired nonces. > > _ > OK, I agree with that. Now let's hope that the change will not brake some other TURN client implementations... --047d7b67830038c8fe04f2c7c4ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 19, 2014 at 11:47 AM, Jonathan Lennox <jonathan@vidyo= .com> wrote:


Right, I think this should be the 438; I can’t think of any= reason to want client behavior to be different for expired nonces and inva= lid nonces.  (And, as you say, the server can’t always distingui= sh them.)  But right now the spec only says what to do for expired non= ces.

_

OK, I agree with that.

=
Now let's hope that the change will no= t brake some other TURN client implementations...


--047d7b67830038c8fe04f2c7c4ce-- From nobody Wed Feb 19 11:56:20 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C8F1A04EA for ; Wed, 19 Feb 2014 11:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 6JZfYB1jL6XB for ; Wed, 19 Feb 2014 11:56:17 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id E5FAA1A04C1 for ; Wed, 19 Feb 2014 11:56:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4570; q=dns/txt; s=iport; t=1392839773; x=1394049373; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TFoiPXutCBxq2qpOgQLyp07W9cONBbMd7nMkhygfZn8=; b=EzCeHy0gSUP+t+dma9o40dnT74qZWZ5KgzwPADyVl07Ajk6zZar1cXPs /KN564NqB0p4z/LSWQd0eR0xiZ1tbTKNmax1303NRbAQOg2jGLWIYTXON 0ffIdixVMIpKMeuQ9HBe4jREq4a27NOCJh/K7hf/+rNSBCVmkXqhzxH/X I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJMLBVOtJXG//2dsb2JhbABZgwY4V8AFgRwWdIIlAQEBAwEBAQFrCxACAQgYGAwKIQYLJQIEDgWHcQMJCA2xAZUpDYdwF4xPgT0lMwcYgwyBFASWRIFsgTKLLIVGgy2BaEI X-IronPort-AV: E=Sophos;i="4.97,507,1389744000"; d="scan'208";a="21677557" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 19 Feb 2014 19:56:13 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1JJuD9W024385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 19:56:13 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 13:56:13 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Jonathan Lennox Thread-Topic: [tram] Sharing nonces across allocations - allowed? Thread-Index: AQHPLZklI/mstGT3gUGmj+XPt51ctZq9SW0AgAAWp4CAAAKWAA== Date: Wed, 19 Feb 2014 19:56:12 +0000 Message-ID: <392B546F-C992-499D-AF5B-512C56CF35D5@cisco.com> References: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> <2504152D-287E-44DD-8184-8E68EDB08792@vidyo.com> In-Reply-To: <2504152D-287E-44DD-8184-8E68EDB08792@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.52] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/vPwP_P37aWj4LHDQGNunKf2TwBQ Cc: Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] Sharing nonces across allocations - allowed? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:56:19 -0000 On Feb 19, 2014, at 2:46 PM, Jonathan Lennox wrote: >=20 > On Feb 19, 2014, at 1:25 PM, Oleg Moskalenko wrote: >=20 >> Also consider a situation when an intruder is behind the same nat as the= real client. If the nonces can be reused then the intruder can just replay= the original allocation request and get a new allocation.=20 >>=20 >> Stronger nonce usage pattern prevent that replay problem. You cannot say= that the stun rfc does not allow stronger nonces. >=20 > Yes, that=92s a good point =97 thinking about that case, this forces a pe= r-allocation challenge/response, which does prevent that attack. >=20 > I agree this needs to be clarified in STUN-bis, though. +1 We really should start an issues list (on a wiki or something) that we all = agree need to be addressed as part of the STUNbis and TURNbis efforts. Sin= ce these milestones are left as intentionally longer-term items, it would = be helpful when we circle back a year from now to have a list of what we le= arned working through these shorter-term milestones. -G >=20 >> Also look at nonces in SIP worlds, for example. There are implementation= s with unique nonces per session. >>=20 >> Sent from my iPhone >>=20 >> On Feb 19, 2014, at 9:36 AM, Jonathan Lennox wrote: >>=20 >>> So Oleg and I were having an argument in the rfc5766-turn-server bug tr= acker about whether it's valid to share nonces across TURN allocations. (S= ee ). >>>=20 >>> I argued that this text from RFC 5389 means that a client can (and inde= ed should) re-use nonces across multiple allocations:=20 >>>=20 >>> If the client has not completed a successful request/response >>> transaction with the server (as identified by hostname, if the DNS >>> procedures of Section 9 are used, else IP address if not), it SHOULD >>> omit the USERNAME, MESSAGE-INTEGRITY, REALM, and NONCE attributes. >>> In other words, the very first request is sent as if there were no >>> authentication or message integrity applied. >>>=20 >>> Once a request/response transaction has completed successfully, the >>> client will have been presented a realm and nonce by the server, and >>> selected a username and password with which it authenticated. The >>> client SHOULD cache the username, password, realm, and nonce for >>> subsequent communications with the server. When the client sends a >>> subsequent request, it SHOULD include the USERNAME, REALM, and NONCE >>> attributes with these cached values. It SHOULD include a MESSAGE- >>> INTEGRITY attribute, computed as described in Section 15.4 using the >>> cached password. >>>=20 >>> Since it says that a client identifies a server by hostname or IP addre= ss, I interpreted this to mean that the client SHOULD use the nonce establi= shed in setting up one allocation to authenticate itself for other allocati= ons on the same server. >>>=20 >>> However, Oleg's implementation doesn't do this, requiring a separate no= nce for each allocation, and he cites this text from RFC 2617 (cited normat= ively by RFC 5389) as justification: >>>=20 >>> "server is free to construct the nonce such that it may only be used >>> from a particular client, for a particular resource, for a limited >>> period of time or number of uses, or any other restrictions. Doing >>> so strengthens the protection provided against, for example, replay >>> attacks". >>>=20 >>> So -- is Oleg's server indeed within its rights, here? It results in a= n extra round-trip per allocation, which can be problematic if a client has= a large number of allocations it needs to set up. >>>=20 >>>=20 >>> Relatedly: what should a server do when presented with a nonce it's nev= er before encountered? RFC 5389 specifies 438 as the error code when a non= ce is "no longer valid", but doesn't say what to do when a nonce is one tha= t the server has never sent. I argue that this should also result in a 438= -- with a new nonce -- or else the client state machine can get stuck, but= the spec doesn't currently say this. (rfc5766-turn-server currently retur= ns 401 in this case.) >>>=20 >>> _______________________________________________ >>> tram mailing list >>> tram@ietf.org >>> https://www.ietf.org/mailman/listinfo/tram >>=20 >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 19 11:58:07 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E58A1A0618 for ; Wed, 19 Feb 2014 11:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 2IyE3GndMmM4 for ; Wed, 19 Feb 2014 11:58:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9556B1A05EB for ; Wed, 19 Feb 2014 11:58:04 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 35592403C0 for ; Wed, 19 Feb 2014 14:58:01 -0500 (EST) Message-ID: <53050CC8.5090409@viagenie.ca> Date: Wed, 19 Feb 2014 14:58:00 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> <2504152D-287E-44DD-8184-8E68EDB08792@vidyo.com> <392B546F-C992-499D-AF5B-512C56CF35D5@cisco.com> In-Reply-To: <392B546F-C992-499D-AF5B-512C56CF35D5@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RLXHBIFWUNMEZZPMpu3KOQbKl44 Subject: Re: [tram] Sharing nonces across allocations - allowed? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:58:06 -0000 Le 2014-02-19 14:56, Gonzalo Salgueiro (gsalguei) a écrit : > We really should start an issues list (on a wiki or something) As soon as we become a real WG (tomorrow?), we will have the IETF tools at our disposal for that! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Feb 19 11:58:59 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264DF1A04C1 for ; Wed, 19 Feb 2014 11:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 Woc5_ueV2d83 for ; Wed, 19 Feb 2014 11:58:54 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 920361A04EA for ; Wed, 19 Feb 2014 11:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7815; q=dns/txt; s=iport; t=1392839931; x=1394049531; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EgY+SAbiHNbe0tyF9O37dePHGls1YTADbZdFsJ8vDAo=; b=gJ1b15MbED9YdbvjCqzhkGN8x0F290tcrYrxGbqfLqeFo73Si+h7wbgZ SfAeyKCqHiOvRRLF8T7tvmB/Qrh66U4HkotIeKPxTfnDAo9Kl5MyFSnfH LXUXFIJTHdAybkoajpaNVwY+BQYlEHERYkHEPzdLGZsi3vwsmpmbB6tUw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIGABAMBVOtJXG//2dsb2JhbABWA4MGOFeqSoxliFaBHBZ0giUBAQEEAQEBJEcEBwwEAgEIEQQBASgHJwsUCQgCBA4FiAUNzioXjlQMBAcGAwiDE4EUBJgwgTKQcoMtgWgkHg X-IronPort-AV: E=Sophos;i="4.97,507,1389744000"; d="scan'208,217";a="305157828" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 19 Feb 2014 19:58:51 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1JJwp7M028064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 19:58:51 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 13:58:50 -0600 From: "Pal Martinsen (palmarti)" To: Mallinath Bareddy Thread-Topic: [tram] IPv4 and IPv6 allocations Thread-Index: AQHPLYfCF1sa7J708UqHyNHj1pugzJq9G8kAgAAPoQCAAAHCAIAABuuAgAABDYCAAARRAIAABT2AgAAE5ICAAB/uAA== Date: Wed, 19 Feb 2014 19:58:50 +0000 Message-ID: References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.70] Content-Type: multipart/alternative; boundary="_000_E38E346C2AEE4524B99D832337B6B678ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/KtcTwyXNMBVPtNVRWiaHm4Zb3yc Cc: Simon Perreault , "tram@ietf.org" , "Yoakum, John H \(John\)" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:58:57 -0000 --_000_E38E346C2AEE4524B99D832337B6B678ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable -1 ;-) Reading RFC5766 they use language that indicates that you will only receive= one XOR-RELAYED-ADDRESS attribute. An old client that receives two might p= ick the wrong one, and get confused since he asked for a IPv4 address and g= ot a IPv6 address. There is no way for the client to get out of that situat= ion. (Furiously checking my own TURN client implementation=85) I would like to TURN (*sigh) around.. I think it would be better for the client to include two REQUESTED-ADDRESS-= FAMILY attributes in the allocation request instead. If the server supports= that everything is fine. If the TURN server responds with only one RELAY a= ddress, the client would notice and could easily request the other address = family on a different 5-tuple. Same goes if the TURN server return an error= , the client can go back to old behaviour. The client could do some of those checks prior to all setup and would know = what the TURN server supports. But that is an implementation detail. .-. P=E5l-Erik On 19 Feb 2014, at 19:04 pm, Mallinath Bareddy > wrote: +1 On Wed, Feb 19, 2014 at 9:46 AM, Yoakum, John H (John) > wrote: +1 I love out of the box thinking! Not sure what could go wrong but worth thi= nking about. Also it might be interesting to explore if there is any role = for IPv6 temporary addresses in relation to media flows. Cheers, John AVAYA 1.919.425.8446 -----Original Message----- From: tram [mailto:tram-bounces@ietf.org] On = Behalf Of Simon Perreault Sent: Wednesday, February 19, 2014 12:28 PM To: tram@ietf.org Subject: Re: [tram] IPv4 and IPv6 allocations Here's a crazy idea: why not have servers unconditionally create an IPv4 *and* an IPv6 allocation on any Allocate request? No need for a new paramet= er. What could go wrong? After all, we want clients to support dual-stack. = This could actually help clients do it "by default" without having to creat= e multiple TURN sessions. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_E38E346C2AEE4524B99D832337B6B678ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable -1 ;-)

Reading RFC5766 they use language that indicates that you will only re= ceive one XOR-RELAYED-ADDRESS attribute. An old client that receives two mi= ght pick the wrong one, and get confused since he asked for a IPv4 address = and got a IPv6 address. There is no way for the client to get out of that situation. (Furiously checking my= own TURN client implementation=85)

I would like to TURN (*sigh) around..

I think it would be better for the client to include two REQUESTED-ADD= RESS-FAMILY attributes in the allocation request instead. If the server sup= ports that everything is fine. If the TURN server responds with only one RE= LAY address, the client would notice and could easily request the other address family on a different 5-tuple. = Same goes if the TURN server return an error, the client can go back to old= behaviour. 

The client could do some of those checks prior to all setup and would = know what the TURN server supports. But that is an implementation detail.

.-.
P=E5l-Erik
 
 
On 19 Feb 2014, at 19:04 pm, Mallinath Bareddy <mallinath@google.com> wrote:

+1


On Wed, Feb 19, 2014 at 9:46 AM, Yoakum, John H = (John) <yoakum@avaya.com<= /a>> wrote:
+1
I love out of the box thinking!  Not sure what could go wrong but wort= h thinking about.  Also it might be interesting to explore if there is= any role for IPv6 temporary addresses in relation to media flows.


Cheers,
John

AVAYA
1.919.425.8446


-----Original Message-----
From: tram [mailto:tram-bounces@ie= tf.org] On Behalf Of Simon Perreault
Sent: Wednesday, February 19, 2014 12:28 PM
To: tram@ietf.org
Subject: Re: [tram] IPv4 and IPv6 allocations

Here's a crazy idea: why not have servers unconditionally create an IPv4 *and* an IPv6 allocation on any Allocate request? No need for a new paramet= er. What could go wrong? After all, we want clients to support dual-stack. = This could actually help clients do it "by default" without havin= g to create multiple TURN sessions.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

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

--_000_E38E346C2AEE4524B99D832337B6B678ciscocom_-- From nobody Wed Feb 19 11:59:12 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24431A0618 for ; Wed, 19 Feb 2014 11:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 nBHIJXp-IvfX for ; Wed, 19 Feb 2014 11:59:09 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 31FA01A04EA for ; Wed, 19 Feb 2014 11:59:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=714; q=dns/txt; s=iport; t=1392839946; x=1394049546; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=s1bqmjpXXUqTryecD9rxwlni5s0PU9Th+rnqsSC2FWM=; b=i7IE7EfMwtkd3ukvfq1UkIP0BkVohzZxFHaNg48ONeN0LeS1l4jF/PuK BEhUYYeRAtYju0hGrB4mL1rLcigZDw8tmIRFdM/mpjS1n//qQMEM4xSzc BUSM63GMkc1TQHMd5ZKHChVMv4/t8rpnRZ8+JLOuYvQAiqZgU/A+f10Gr A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJwMBVOtJXHB/2dsb2JhbABZgwY4V8AFgRwWdIIlAQEBAwEBAQEkRwsFCwIBCEYnCyUCBA4Fh30IDc4uF44xMweDJIEUAQOYMIEykHKDLYIq X-IronPort-AV: E=Sophos;i="4.97,507,1389744000"; d="scan'208";a="21686256" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-8.cisco.com with ESMTP; 19 Feb 2014 19:59:05 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1JJx5dZ009940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Feb 2014 19:59:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 19 Feb 2014 13:59:05 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Simon Perreault Thread-Topic: [tram] Sharing nonces across allocations - allowed? Thread-Index: AQHPLZklI/mstGT3gUGmj+XPt51ctZq9SW0AgAAWp4CAAAKWAIAAAIAAgAAATQA= Date: Wed, 19 Feb 2014 19:59:05 +0000 Message-ID: <8643264F-0A7D-4854-9177-1087671C2DAE@cisco.com> References: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> <2504152D-287E-44DD-8184-8E68EDB08792@vidyo.com> <392B546F-C992-499D-AF5B-512C56CF35D5@cisco.com> <53050CC8.5090409@viagenie.ca> In-Reply-To: <53050CC8.5090409@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.52] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5645CC33409ECB45BFEE85F2250A4FA0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/9odn5VDqfT1Yqf--ixma7bvAdKU Cc: "tram@ietf.org" Subject: Re: [tram] Sharing nonces across allocations - allowed? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 19:59:10 -0000 On Feb 19, 2014, at 2:58 PM, Simon Perreault = wrote: > Le 2014-02-19 14:56, Gonzalo Salgueiro (gsalguei) a =E9crit : >> We really should start an issues list (on a wiki or something) >=20 > As soon as we become a real WG (tomorrow?), we will have the IETF tools > at our disposal for that! Perfect. -G >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 19 12:02:06 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAA81A04C1 for ; Wed, 19 Feb 2014 12:02:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 v-3e4u9VYVtD for ; Wed, 19 Feb 2014 12:02:03 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 75E9C1A04F7 for ; Wed, 19 Feb 2014 12:02:03 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id z10so807674pdj.19 for ; Wed, 19 Feb 2014 12:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bPFnKTsimCA5U6ruXrFW8L71F4H9kMCJNJOM0M6jcgw=; b=mqeDekaPfTcpNTRBDIpmZxyXYQ3uuIeSn9NMN2gGQ9aI4KOEarJhaXLUnDBFQS0d/O wyDVHBuDfMnXAsmwjD9NJrlbE7/2F0XcVjOwLD2RhrubnvteHThdW//RfabUGOB8rNQX fmze/Tr7TiyCDwZW5PLRhCDAovZajve5OG9lshmUyXSBL2fV0AMvwTJpqU5hNo3foU+X gkTr9WHq1SYFw41lJw7d1gmAmzXyBy0ZoorhDE45LBbVLzC1H3N/KgH17qVkzynX1EIV ubZsJVTwbNRCgOcrUw1G6RuwbxKvCCj5+lU4V8nlbaefcjQtq/FUa4jx3WrE1K7ziKt9 HwRg== MIME-Version: 1.0 X-Received: by 10.68.233.70 with SMTP id tu6mr3857792pbc.34.1392840120207; Wed, 19 Feb 2014 12:02:00 -0800 (PST) Received: by 10.68.147.131 with HTTP; Wed, 19 Feb 2014 12:02:00 -0800 (PST) In-Reply-To: References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> Date: Wed, 19 Feb 2014 12:02:00 -0800 Message-ID: From: Oleg Moskalenko To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=047d7b33d146980ebc04f2c7dc51 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/k2ktiVtGQqgcNsb2ar3uN3srHyg Cc: Simon Perreault , Mallinath Bareddy , "tram@ietf.org" , "Yoakum, John H \(John\)" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:02:06 -0000 --047d7b33d146980ebc04f2c7dc51 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd leave it to the future possible TURN-bis standard. I'd suggest NOT to tweak the existing TURN servers which follow RFC 5766 procedure. In the TURN-bis, we can vent it properly. On Wed, Feb 19, 2014 at 11:58 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > -1 ;-) > > Reading RFC5766 they use language that indicates that you will only > receive one XOR-RELAYED-ADDRESS attribute. An old client that receives tw= o > might pick the wrong one, and get confused since he asked for a IPv4 > address and got a IPv6 address. There is no way for the client to get out > of that situation. (Furiously checking my own TURN client implementation.= ..) > > I would like to TURN (*sigh) around.. > > I think it would be better for the client to include two > REQUESTED-ADDRESS-FAMILY attributes in the allocation request instead. If > the server supports that everything is fine. If the TURN server responds > with only one RELAY address, the client would notice and could easily > request the other address family on a different 5-tuple. Same goes if the > TURN server return an error, the client can go back to old behaviour. > > The client could do some of those checks prior to all setup and would > know what the TURN server supports. But that is an implementation detail. > > .-. > P=E5l-Erik > > > On 19 Feb 2014, at 19:04 pm, Mallinath Bareddy > wrote: > > +1 > > > On Wed, Feb 19, 2014 at 9:46 AM, Yoakum, John H (John) = wrote: > >> +1 >> I love out of the box thinking! Not sure what could go wrong but worth >> thinking about. Also it might be interesting to explore if there is any >> role for IPv6 temporary addresses in relation to media flows. >> >> >> Cheers, >> John >> >> AVAYA >> 1.919.425.8446 >> >> >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault >> Sent: Wednesday, February 19, 2014 12:28 PM >> To: tram@ietf.org >> Subject: Re: [tram] IPv4 and IPv6 allocations >> >> Here's a crazy idea: why not have servers unconditionally create an IPv4 >> *and* an IPv6 allocation on any Allocate request? No need for a new >> parameter. What could go wrong? After all, we want clients to support >> dual-stack. This could actually help clients do it "by default" without >> having to create multiple TURN sessions. >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7b33d146980ebc04f2c7dc51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'd leave it to the future possible TURN-bis standard.= I'd suggest NOT to tweak the existing TURN servers which follow RFC 57= 66 procedure. In the TURN-bis, we can vent it properly.


On Wed, Feb 19, 2014 at 11:58 AM, Pal Ma= rtinsen (palmarti) <palmarti@cisco.com> wrote:
-1 ;-)

Reading RFC5766 they use language that indicates that you will only re= ceive one XOR-RELAYED-ADDRESS attribute. An old client that receives two mi= ght pick the wrong one, and get confused since he asked for a IPv4 address = and got a IPv6 address. There is no way for the client to get out of that situation. (Furiously checking my= own TURN client implementation…)

I would like to TURN (*sigh) around..

I think it would be better for the client to include two REQUESTED-ADD= RESS-FAMILY attributes in the allocation request instead. If the server sup= ports that everything is fine. If the TURN server responds with only one RE= LAY address, the client would notice and could easily request the other address family on a different 5-tuple. = Same goes if the TURN server return an error, the client can go back to old= behaviour. 

The client could do some of those checks prior to all setup and would = know what the TURN server supports. But that is an implementation detail.

.-.
P=E5l-Erik
 
 
On 19 Feb 2014, at 19:04 pm, Mallinath Bareddy <mallinath@google.com> wrote:<= /div>
+1


On Wed, Feb 19, 2014 at 9:46 AM, Yoakum, John H = (John) <yoakum@avaya.com<= /a>> wrote:
+1
I love out of the box thinking!  Not sure what could go wrong but wort= h thinking about.  Also it might be interesting to explore if there is= any role for IPv6 temporary addresses in relation to media flows.


Cheers,
John

AVAYA
1.9= 19.425.8446


-----Original Message-----
From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Simon Perreault
Sent: Wednesday, February 19, 2014 12:28 PM
To: tram@ietf.org Subject: Re: [tram] IPv4 and IPv6 allocations

Here's a crazy idea: why not have servers unconditionally create an IPv= 4
*and* an IPv6 allocation on any Allocate request? No need for a new paramet= er. What could go wrong? After all, we want clients to support dual-stack. = This could actually help clients do it "by default" without havin= g to create multiple TURN sessions.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--047d7b33d146980ebc04f2c7dc51-- From nobody Wed Feb 19 12:06:32 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45C01A0535 for ; Wed, 19 Feb 2014 12:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 twqgtl03wRZZ for ; Wed, 19 Feb 2014 12:06:24 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 892741A0510 for ; Wed, 19 Feb 2014 12:06:24 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0AADA403C0; Wed, 19 Feb 2014 15:06:21 -0500 (EST) Message-ID: <53050EBC.3040903@viagenie.ca> Date: Wed, 19 Feb 2014 15:06:20 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Pal Martinsen (palmarti)" , Mallinath Bareddy References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ZTLcVCY9Fnh-0xkorh_u9ISTf-8 Cc: "tram@ietf.org" , "Yoakum, John H \(John\)" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:06:26 -0000 Le 2014-02-19 14:58, Pal Martinsen (palmarti) a écrit : > Reading RFC5766 they use language that indicates that you will only > receive one XOR-RELAYED-ADDRESS attribute. An old client that receives > two might pick the wrong one, and get confused since he asked for a IPv4 > address and got a IPv6 address. There is no way for the client to get > out of that situation. (Furiously checking my own TURN client > implementation…) Backwards compatibility is why we can't have nice things... ;) How about we specify which XOR-RELAYED-ADDRESS parameter goes first? We can expect older clients to only look at the first one. So if you don't include REQUESTED-ADDRESS-FAMILY, the server returns both IPv4 and IPv6, and puts IPv4 first. If you do include REQUESTED-ADDRESS-FAMILY, the server still allocates two, the requested family is first in the response. If that works with existing clients (and it would be easy to try those we know), then we can have our cake and it it too! > I think it would be better for the client to include two > REQUESTED-ADDRESS-FAMILY attributes in the allocation request instead. > If the server supports that everything is fine. If the TURN server > responds with only one RELAY address, the client would notice and could > easily request the other address family on a different 5-tuple. Same > goes if the TURN server return an error, the client can go back to old > behaviour. That's a fine workaround. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Feb 19 12:18:29 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6A81A022E for ; Wed, 19 Feb 2014 12:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 WHvrHACEkUBH for ; Wed, 19 Feb 2014 12:18:26 -0800 (PST) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 14D431A0527 for ; Wed, 19 Feb 2014 12:18:26 -0800 (PST) Received: by mail-pd0-f179.google.com with SMTP id fp1so833662pdb.10 for ; Wed, 19 Feb 2014 12:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=to+vMwf/F7wpC+EYb8EjytJ12rRxYtzlUyAsuWU9+JY=; b=Int97zw4gA3ZsdHQFA++gLjF+YZNH9YbzviLo/Y+yCUv/Isg5NFfI0YBGvHzI/pEnp ySMPEnuC22jYkPkopXmr/kkMff/ZF7mxXU81+Bfwa3e3umcDqrA1cJwzryyU+haaURUC EXL8ye52k7qhTkDG+7vjLkqaNyG6V54H0H3kV7yJaQOxLfrvznNWztG6DrgnvsHrAdnK eQDr9CsETWMDrfpylge+YzXZEqEADBK4Fw3DrBCBcPGL70bdKsrdrxjWA6iFsqFSnE0v miv+UeRvUtGJE8n8XqxOX5UVBQ/66xPsb64oSUKfdn/z/0YjzyxCB00uTGfps74mrLsY 4UGg== X-Received: by 10.68.212.10 with SMTP id ng10mr4513674pbc.95.1392841102896; Wed, 19 Feb 2014 12:18:22 -0800 (PST) Received: from ?IPv6:2001:4998:effd:600:4979:a525:6699:cd73? ([2001:4998:effd:600:4979:a525:6699:cd73]) by mx.google.com with ESMTPSA id ix5sm3397949pbd.36.2014.02.19.12.18.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 12:18:22 -0800 (PST) References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> <53050EBC.3040903@viagenie.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <53050EBC.3040903@viagenie.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> X-Mailer: iPhone Mail (10B350) From: Oleg Moskalenko Date: Wed, 19 Feb 2014 12:18:22 -0800 To: Simon Perreault Archived-At: http://mailarchive.ietf.org/arch/msg/tram/CfR2af0DIjgjnmoIEyBjrddpYwA Cc: "Pal Martinsen \(palmarti\)" , Mallinath Bareddy , "tram@ietf.org" , "Yoakum, John H \(John\)" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:18:28 -0000 If the client explicitly requested an ip family - why the server must waste r= esources and allocated a useless (possibly) socket of a different family ? The server resources must be taken into account, too. Sent from my iPhone On Feb 19, 2014, at 12:06 PM, Simon Perreault w= rote: > Le 2014-02-19 14:58, Pal Martinsen (palmarti) a =C3=A9crit : >> Reading RFC5766 they use language that indicates that you will only >> receive one XOR-RELAYED-ADDRESS attribute. An old client that receives >> two might pick the wrong one, and get confused since he asked for a IPv4 >> address and got a IPv6 address. There is no way for the client to get >> out of that situation. (Furiously checking my own TURN client >> implementation=E2=80=A6) >=20 > Backwards compatibility is why we can't have nice things... ;) >=20 > How about we specify which XOR-RELAYED-ADDRESS parameter goes first? We > can expect older clients to only look at the first one. So if you don't > include REQUESTED-ADDRESS-FAMILY, the server returns both IPv4 and IPv6, > and puts IPv4 first. If you do include REQUESTED-ADDRESS-FAMILY, the > server still allocates two, the requested family is first in the > response. If that works with existing clients (and it would be easy to > try those we know), then we can have our cake and it it too! >=20 >> I think it would be better for the client to include two >> REQUESTED-ADDRESS-FAMILY attributes in the allocation request instead. >> If the server supports that everything is fine. If the TURN server >> responds with only one RELAY address, the client would notice and could >> easily request the other address family on a different 5-tuple. Same >> goes if the TURN server return an error, the client can go back to old >> behaviour.=20 >=20 > That's a fine workaround. >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 19 12:28:08 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE4F1A04F4 for ; Wed, 19 Feb 2014 12:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 Hqyt-M2vka0r for ; Wed, 19 Feb 2014 12:28:04 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1121A05D2 for ; Wed, 19 Feb 2014 12:28:03 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8F7D4403C0 for ; Wed, 19 Feb 2014 15:27:59 -0500 (EST) Message-ID: <530513CF.7000502@viagenie.ca> Date: Wed, 19 Feb 2014 15:27:59 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> In-Reply-To: <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/xdXgQNT3FWukEgMr7T19uh7FkgE Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:28:07 -0000 Le 2014-02-19 15:18, Oleg Moskalenko a écrit : > If the client explicitly requested an ip family - why the server must waste resources and allocated a useless (possibly) socket of a different family ? Right. So: No REQUESTED-ADDRESS-FAMILY: allocate both, IPv4 goes first REQUESTED-ADDRESS-FAMILY = IPv4: allocate only IPv4 REQUESTED-ADDRESS-FAMILY = IPv6: allocate only IPv6 REQUESTED-ADDRESS-FAMILY = IPv4+IPv6: allocate both, order doesn't matter > The server resources must be taken into account, too. Right. And single-stack servers too. And local security policy. But seriously, just provision your TURN server with a /96 and let it go wild. :) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Feb 19 12:45:28 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6711C1A022E for ; Wed, 19 Feb 2014 12:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 EFel_tJLoEkM for ; Wed, 19 Feb 2014 12:45:26 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 13D051A01DB for ; Wed, 19 Feb 2014 12:45:25 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id g10so856856pdj.16 for ; Wed, 19 Feb 2014 12:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=ZLwCZjS9a5Zxrb1dADnelG8oinpD5Zog90gizpm8r2Y=; b=IeRVotiZAIjSC1dRafYXfo+3r2fQm9AchN1nu8BjcYGGYwJRbT91r2Hgqsz2TYt3ju ys5fDkoKkf/PS//V3H0AXU69XTIdhkbM6vohGOfkfM9S6iTwuhMMLBFWfIGJXf1/KgR3 mePIO0LgibU5B8jxuS5jP1PWvKLMkwMpzmIcy1t9rbjSkLFG8ngQdFudndU/0RUJRiZQ 0owcWjb6fzkoRLY+Wq6KjmqLQF/SIIu28IyeqQCHnrVEx48ieMbOHHkwB+O9eXqZLEbP Nfc9GcSGnWG9ARD737F9cL1MIfOTzXiaPMJMSyTRkLOnYvdqrJ/J00pdzS/MiWe1/bxl qR1g== X-Received: by 10.67.24.1 with SMTP id ie1mr4567457pad.133.1392842722829; Wed, 19 Feb 2014 12:45:22 -0800 (PST) Received: from ?IPv6:2001:4998:effd:600:c463:449a:4040:cb60? ([2001:4998:effd:600:c463:449a:4040:cb60]) by mx.google.com with ESMTPSA id tu3sm8818730pab.1.2014.02.19.12.45.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Feb 2014 12:45:21 -0800 (PST) References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <530513CF.7000502@viagenie.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> X-Mailer: iPhone Mail (10B350) From: Oleg Moskalenko Date: Wed, 19 Feb 2014 12:45:21 -0800 To: Simon Perreault Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ZrThodV6NfA3J-7qbz3rmEW2B24 Cc: "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 20:45:27 -0000 I d suggest to allocate both families ONLY when ipv4+ipv6 are used in the re= quests, then it will 100% compatible and non-resource-wasting. Sent from my iPhone On Feb 19, 2014, at 12:27 PM, Simon Perreault w= rote: > Le 2014-02-19 15:18, Oleg Moskalenko a =C3=A9crit : >> If the client explicitly requested an ip family - why the server must was= te resources and allocated a useless (possibly) socket of a different family= ? >=20 > Right. So: >=20 > No REQUESTED-ADDRESS-FAMILY: allocate both, IPv4 goes first > REQUESTED-ADDRESS-FAMILY =3D IPv4: allocate only IPv4 > REQUESTED-ADDRESS-FAMILY =3D IPv6: allocate only IPv6 > REQUESTED-ADDRESS-FAMILY =3D IPv4+IPv6: allocate both, order doesn't matte= r >=20 >> The server resources must be taken into account, too. >=20 > Right. And single-stack servers too. And local security policy. >=20 > But seriously, just provision your TURN server with a /96 and let it go > wild. :) >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Wed Feb 19 18:39:25 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C351A0638 for ; Wed, 19 Feb 2014 18:39:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 RbBbRRTBIQkG for ; Wed, 19 Feb 2014 18:39:21 -0800 (PST) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 272BD1A0636 for ; Wed, 19 Feb 2014 18:39:21 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id jx11so1271249veb.24 for ; Wed, 19 Feb 2014 18:39:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=L781zaxz8hKRiWOlW1dLqqA0rfdJj6GgFLYCaJ+qvNI=; b=c8jnYZqjkTKecSa9WqtPQx0OwuJLxcp8AbsNd6WQ0fB3IKf3n0gOlkgAB9c6ZzykSb zJJSCi7kYAkLA5DMLDtVUthisCHi4nMaX3z4SIE/JsCBihhTES7k6tMrcm0hwPRd1Jxa WpU6UI9e0SpLdpwsghMtcaPK7GDUy/Q3sUYiXa+aOdsje21HbHdICpuV4kD96Kmasq2i Iypcvf9oI1tlCfJS1H3YR7POhWwNg7RP0exwpUIL6tOt0BovYCIvBJbYQoQ2Aws23bLN Dh+7jA8VcR1ortx/xGkdTX3WJNyntg1MiGCWkodWxNjuPS2M8qF1e1ClLJNcDdxTf5XA 0o9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=L781zaxz8hKRiWOlW1dLqqA0rfdJj6GgFLYCaJ+qvNI=; b=l0vtCjxSr8DXjJbPSpRl2q+61eIWiFEUoNelFakM3ld23kH3d9b4hiCXKcp4sdN5ll K9J9nWHwqJZbRHDpK3EX0X4g8V43r+GNNH1ITAfZs03cn12xVxGtscgjCUDvpP7BDUH0 5WJGQLtpFGCBFrtWHt9mAN4+TEvt4c0cS8t+X/tY4i+3nBym6btTQIs+YOY9EBXNOiZ7 bjPTgLe6UMJgVt+x832+xPoU/k7wNhq4TGRXciIAOqc6ww2MVlPC3IZoP9xAt4vxVhrD fUvD7+Z6K+O47wWc+KHP+5dyIZpqJp1uY/2bavpjEhHSUSwCitmpFfunWGDpn0Y8BWMh Zr3A== X-Gm-Message-State: ALoCoQkyNubiEn0lxYupvkXfvLH38931yZBu/lO3Qx1W6OOzGnXTSAMP2qbm8Pk4Lc4100YgB2PazK7E1YM+HU24uK/h+vCRpdzyp0AoNOKP8+mIEoZaJAVXgh3bSn49y821pRSpVqAl92tJX3WRR/mFhV8xR5qXeq4mVefXdqt6y0Gns+0cyXBk+IH8OAGcFSr5mp0mwIFS X-Received: by 10.52.190.1 with SMTP id gm1mr17631484vdc.21.1392863957346; Wed, 19 Feb 2014 18:39:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Wed, 19 Feb 2014 18:38:57 -0800 (PST) In-Reply-To: <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> From: Justin Uberti Date: Wed, 19 Feb 2014 18:38:57 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a1133eec266028704f2cd6904 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/xc-FS13sZ2_2750tIr9AKazDwAI Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 02:39:23 -0000 --001a1133eec266028704f2cd6904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK. So to do this we make the following changes: Allocate: add support for request of v4+v6 requested-address, allow return of v4 + v6 relayed address Refresh: None needed? Or do we want to allow client to pick the address to refresh via requested-address-family CreatePermission: Binding to create permission on implicit through destination address type ChannelData: same as CreatePermission This SGTM, as it allows a single socket to create local, stun, relay v4, and relay v6 candidates with no major TURN changes. On Wed, Feb 19, 2014 at 12:45 PM, Oleg Moskalenko wrot= e: > I d suggest to allocate both families ONLY when ipv4+ipv6 are used in the > requests, then it will 100% compatible and non-resource-wasting. > > Sent from my iPhone > > On Feb 19, 2014, at 12:27 PM, Simon Perreault > wrote: > > > Le 2014-02-19 15:18, Oleg Moskalenko a =C3=A9crit : > >> If the client explicitly requested an ip family - why the server must > waste resources and allocated a useless (possibly) socket of a different > family ? > > > > Right. So: > > > > No REQUESTED-ADDRESS-FAMILY: allocate both, IPv4 goes first > > REQUESTED-ADDRESS-FAMILY =3D IPv4: allocate only IPv4 > > REQUESTED-ADDRESS-FAMILY =3D IPv6: allocate only IPv6 > > REQUESTED-ADDRESS-FAMILY =3D IPv4+IPv6: allocate both, order doesn't ma= tter > > > >> The server resources must be taken into account, too. > > > > Right. And single-stack servers too. And local security policy. > > > > But seriously, just provision your TURN server with a /96 and let it go > > wild. :) > > > > Simon > > -- > > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > > STUN/TURN server --> http://numb.viagenie.ca > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a1133eec266028704f2cd6904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK. So to do this we make the following changes:
Alloc= ate: add support for request of v4+v6 requested-address, allow return of v4= + v6 relayed address
Refresh: None needed? Or do we want to allo= w client to pick the address to refresh via requested-address-family
CreatePermission: Binding to create permission on implicit through des= tination address type
ChannelData: same as CreatePermission
=

This SGTM, as it allows a single socket to create local= , stun, relay v4, and relay v6 candidates with no major TURN changes.


On Wed,= Feb 19, 2014 at 12:45 PM, Oleg Moskalenko <mom040267@gmail.com><= /span> wrote:
I d suggest to allocate both families ONLY w= hen ipv4+ipv6 are used in the requests, then it will 100% compatible and no= n-resource-wasting.

Sent from my iPhone

On Feb 19, 2014, at 12:27 PM, Simon Perreault <simon.perreault@viagenie.ca> wrote:

> Le 2014-02-19 15:18, Oleg Moskalenko a =C3=A9crit :
>> If the client explicitly requested an ip family - why the server m= ust waste resources and allocated a useless (possibly) socket of a differen= t family ?
>
> Right. So:
>
> No REQUESTED-ADDRESS-FAMILY: allocate both, IPv4 goes first
> REQUESTED-ADDRESS-FAMILY =3D IPv4: allocate only IPv4
> REQUESTED-ADDRESS-FAMILY =3D IPv6: allocate only IPv6
> REQUESTED-ADDRESS-FAMILY =3D IPv4+IPv6: allocate both, order doesn'= ;t matter
>
>> The server resources must be taken into account, too.
>
> Right. And single-stack servers too. And local security policy.
>
> But seriously, just provision your TURN server with a /96 and let it g= o
> wild. :)
>
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca=
> STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --&g= t; http://numb.viagen= ie.ca
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--001a1133eec266028704f2cd6904-- From nobody Wed Feb 19 22:49:41 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5BD1A05EA for ; Wed, 19 Feb 2014 22:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 frD3sIa5NsdV for ; Wed, 19 Feb 2014 22:49:37 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 29BC61A0551 for ; Wed, 19 Feb 2014 22:49:37 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id rr13so1494027pbb.21 for ; Wed, 19 Feb 2014 22:49:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RZzPA0XXc/gAWsJekO4GNccs0Xr/IELjeIamuPrqBgU=; b=sQ3/DALD57jpSCB9HGc7/J8uxaiWzl1TiW5i3WGg0+g3vhwtmlHNMob5Jfi+RqbmnO AWQ4hQF5ah/90rwVtexaY9d2hzrEsUjEz3+WLrB7WVWXTFtlu3ty4t17MPTdV2SecZSW y+FqUaiw5z4p5CHp35qnDNO3GLPEv1A+0Tv/j5MO9n5tPpN3TyqJkt/501x8MIkpgIS6 NSFD+3mmwip+DJP/0kGco+QSIN0iv9UwRFzKmcnQemkS0kWWehJVmId63oUOnOECXRMg T+0dgtR4gIvkAD3kHnLkh7N0e5w1vuSOZ3G86iymnYXMfed9R2H2eCG7oUAktZdc/Ozu Q0lA== MIME-Version: 1.0 X-Received: by 10.68.212.161 with SMTP id nl1mr171401pbc.142.1392878973768; Wed, 19 Feb 2014 22:49:33 -0800 (PST) Received: by 10.68.147.131 with HTTP; Wed, 19 Feb 2014 22:49:33 -0800 (PST) In-Reply-To: References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> Date: Wed, 19 Feb 2014 22:49:33 -0800 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=e89a8ff1c89c725b0f04f2d0e87d Archived-At: http://mailarchive.ietf.org/arch/msg/tram/TE69tntEIU5Ya-EHTj_orM2zpy8 Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 06:49:38 -0000 --e89a8ff1c89c725b0f04f2d0e87d Content-Type: text/plain; charset=ISO-8859-1 Justin, please see below: On Wed, Feb 19, 2014 at 6:38 PM, Justin Uberti wrote: > OK. So to do this we make the following changes: > Allocate: add support for request of v4+v6 requested-address, allow return > of v4 + v6 relayed address > Refresh: None needed? > > Or do we want to allow client to pick the address to refresh via > requested-address-family > If we are going to make it backward compatible, then we must refresh with explicit address-family in the refresh request. Only relay endpoints which families are set in the refresh request will be refreshed. Then the old specs will be a subset of the new specs. > CreatePermission: Binding to create permission on implicit through > destination address type > I agree > ChannelData: same as CreatePermission > I agree > > This SGTM, as it allows a single socket to create local, stun, relay v4, > and relay v6 candidates with no major TURN changes. > > I agree Oleg --e89a8ff1c89c725b0f04f2d0e87d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Justin, please see below:

On Wed, Feb 19, 2014 at 6:38 PM, Justin U= berti <juberti@google.com> wrote:
OK. So t= o do this we make the following changes:
Allocate: add support for requ= est of v4+v6 requested-address, allow return of v4 + v6 relayed address
Refresh: None needed?
=A0
Or do we want to all= ow client to pick the address to refresh via requested-address-family

If we are going to make it backward compatible,= then we must refresh with explicit address-family in the refresh request. = Only relay endpoints which families are set in the refresh request will be = refreshed. Then the old specs will be a subset of the new specs.
=A0
CreatePermission: Binding to create permission on implicit through des= tination address type

I agree
=A0
ChannelData: same as CreatePermission

I agree
=A0

This SGTM, as it allows a single socke= t to create local, stun, relay v4, and relay v6 candidates with no major TU= RN changes.


I agree

Oleg
--e89a8ff1c89c725b0f04f2d0e87d-- From nobody Wed Feb 19 22:53:00 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB791A0618 for ; Wed, 19 Feb 2014 22:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 n3WcMd0sxEGR for ; Wed, 19 Feb 2014 22:52:56 -0800 (PST) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0861A0551 for ; Wed, 19 Feb 2014 22:52:56 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hu8so1469922vcb.29 for ; Wed, 19 Feb 2014 22:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uNFpbmEqIY2PuchQDRaHbzl7biA4TdC5GqgXWPiJws4=; b=kwvqkustBkrp4uzvdpmhS9Hs018C39lptf78nVHDhd+jDxvFD4Znh4T0e1qLVnpsD5 2iIKWVZvKVe4jim32APzv0ZlANtYUTY/RYlQ2O+gjO0ilEUH1we9ioZ9k1dMVLszzFPu mVvrABTWsxEXKdccuubf+BOOVyZwFNsLkKnsIstArpNVzWHEEnSBi2wevU6CrHDCzAoU jqFoRmdvkSy1ZP456Ooi1wpfwnTYpqAit5WsKlmN2jPhJIPWY3ISabI5cAxNpPPdeM3r D0YupAzUq71MVn2z8xch0mOF9+aoS2G7isn+OXcs2DtS2b8KFikX+/fs5ZpqvLNJPggg 4tZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=uNFpbmEqIY2PuchQDRaHbzl7biA4TdC5GqgXWPiJws4=; b=B6PWiLXbPgrx1qJoYYOT/dZUAHS0XM7QlDceMq/HZz4TY8G5NtKFfqrszymzwoKEt4 b+JljAWBQWsc6dnDhmycsXyBatUiQg9OFdPjk8vC+1OiGfoQYz9eNZMENd7UqjwOSN4C E/xLSCPLX83B65u8+soKUvF5cXyPKN9eVkU0aEUIovjVgTbu7YNVxYqQaNjKSU3wK4xk UVV4IGxn+49rpmtZC2NIHMy/LIQnCKXZSfs0FUassOpkWsTW78KuG+c5BtudGgVdAsfj 0RSeiI6zhff2Ko/CPt4zeeUwrt1s3U9GkISK1aBA7GN9hcscikf2DWXJ3bXpGbAyQOO6 4F9w== X-Gm-Message-State: ALoCoQlnJ5HKTMFlvJQQ+snAYNYQMtU9EYM+ZaaU4XND60ALfR7kIrSiZ4j8b6oWghV14t/CUffKw579mrbEAESz5zRVF9x9y3dkqbCK/7fb5cWvtHikcp4AMzPimnJS5fTcoLbGTyivmAZ21el9k79/Y+es5aRaJ/voIH9jAUlmNVm5EL3LfBXAnEnHLgyciXe6ESL3jJQr X-Received: by 10.52.190.1 with SMTP id gm1mr48304vdc.21.1392879172505; Wed, 19 Feb 2014 22:52:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Wed, 19 Feb 2014 22:52:32 -0800 (PST) In-Reply-To: References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> From: Justin Uberti Date: Wed, 19 Feb 2014 22:52:32 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a1133eec24ae8d804f2d0f4a0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/1yBUmRpP_ceTOrfDcI_bwh9X8_Y Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 06:52:58 -0000 --001a1133eec24ae8d804f2d0f4a0 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 19, 2014 at 10:49 PM, Oleg Moskalenko wrote: > Justin, please see below: > > On Wed, Feb 19, 2014 at 6:38 PM, Justin Uberti wrote: > >> OK. So to do this we make the following changes: >> Allocate: add support for request of v4+v6 requested-address, allow >> return of v4 + v6 relayed address >> Refresh: None needed? >> >> > Or do we want to allow client to pick the address to refresh via >> requested-address-family >> > > If we are going to make it backward compatible, then we must refresh with > explicit address-family in the refresh request. Only relay endpoints which > families are set in the refresh request will be refreshed. Then the old > specs will be a subset of the new specs. > I don't follow. Only new clients will allocate v4+v6 on the same socket. (And the existing spec says to NOT use r-a-f in the refresh request.) > > >> CreatePermission: Binding to create permission on implicit through >> destination address type >> > > I agree > > >> ChannelData: same as CreatePermission >> > > I agree > > >> >> This SGTM, as it allows a single socket to create local, stun, relay v4, >> and relay v6 candidates with no major TURN changes. >> >> > I agree > > Oleg > --001a1133eec24ae8d804f2d0f4a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 19, 2014 at 10:49 PM, Oleg Moskalenko <mom040267@gma= il.com> wrote:

=C2=A0
CreatePermission: Binding to create permission on implicit through des= tination address type

I a= gree
=C2=A0
ChannelData: same as CreatePermission

I agree
=C2=A0

This SGTM, as it allows a single socke= t to create local, stun, relay v4, and relay v6 candidates with no major TU= RN changes.


I agree

Oleg

--001a1133eec24ae8d804f2d0f4a0-- From nobody Wed Feb 19 23:15:18 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E458D1A02FD for ; Wed, 19 Feb 2014 23:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 9vuWDG1UHb4S for ; Wed, 19 Feb 2014 23:15:14 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9598E1A0369 for ; Wed, 19 Feb 2014 23:15:14 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kx10so1530137pab.35 for ; Wed, 19 Feb 2014 23:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gyzaDW+SAqmsI7gVPTNY01d14zSZXMOL7wdvT10bYm4=; b=vJVcYprXYgjkmbiIyqZZOo1l1JjfXsWiflCve4qwCW1DWFRCcid0wNc9HkdNTqnbiW hnz/h8LQbrD1M0R2N47yTxVYhq0SpDas+u4FcXnWOBiMIXseUXZnTFPti4Cm9gR4kQHe f5zQKapvF7plR8StyRn9Wk1LDvVAFlQbud3m1P13+kwwXXE3VXnZESbEYGS2OrapJrw8 /aKJ10c02ENKZAaSUfDvt7NexvQNiZx80KnXT8WCvWmyABnyg6RRGAMWOWLBYCXKDJGK 1uZFfj1OXUCOaLg1qoDljQIWlWbJIyuyUM+Ax8M9+gekzNMf1GMQnV6fFb9wBYQnZvZl oXGw== MIME-Version: 1.0 X-Received: by 10.68.139.100 with SMTP id qx4mr281787pbb.144.1392880511204; Wed, 19 Feb 2014 23:15:11 -0800 (PST) Received: by 10.68.147.131 with HTTP; Wed, 19 Feb 2014 23:15:11 -0800 (PST) In-Reply-To: References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> Date: Wed, 19 Feb 2014 23:15:11 -0800 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=001a11c361d215c71604f2d144ae Archived-At: http://mailarchive.ietf.org/arch/msg/tram/1PEFwAnnnYDBhcYQkYIHVheJes4 Cc: Simon Perreault , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 07:15:17 -0000 --001a11c361d215c71604f2d144ae Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 19, 2014 at 10:52 PM, Justin Uberti wrote: > > > I don't follow. Only new clients will allocate v4+v6 on the same socket. > That's true. > (And the existing spec says to NOT use r-a-f in the refresh request.) > >> >> > That is somewhat a grey area... this is what RFC 6156 is saying: ======================================================================== 5.1 . Sending a Refresh Request To perform an allocation refresh, the client generates a Refresh Request as described in Section 7.1 of [RFC5766] . The client MUST NOT include any REQUESTED-ADDRESS-FAMILY attribute in its Refresh Request. 5.2 . Receiving a Refresh Request If a server receives a Refresh Request with a REQUESTED-ADDRESS- FAMILY attribute, and the attribute's value doesn't match the address family of the allocation, the server MUST reply with a 443 (Peer Address Family Mismatch) Refresh error response. ============================================== So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may expect that attribute... So, I reconsider my opinion: let's not use the address-family in the REFRESH at all, and refresh all relay endpoints regardless of their protocols. Regards, Oleg --001a11c361d215c71604f2d144ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 19, 2014 at 10:52 PM, Justin Uberti &= lt;juberti@google.c= om> wrote:


I don= 't follow. Only new clients will allocate v4+v6 on the same socket.

That's true.

=A0
(And the existi= ng spec says to NOT use r-a-f in the refresh request.)=A0
=A0
<= /div>

That is somewhat a grey area... this = is what RFC 6156 is saying:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5.1.  Sending a=
 Refresh Request



   To perform an allocation refresh, the client generates a Refresh
   Request as described in Section=A07.1 of [RFC5766].  The client MUST
   NOT include any REQUESTED-ADDRESS-FAMILY attribute in its Refresh
   Request.


5.2.  Receiving a Refresh Reques=
t


   If a server receives a Refresh Request with a REQUESTED-ADDRESS-
   FAMILY attribute, and the attribute's value doesn't match the ad=
dress
   family of the allocation, the server MUST reply with a 443 (Peer
   Address Family Mismatch) Refresh error response.

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may exp= ect that attribute...

So, I reconsider my opinion: let's not use the address-f= amily in the REFRESH at all, and refresh all relay endpoints regardless of = their protocols.

Regard= s,
Oleg

--001a11c361d215c71604f2d144ae-- From nobody Thu Feb 20 03:50:17 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DEF1A00BB for ; Thu, 20 Feb 2014 03:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 fcYuSbcCoh1W for ; Thu, 20 Feb 2014 03:50:10 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9C38F1A0061 for ; Thu, 20 Feb 2014 03:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=836; q=dns/txt; s=iport; t=1392897007; x=1394106607; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GRkS/8kODRXS/ozfW/7vJMndaHSMPelgbwvW13OGGIQ=; b=K8aXcONqazsT1rornYvfrkQOQao9AHW3S7B0IHIa2/YZClXujeGUwW9J nsBks2iaiY/C9xVqFXGPtnQ3Xlj2P/b26JYHQzCdqLJBTpeC/met1Qn1n 81fzkyGbazhENEZd3bc2OY7YnuTcc5FPFRGN4trY34RKAH0C8GjnA2hcK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAO/qBVOtJV2d/2dsb2JhbABZgwY4V8AKgQ0WdIIlAQEBAwEBAQFrCwULAgEIDjghBgslAgQOBYdxAwkIDcZRDYdwEwSMT4FiMweDJIEUAQOJEI00gWyMXoVGgy2CKg X-IronPort-AV: E=Sophos;i="4.97,512,1389744000"; d="scan'208";a="305344319" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 20 Feb 2014 11:50:07 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1KBo6ox003499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 11:50:06 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 05:50:06 -0600 From: "Pal Martinsen (palmarti)" To: Oleg Moskalenko Thread-Topic: [tram] IPv4 and IPv6 allocations Thread-Index: AQHPLYfCF1sa7J708UqHyNHj1pugzJq9G8kAgAAPoQCAAAHCAIAABuuAgAABDYCAAARRAIAABT2AgAAE5ICAAB/uAIAAAh0AgAADXQCAAAKwgIAABNqAgABiy4CAAEYFgIAAANUAgAAGVICAAEzPgA== Date: Thu, 20 Feb 2014 11:50:05 +0000 Message-ID: <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.70] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0210BB31CA0AFD489DFDF03F2F757E09@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/c1sQ2XCqGEjOjqgMhML2L4TSXZE Cc: Simon Perreault , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 11:50:13 -0000 On 20 Feb 2014, at 08:15 am, Oleg Moskalenko wrote: [cut] >=20 >=20 > So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may exp= ect that attribute... >=20 I just noticed that as well. Funny.. > So, I reconsider my opinion: let's not use the address-family in the REFR= ESH at all, and refresh all relay endpoints regardless of their protocols. >=20 Well it is nice to have in there as the refresh is also used to delete an a= llocation. So if you after ICE is completed ends up only using the IPv6 all= ocation you can delete the IPv4 allocation. This frees up resources on the = TURN server.=20 .-. P=E5l-Erik > Regards, > Oleg >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Feb 20 05:35:17 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1467B1A0160 for ; Thu, 20 Feb 2014 05:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 ehG9JsT-50xF for ; Thu, 20 Feb 2014 05:35:05 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id AB3E61A0161 for ; Thu, 20 Feb 2014 05:35:01 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402201434556813; Thu, 20 Feb 2014 14:34:55 +0100 From: "Karl Stahl" To: "'Tirumaleswar Reddy \(tireddy\)'" , "'Dan Wing \(dwing\)'" , "'Pal Martinsen \(palmarti\)'" References: <913383AAA69FF945B8F946018B75898A242AF62F@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A242AF62F@xmb-rcd-x10.cisco.com> Date: Thu, 20 Feb 2014 14:34:53 +0100 Message-ID: <01a401cf2e40$89d31350$9d7939f0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A5_01CF2E48.EB977B50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8r9BugYsLIjYAAQP2Yz1Hsf4BmOABq3x4w Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RWU8BHqsKwDLYUzTQnaLFDjKvxE Cc: tram@ietf.org Subject: Re: [tram] QoS for RTC over the Internet, DISCUSS: Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 13:35:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01A5_01CF2E48.EB977B50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Tiru,=20 See next email, where I address a few of your points after = P=C3=A5l=E2=80=99s extensive input. The rest of your points I simply agree with, I think. /Karl =20 Fr=C3=A5n: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]=20 Skickat: den 17 februari 2014 16:23 Till: Karl Stahl; Dan Wing (dwing); Pal Martinsen (palmarti) Kopia: tram@ietf.org =C3=84mne: RE: QoS for RTC over the Internet, DISCUSS: [tram] Milestone = 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 Hi Karl, =20 Please see inline [TR] =20 =20 From: Karl Stahl [ = mailto:karl.stahl@intertex.se]=20 Sent: Monday, February 17, 2014 6:41 PM To: Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Pal Martinsen = (palmarti) Cc: tram@ietf.org Subject: QoS for RTC over the Internet, DISCUSS: [tram] Milestone 3: = TURN server auto-discovery mechanism for enterprise and ISPs =20 Tiru > I did not did not understand how TURN server will identify if = it=E2=80=99s WebRTC media streams or gaming traffic or some other data = traffic relayed through it to set the diffserv bits correctly ! --- I think you do understand=E2=80=A6 =E2=80=93 but I will spell out = that DISCUSS/MALICE does it better and with useful detail J =20 P=C3=A5l, Tiru, Dan and you other thinking about these things: =20 What has been discussed by me here so far, to give us quality of = real-time traffic over the Internet (not a small task) is: =20 1) To direct the real-time traffic to where the network can handle such = traffic (using a network offered TURN servers) (which is not within the = scope of DISCUSS) =20 [TR] I still don=E2=80=99t understand the need to force the media = traffic to be sent through the TURN server either with DISCUSS or PCP. =20 2) When such a TURN server flow is allocated, it can ASSUME that it is = going to used for real-time traffic and instruct the network (e g via = setting diffserve bits) to prioritize the assumed real-time traffic. = (Giving the same prioritization to all TURN traffic works quite well. = =E2=80=93 Only if we fill the whole pipe with prioritized traffic (best = effort totally pushed off) is it important that e.g. voice if = prioritized higher than video). =20 [TR] This assumption is not right and could result in false positives.=20 =20 3) When the TURN server sees the flow coming in (Note: in both = directions) it can do smarter guesswork of what traffic it is (like a = DPI-box), e.g. what is RTP and what is data channel to instruct the = network better. =20 [TR] I don=E2=80=99t think DPI will help, how will the TURN server = differentiate b/w audio and video streams when it is DTLS-SRTP ?=20 Even the Home Router needs to treat these media streams differently but = may not see the need to deploy a TURN server.=20 =20 Now after browsing = = http://tools.ietf.org/html/draft-martinsen-tram-discuss-00=20 =20 4) DISCUSS transfers information directly from the application to the = network at the time of setup of the STUN or TURN(?) server, which it = therefore can do with better detail and prediction. This is valuable, = also for reserving bandwidth in non diffserve networks like Cable and = Mobile where one reserves bandwidth rather than use diffserve for QoS. =20 [TR] Yes, the network can enforce any QOS policy based on the metadata = signaled by the client. Please note that during the review of = = http://tools.ietf.org/html/draft-wing-pcp-flowdata-00 we found that = there was only interest to provide GBR (Guaranteed Bit Rate =E2=80=93 = bandwidth reservation) for WebRTC media streams if the WebRTC server has = business tie-up with the Mobile network otherwise it=E2=80=99s non-GBR = for the WebRTC media streams. This topic needs more discussion. =20 5) Isn=E2=80=99t DISCUSS usable with TURN? Maybe even better! And it can = be used with 1) above J You can transfer the same information in the TURN allocate request as in = the STUN binding request, can=E2=80=99t you?. I searched for = =E2=80=9CTURN=E2=80=9D in the DISCUSS draft, but could not see it = spelled out. TURN is an extension to STUN, so maybe it is just obvious? = =E2=80=93 I have not checked details in the specs so P=C3=A5l, Tiru or = Dan knowing better, please confirm or correct ! =20 [TR] = http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00 = addresses the problem you had mentioned, it needs to be enhanced with = more metadata and the other advantage is TURN server can respond in the = ALLOCATE response if it can meet the flow characteristics or not. = It=E2=80=99s discussed in section = = http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00#section-4= .2 of the draft. My point is it=E2=80=99s only useful if TURN is = selected because direct connectivity using host/server-reflexive = candidates failed or relayed candidates are only advertised for privacy = reason. =20 Some observations: =20 a. In DISCUSS using STUN, the network element doing the diffserv or = reservation settings WOULD be in the default gateway. b. In DISCUSS using TURN, the TURN server doing the diffserv or = reservation settings COULD be in the default gateway. (The = auto-discovery of the TURN server would simply point out the default = gateway.) =20 Sound very similar: Could not DISCUSS over TURN always be used? =20 c. With DISCUSS using TURN, the application would directly talk to the = network device doing the diffserve settings etc. (instead of through it, = where typically the default gateway would snope that talk). Would that = not easy some of the concerns in the draft left for further discussion?=20 =20 d. Can we add info in the response? E.g. if the network device is only = willing to give 1 Mbps instead of needed 3 Mbps, so the application can = be informed to reduce his video resolution? Would be a nice mechanism = when RTC alone starts filling our pipes. (I saw a similar idea by = P=C3=A5l in the previous email I just commented.) =20 [TR] PCP solves the problem by providing response similar to what you = had mentioned and can also send subsequent response updating the = information about the flow, should the network conditions change. For = more details refer to = = http://www.ietf.org/proceedings/87/slides/slides-87-pcp-5.pdf.=20 =20 -Tiru. =20 6) Please add to the DISCUSS draft that it also could reserve bandwidth = in bandwidth reservation type of networks like Cable and Mobile = networks! =20 =20 A few more things are needed for the ultimate goal, bringing end-to-end = QoS or QoE for real-time communication to Best Effort Internet (which = does not seem impossible, but quite doable now J ) remains though. = I=E2=80=99ll come back to those.=20 =20 It will e.g. relate to how to do with INCOMING traffic, especially in = reservation type of networks, and the wild changing/stripping of = diffserve bits between ISPs. =20 You may want to check this old discussion to see if this useful: = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html=20 = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html=20 =20 /Karl =20 =20 Fr=C3=A5n: Tirumaleswar Reddy (tireddy) [ = mailto:tireddy@cisco.com]=20 Skickat: den 13 februari 2014 17:47 Till: Karl Stahl Kopia: tram@ietf.org =C3=84mne: RE: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and ISPs =20 Hi Karl, =20 I did not understand how TURN server will identify if it=E2=80=99s = WebRTC media streams or gaming traffic or some other data traffic = relayed through it to set the diffserv bits correctly ! =20 -Tiru. From: Karl Stahl [ = mailto:karl.stahl@intertex.se]=20 Sent: Thursday, February 13, 2014 5:05 PM To: Tirumaleswar Reddy (tireddy); 'Hutton, Andrew'; 'Justin Uberti'; = Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; 'Simon Perreault'; = 'Oleg Moskalenko'; tram@ietf.org; 'Marc = Blanchet'; Dan Wing (dwing) Subject: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and ISPs =20 On the side of this TRAM-list, I also got this question: > Regarding the enterprise case, I am not sure I follow your argument. > Do you mean that by setting up an enterprise TURN server, and open the = firewall for media over UDP from/to TURN server be the solution? ---- As we all realize, that would of course not help or improve things =20 The intended solution in the enterprise case has not yet been spelled = out in this TRAM-list discussion, so for better understanding, let me = copy a few things from the discussion in September/October on the = RTCWEB-list and what is (since long) spelled out in the = draft-ietf-rtcweb-use-cases-and-requirements. =20 For better understanding, I also want to point out that a TURN can have = two interfaces (acting like a router for media between different = networks). This allows to easier understand that can TURN servers can = direct a best media path (rather than just thinking that a TURN service = is a device which media just bounces against at one interface).=20 =20 And, we can also hope for that a TURN server becomes a (common) = component of a firewall, which would allow the firewall to understand = that the media directed to it is RTC and should be prioritized whereby = the firewall can traffic shaped (back-off data traffic that may be = filling its Internet pipe) as well as e.g. set diffserve bits or take = other measures to assist proper quality handling thought the network. = (These are common mechanisms available and used in firewalls/NATs/access = routers, but TURN servers are not yet included such devices.) The same = goes for access routers/default gateways, DPIs in the transport network = itself =E2=80=93 TURN servers included in such points were media can = pass and quality measures applied may/will be very useful to get us = WebRTC media with through networks without quality destruction. =20 >From the RTCWEB mailing list September 20th (by me): An enterprise network that want to keep a restrictive firewall not = allowing UDP traffic, could provide a real-time path using a TURN server = paralleling the firewall, instead of tunneling RTP through always open = http or https ports resulting in RTP media over TCP =E2=80=93 with = severe quality problems from TCP retransmissions of dropped packets. The = TURN server address is most easily provided in the same way as the IP = address and DNS address. (That would also put the right party in control = =E2=80=93 The network provider (here the enterprise) decides what is = allowed on his network.) =20 The browser should select which available TURN server address to use in = the following priority order, where ICE could be used to try several: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used) 2) TURN server address configured by the network administrator via an = =E2=80=9Cadmin policy template=E2=80=9D 3) TURN server address supplied by DHCP or similar automatic network = method 4) TURN server address being supplied by the web application" =20 =20 And from yesterdays(!) = = http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1= 4 these enterprise things and necessity are spelled out in: =20 F19 The browser must be able to use several STUN and TURN servers ---------------------------------------------------------------- =20 A22 = 3.3.5. Simple Video Communication Service, enterprise = aspects = 3.3.5.1. Description This use-case is similar to the Simple Video Communication Service use-case ( = Section 3.3.1). =20 What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use-case. =20 An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application sessions used from inside the company towards any external peer. To be able to do this they deploy a TURN server that straddles the boundary between the internal and the external network. =20 The firewall will block all attempts to use STUN with an external destination unless they go to the enterprise auditing TURN server. In cases where employees are using RTCWEB applications provided by an external service provider they still want the traffic to stay inside their internal network and in addition not load the straddling TURN server, thus they deploy a STUN server allowing the RTCWEB client to determine its server reflexive address on the internal side. Thus enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possible to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to achieve by auto-configuration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. = 3.3.5.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F20 The browser must support the use of STUN and TURN servers that are supplied by entities other than the web application (i.e. the network provider). ---------------------------------------------------------------- =20 There are further requirement listed, helping us to understand the need = for auto discovery and a network provided TURN-server should be used to = ENFORCE that media takes that path (and thus, other paths e.g. suggested = by the remote MUST not happen to be used). This is related to the = mobility aspect (valid even without the roaming idea): = 3.3.6. Simple Video Communication Service, access = change = 3.3.6.1. Description This use-case is almost identical to the Simple Video Communication Service use-case ( = Section 3.3.1). The difference is that the user changes network access during the session. =20 The communication device used by one of the users has several network adapters (Ethernet, WiFi, Cellular). The communication device is accessing the Internet using Ethernet, but the user has to start a trip during the session. The communication device automatically changes to use WiFi when the Ethernet cable is removed and then moves to cellular access to the Internet when moving out of WiFi coverage. The session continues even though the access method changes. = 3.3.6.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- = 3.3.7. Simple Video Communication Service, QoS = 3.3.7.1. Description This use-case is almost identical to the Simple Video Communication Service, access change use-case ( = Section 3.3.6). The use of Quality of Service (QoS) = capabilities is added: =20 The user in the previous use case that starts a trip is behind a common residential router that supports prioritization of traffic. In addition, the user's provider of cellular access has QoS support enabled. The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular. = 3.3.7.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- F22 The browser must be able to receive streams and data from multiple peers concurrently. ---------------------------------------------------------------- =20 Further from the RTCWEB mailing list September 20th (by me): =20 There are several reasons for a network service provider to supply a = TURN server as part of his offered access: - to keep media paths short, specifically not sending media outside its = own network to some distant application provided TURN server - to support mobility, i.e. you may want to move from a LAN with a = configured TURN server to accessing via WiFi or 3G/4G OTT channels - to offer a media path with better quality (than best effort data = traffic). Getting =E2=80=9CWebRTC-ready=E2=80=9D access and we look forward to = telepresence for everyone. =20 =20 I hope this (a bit lengthy) summary of already thought-out and discussed = aspects/requirements will help us understand that the auto-discovered = TURN server is an ORDER from the enterprise and/or the NSP/ISP to send = the media through this TURN path, and that other media paths that may = exist MUST NOT BE USED. (That is why we especially have to watch/advice = that workable media paths proposed by the remote party not becomes used = =E2=80=9Cby accident=E2=80=9D. =20 /Karl =20 =20 Fr=C3=A5n: Tirumaleswar Reddy (tireddy) [ = mailto:tireddy@cisco.com]=20 Skickat: den 13 februari 2014 04:37 Till: Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Kopia: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ietf.org; Marc Blanchet; = Dan Wing (dwing); Karl Stahl =C3=84mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Hi Andy, =20 There are other ways to solve the problem for example using PCP. Can you = clarify how deploying a TURN server in the Enterprise protects the users = and the network ?=20 =20 -Tiru. From: tram [ = mailto:tram-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Thursday, February 13, 2014 1:00 AM To: Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ietf.org; Marc Blanchet; = Dan Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The case where the TURN server is the only option may become common = within enterprise networks and that might be deliberate enterprise = policy because it provides the better path (UDP through the F/W) and = protects the users and the network. =20 Andy =20 =20 From: tram [ = mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 12 February 2014 17:46 To: Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ietf.org; Marc Blanchet; = Dan Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Agree. If TURN is indeed being provided for the user's benefit, the = client's ICE logic (based on RTT or similar) should result in it = preferring the TURN path. =20 On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) = wrote: Yes, I believe the second case is rare, but would be better than a rat = race b/w administrators trying to block p2p traffic and force it through = a TURN server and apps/endpoints finding smarter ways to bypass them. =20 Muthu =20 From: Oleg Moskalenko [mailto: = mom040267@gmail.com]=20 Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; = tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The TURN server has to be used when it is either the only option, or if = it provides a better path (I guess the second case is rather rare). =20 On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) = wrote: +1 =20 Forcing all traffic through a TURN server and expecting it would provide = the best user experience doesn't look the right approach. Instead, if a = path through a TURN server exists and does provide lower RTT, jitter = etc, being able to detect and use (or switch to) that path might be = desirable.. =20 Muthu =20 From: tram [mailto: = tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl = wrote: Listening to this thread, I am afraid we are missing the very point and = necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by = the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle = routing",need a new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.=20 - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic.=20 Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =E2=80=9CTURN=E2=80=A6to identify WebRTC = flows=E2=80=9D etc! It is not a mistake, but the very need for this = milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like = MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the = wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication = (SIP at that time). However, its largest flaw/problem is that quality = things were not (could not be?) considered. The method=E2=80=99s very = idea (like all similar methods for getting RTC through ordinary = NAT/Firewalls) is to fool the media through a NAT/Firewall that is = unaware of what is happening. Thus, this is root of quality issues (and = bandwidth allocation optimization) that needs to be dealt with: = Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. J=20 ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get = media through (and of course with as good quality as required and = possible).=20 =20 If the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D It is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).=20 =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =E2=80=9Cbecause it is all = about bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with = time=E2=80=9D etc., I strongly object! That is wrong and will be very = detrimental for WebRTC usage. We already see it and I can give numerous = examples of how much less quality demanding VoIP is/is not handled = quality wise and that it matters. And, what would be bad considering = quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. (Maybe the Web browser can = detect and encourage this=E2=80=A6)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the = browser that there are good media paths to be used, and that the web = browser automatically can chose those, then let us all understand those, = so we can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the = Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) = is a much bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of = WebRTC. =20 /Karl =20 =20 Fr=C3=A5n: Dan Wing [mailto: dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; = Karl Stahl; tram@ietf.org; Simon Perreault =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet < = marc.blanchet@viagenie.ca> wrote: =20 Le 2014-02-11 =C3=A0 00:39, Dan Wing < = dwing@cisco.com> a =C3=A9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti < = juberti@google.com> wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' = path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level = proxy (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network = administrator) or necessary (for the call to work at all).=20 =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN = server will do, and the endpoint should prefer TURN candidates over all = others because there might be some functionality / usefulness of TURN = that the user might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl < = karl.stahl@intertex.se> wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto: = tram-bounces@ietf.org] F=C3=B6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; = tireddy@icisco.com =C3=84mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =C3=A9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =E2=80=9Cautomatically=E2=80=9D does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is = provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage = of the TURN server (that we wanted to be used for the good purposes = listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting = ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be = adding a route in a default gateway, adding a firewall rule to eat STUN = packets would assure that the provisioned TURN server actually becomes = used (and not bypassed "by accident"). (That was the thought behind the = =E2=80=9Cautomatically=E2=80=9D within quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an = auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - = "anyone could set up a badly-maintained" - enforcing such ICE usage may = not be good.) > - 3^rd The Anycast method below =E2=80=93 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =E2=80=93 The anycast discovered = TURN-server can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued = 6to4? That is, anyone could set up a badly-maintained, under-provisioned = TURN server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the = anycast server you see is being provided to you by your ISP, rather than = a server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready = answer... An auto-discovered TURN server must be trusted (whatever method it is = discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that = trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? = Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> = http://postellation.viagenie.ca NAT64/DNS64 open-source --> = http://ecdysis.viagenie.ca STUN/TURN server --> = http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org = https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_01A5_01CF2E48.EB977B50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi= Tiru,

Se= e next email, where I address a few of your points after = P=C3=A5l=E2=80=99s extensive input.

Th= e rest of your points I simply agree with, I = think.

/K= arl

 

Fr=C3=A5n: = Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] =
Skickat: den 17 februari 2014 16:23
Till: Karl = Stahl; Dan Wing (dwing); Pal Martinsen (palmarti)
Kopia: = tram@ietf.org
=C3=84mne: RE: QoS for RTC over the Internet, = DISCUSS: [tram] Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs

 

Hi= Karl,

 

Pl= ease see inline [TR]

 

 

From:= Karl Stahl = [mailto:karl.= stahl@intertex.se] =
Sent: Monday, February 17, 2014 6:41 PM
To: = Tirumaleswar Reddy (tireddy); Dan Wing (dwing); Pal Martinsen = (palmarti)
Cc: tram@ietf.or= g
Subje= ct: QoS for RTC over the Internet, DISCUSS: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

Tiru > I did not did not understand how TURN server will identify = if it=E2=80=99s WebRTC media streams or gaming traffic or some other = data traffic relayed through it to set the diffserv bits correctly = !

--= - I think you do understand=E2=80=A6 =E2=80=93 but I will spell out that = DISCUSS/MALICE does it better and with useful detail J<= /span>

 

P=C3= =A5l, Tiru, Dan and you other thinking about these = things:

 

Wh= at has been discussed by me here so far, to give us quality of real-time = traffic over the Internet (not a small task) is:

 

1)= To direct the real-time traffic to where the network can handle such = traffic (using a network offered TURN servers) (which is not within the = scope of DISCUSS)

 

[TR] I still don=E2=80=99t understand the need to force the media = traffic to be sent through the TURN server either with DISCUSS or = PCP.

 

2)= When such a TURN server flow is allocated, it can ASSUME that it is = going to used for real-time traffic and instruct the network (e g via = setting diffserve bits) to prioritize the assumed real-time traffic. = (Giving the same prioritization to all TURN traffic works quite well. = =E2=80=93 Only if we fill the whole pipe with prioritized traffic (best = effort totally pushed off) is it important that e.g. voice if = prioritized higher than video).

 

[TR] This assumption is not right and could result in false = positives.

 

3)= When the TURN server sees the flow coming in (Note: in both directions) = it can do smarter guesswork of what traffic it is (like a DPI-box), e.g. = what is RTP and what is data channel to instruct the network = better.

 

[TR] I don=E2=80=99t think DPI will help, how will the TURN server = differentiate b/w audio and video streams when it is DTLS-SRTP ? =

Even the Home Router needs to treat these media streams differently but = may not see the need to deploy a TURN server.

 

No= w after browsing http://tools.= ietf.org/html/draft-martinsen-tram-discuss-00 =

 

4)= DISCUSS transfers information directly from the application to the = network at the time of setup of the STUN or TURN(?) server, which it = therefore can do with better detail and prediction. This is valuable, = also for reserving bandwidth in non diffserve networks like Cable and =  Mobile where one reserves bandwidth rather than use diffserve for = QoS.

 

[TR] Yes, the network can enforce any QOS policy based on the = metadata signaled by the client. Please note that during the review of = http://tool= s.ietf.org/html/draft-wing-pcp-flowdata-00 we found that there was only interest to provide GBR (Guaranteed Bit = Rate =E2=80=93 bandwidth reservation) for WebRTC media streams if the = WebRTC server has business tie-up with the Mobile network otherwise = it=E2=80=99s non-GBR for the WebRTC media streams.  This topic = needs more discussion.

 

5)= Isn=E2=80=99t DISCUSS usable with TURN? Maybe even better! And it can = be used with 1) above J

Yo= u can transfer the same information in the TURN allocate request as in = the STUN binding request, can=E2=80=99t you?. I searched for = =E2=80=9CTURN=E2=80=9D in the DISCUSS draft, but could not see it = spelled out. TURN is an extension to STUN, so maybe it is just obvious? = =E2=80=93 I have not checked details in the specs so P=C3=A5l, Tiru or = Dan knowing better, please confirm or correct !<= o:p>

 

[TR] = http://tool= s.ietf.org/html/draft-thomson-tram-turn-bandwidth-00 addresses the problem you had mentioned, it needs to be enhanced = with more metadata and the other advantage is TURN server can respond in = the ALLOCATE response if it can meet the flow characteristics or = not.  It=E2=80=99s discussed in section http://tool= s.ietf.org/html/draft-thomson-tram-turn-bandwidth-00#section-4.2 of the draft.  My point is it=E2=80=99s only useful if TURN is = selected because direct connectivity using host/server-reflexive = candidates failed or relayed candidates are only advertised for privacy = reason.

 

So= me observations:

 

a.= In DISCUSS using STUN, the network element doing the diffserv or = reservation settings WOULD be in the default = gateway.

b.= In DISCUSS using TURN, the TURN server doing the diffserv or = reservation settings COULD be in the default gateway. (The = auto-discovery of the TURN server would simply point out the default = gateway.)

 

So= und very similar: Could not DISCUSS over TURN always be = used?

 

c.= With DISCUSS using TURN, the application would directly talk to the = network device doing the diffserve settings etc. (instead of through it, = where typically the default gateway would snope that talk). Would that = not easy some of the concerns in the draft left for further discussion? =

 

d.= Can we add info in the response? E.g. if the network device is only = willing to give 1 Mbps instead of needed 3 Mbps, so the application can = be informed to reduce his video resolution? Would be a nice mechanism = when RTC alone starts filling our pipes. (I saw a similar idea by = P=C3=A5l in the previous email I just = commented.)

 

[TR] PCP solves the problem by providing response similar to what you = had mentioned and can also send subsequent response updating the = information about the flow, should the network conditions change. For = more details refer to http://www.= ietf.org/proceedings/87/slides/slides-87-pcp-5.pdf.

 

-Tiru.

 

6)= Please add to the DISCUSS draft that it also could reserve bandwidth in = bandwidth reservation type of networks like Cable and  Mobile = networks!

 

 

A = few more things are needed for the ultimate goal, = bringing end-to-end QoS or QoE for real-time communication to Best = Effort Internet (which does not seem impossible, but quite doable now = J = ) remains though. I=E2=80=99ll come back to those. =

 

It= will e.g. relate to how to do with INCOMING traffic, especially in = reservation type of networks, and the wild changing/stripping of = diffserve bits between ISPs.

 

Yo= u may want to check this old discussion to see if this = useful:

http://www.ie= tf.org/mail-archive/web/rtcweb/current/msg09128.html =

http://www.ie= tf.org/mail-archive/web/rtcweb/current/msg09129.html =

 

/K= arl

 

 

Fr=C3=A5n: = Tirumaleswar Reddy (tireddy) [mailto:tired= dy@cisco.com] =
Skickat: den 13 februari 2014 = 17:47
Till: Karl Stahl
Kopia: tram@ietf.or= g
=C3=84= mne: RE: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

Hi Karl,

 

I did not understand how TURN server will identify if it=E2=80=99s = WebRTC media streams or gaming traffic or some other data traffic = relayed through it to set the diffserv bits correctly = !

 

-Tiru.

From:= Karl Stahl = [mailto:karl.= stahl@intertex.se] =
Sent: Thursday, February 13, 2014 5:05 PM
To: = Tirumaleswar Reddy (tireddy); 'Hutton, Andrew'; 'Justin Uberti'; Muthu = Arul Mozhi Perumal (mperumal)
Cc: tireddy@icis= co.com; 'Simon = Perreault'; 'Oleg Moskalenko'; tram@ietf.or= g; 'Marc = Blanchet'; Dan Wing (dwing)
Subject: IMPORTANT CLARIFICATIONS: = [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise = and ISPs

 

On= the side of this TRAM-list, I also got this = question:

> Regarding the enterprise case, I am not = sure I follow your argument.

> Do you = mean that by setting up an enterprise TURN server, and open the firewall = for media over UDP from/to TURN server be the = solution?

--= -- As we all realize, that would of course not help or improve = things

 

Th= e intended solution in the enterprise case has not yet been spelled out = in this TRAM-list discussion, so for better understanding, let me copy a = few things from the discussion in September/October on the RTCWEB-list = and what is (since long) spelled out in the = draft-ietf-rtcweb-use-cases-and-requirements.

 

Fo= r better understanding, I also want to point out that a TURN can have = two interfaces (acting like a router for media between different = networks). This allows to easier understand that can TURN servers can = direct a best media path (rather than just thinking that a TURN service = is a device which media just bounces against at one interface). =

 

An= d, we can also hope for that a TURN server becomes a (common) component = of a firewall, which would allow the firewall to understand that the = media directed to it is RTC and should be prioritized whereby the = firewall can traffic shaped (back-off data traffic that may be filling = its Internet pipe) as well as e.g. set diffserve bits or take other = measures to assist proper quality handling thought the network. (These = are common mechanisms available and used in firewalls/NATs/access = routers, but TURN servers are not yet included such devices.) The same = goes for access routers/default gateways, DPIs in the transport network = itself =E2=80=93 TURN servers included in such points were media can = pass and quality measures applied may/will be very useful to get us = WebRTC media with through networks without quality = destruction.

 

Fr= om the RTCWEB mailing list September 20th (by = me):

An enterprise network = that want to keep a restrictive firewall not allowing UDP traffic, could = provide a real-time path using a TURN server paralleling the firewall, = instead of tunneling RTP through always open http or https ports = resulting in RTP media over TCP =E2=80=93 with severe quality problems = from TCP retransmissions of dropped packets. The TURN server address is = most easily provided in the same way as the IP address and DNS address. = (That would also put the right party in control =E2=80=93 The network = provider (here the enterprise) decides what is allowed on his = network.)

 <= /p>

The browser should = select which available TURN server address to use in the following = priority order, where ICE could be used to try = several:

 <= /p>

1) TURN server address = configured in the browser by the user (special cases, normally not = used)

2) TURN server address = configured by the network administrator via an =E2=80=9Cadmin policy = template=E2=80=9D

3) TURN = server address supplied by DHCP or similar automatic network = method

4) TURN server address = being supplied by the web application"

 

 

An= d from yesterdays(!) http://tools.= ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-14<= /span> = these enterprise things and necessity are spelled out = in:

 

F19     The = browser must be able to use several STUN and TURN = servers

   = ----------------------------------------------------------------

 

A22

3.3.5.  Simple Video Communication = Service, enterprise aspects

3.3.5.1.  = Description

   This use-case is = similar to the Simple Video Communication = Service

   use-case (Section 3.3.1).

 

   What is added is = aspects when using the service in enterprises.  = ICE

   is assumed in the = further description of this use-case.

 

   An enterprise that uses = a RTCWEB based web application for

   communication desires = to audit all RTCWEB based application sessions

   used from inside the = company towards any external peer.  To be = able

   to do this they deploy = a TURN server that straddles the boundary

   between the internal = and the external network.

 

   The firewall will block = all attempts to use STUN with an external

   destination unless they = go to the enterprise auditing TURN server.

   In cases where = employees are using RTCWEB applications provided by = an

   external service = provider they still want the traffic to stay = inside

   their internal network = and in addition not load the straddling TURN

   server, thus they = deploy a STUN server allowing the RTCWEB client = to

   determine its server = reflexive address on the internal side.  = Thus

   enabling cases where = peers are both on the internal side to connect

   without the traffic = leaving the internal network.  It must be

   possible to configure = the browsers used in the enterprise with

   network specific STUN = and TURN servers.  This should be possible = to

  achieve by = auto-configuration methods.  The RTCWEB functionality = will

   need to utilize both = network specific STUN and TURN resources and

   STUN and TURN servers = provisioned by the web application.

3.3.5.2.  Additional = Requirements

   = ----------------------------------------------------------------

   = REQ-ID      DESCRIPTION

   = ----------------------------------------------------------------

   = F20     The browser must support the use of STUN and = TURN

           = servers that are supplied by entities other than

           the = web application (i.e. the network provider).

   = ----------------------------------------------------------------

 

Th= ere are further requirement listed, helping us to understand the need = for auto discovery and a network provided TURN-server should be used to = ENFORCE that media takes that path (and thus, other paths e.g. suggested = by the remote MUST not happen to be used). This is related to the = mobility aspect (valid even without the roaming = idea):

3.3.6.  Simple Video = Communication Service, access change

3.3.6.1.  = Description
   This use-case is almost =
identical to the
   Simple Video =
Communication Service use-case (Section 3.3.1).  =
The
   difference is =
that the user changes network access during =
the
   =
session.
 
   The communication =
device used by one of the users has several =
network
   adapters (Ethernet, =
WiFi, Cellular).  The communication device =
is
   accessing the =
Internet using Ethernet, but the user has to start =
a
   trip during =
the session.  The communication device =
automatically
   changes to use WiFi =
when the Ethernet cable is removed and then =
moves
   to cellular access to =
the Internet when moving out of WiFi =
coverage.
   The session continues =
even though the access method changes.
3.3.6.2.  Additional = Requirements
   =
----------------------------------------------------------------
   =
REQ-ID      =
DESCRIPTION
   =
----------------------------------------------------------------
   =
F17     The communication session must survive =
across a
           =
change of the network interface used by the
           =
session
   =
----------------------------------------------------------------

3.3.7.  Simple Video = Communication Service, QoS

3.3.7.1.  = Description
   This use-case is almost =
identical to the
   Simple Video =
Communication Service, access change =
use-case
   (Section 3.3.6).  The use of Quality of =
Service (QoS) capabilities is
   =
added:
 
   The user in the =
previous use case that starts a trip is behind =
a
   common =
residential router that supports prioritization of =
traffic.
   In addition, the user's =
provider of cellular access has QoS support
   enabled.  The user =
is able to take advantage of the QoS support =
both
   when accessing via the =
residential router and when using cellular.
3.3.7.2.  Additional = Requirements
   =
----------------------------------------------------------------
   =
REQ-ID      =
DESCRIPTION
   =
----------------------------------------------------------------
   =
F17     The communication session must survive =
across a
  =
         change of the =
network interface used by the
           =
session
   =
----------------------------------------------------------------
   =
F22     The browser must be able to receive streams =
and
           data =
from multiple peers concurrently.
   =
----------------------------------------------------------------

 

Fu= rther from the RTCWEB mailing list September 20th (by = me):

 

There are several = reasons for a network service provider to supply a TURN server as part = of his offered access:

- to keep media paths = short, specifically not sending media outside its own network to some = distant application provided TURN server

- to support mobility, = i.e. you may want to move from a LAN with a configured TURN server to = accessing via WiFi or 3G/4G OTT channels

- to offer a media path = with better quality (than best effort data = traffic).

Getting = =E2=80=9CWebRTC-ready=E2=80=9D access and we look forward to = telepresence for everyone.

 

 

I = hope this (a bit lengthy) summary of already thought-out and discussed = aspects/requirements will help us understand that the auto-discovered = TURN server is an ORDER from the enterprise and/or the NSP/ISP  to = send the media through this TURN path, and that other media paths that = may exist MUST NOT BE USED. (That is why we especially have to = watch/advice that workable media paths proposed by the remote party not = becomes used =E2=80=9Cby accident=E2=80=9D.

 

/K= arl

 

 

Fr=C3=A5n: = Tirumaleswar Reddy (tireddy) [mailto:tired= dy@cisco.com] =
Skickat: den 13 februari 2014 04:37
Till: Hutton, = Andrew; Justin Uberti; Muthu Arul Mozhi Perumal = (mperumal)
Kopia: tireddy@icis= co.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.or= g; Marc = Blanchet; Dan Wing (dwing); Karl Stahl
=C3=84mne: RE: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs

 

Hi Andy,

 

There are other ways to solve the problem for example using PCP. Can = you clarify how deploying a TURN server in the Enterprise protects the = users and the network ?

 

-Tiru.

From:= tram = [mailto:tram-= bounces@ietf.org] On = Behalf Of Hutton, Andrew
Sent: Thursday, February 13, 2014 = 1:00 AM
To: Justin Uberti; Muthu Arul Mozhi Perumal = (mperumal)
Cc: tireddy@icis= co.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.or= g; Marc = Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs

 

The case where the TURN server is the only option may become common = within enterprise networks and that might be deliberate enterprise = policy because it provides the better path (UDP through the F/W) and = protects the users and the network.

 

Andy

 

 

From:= tram = [mailto:tram-= bounces@ietf.org] On = Behalf Of Justin Uberti
Sent: 12 February 2014 = 17:46
To: Muthu Arul Mozhi Perumal (mperumal)
Cc: = tireddy@icis= co.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.or= g; Marc = Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] = Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs

 

Agree. If TURN is indeed being provided for the user's = benefit, the client's ICE logic (based on RTT or similar) should result = in it preferring the TURN path.

 

On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

Yes, I = believe the second case is rare, but would be better than a rat race b/w = administrators trying to block p2p traffic and force it through a TURN = server and apps/endpoints finding smarter ways to bypass = them.

 

Muthu

 

From:= Oleg = Moskalenko [mailto:mom040267@gm= ail.com] =
Sent: Wednesday, February 12, 2014 1:07 PM
To: = Muthu Arul Mozhi Perumal (mperumal)
Cc: Justin Uberti; Karl = Stahl; tireddy@icis= co.com; Marc = Blanchet; tram@ietf.or= g; Dan Wing = (dwing); Simon Perreault


Subject: Re: [tram] Milestone 3: TURN server = auto-discovery mechanism for enterprise and = ISPs

 

The TURN server has to be used when it is either the only = option, or if it provides a better path (I guess the second case is = rather rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal = (mperumal) <mperumal@cisco.com> = wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would = provide the best user experience doesn't look the right approach. = Instead, if a path through a TURN server exists and does provide lower = RTT, jitter etc, being able to detect and use (or switch to) that path = might be desirable..

 

Muthu

 

From:= tram = [mailto:tram-bounces= @ietf.org] On = Behalf Of Justin Uberti
Sent: Wednesday, February 12, 2014 = 11:43 AM
To: Karl Stahl
Cc: tireddy@icis= co.com; Marc = Blanchet; tram@ietf.or= g; Dan Wing = (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) traffic.

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  =E2=80= =9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated why TURN is the right = technology here, compared to a more transparent flow identification tool = like MALICE. We don't force all HTTP requests to locate a HTTP proxy via = anycast, I don't see why we need to do the same for = WebRTC. 

&n= bsp;

Wh= at are the hesitations raised here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method=E2=80=99s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion point.

 

I think that "fooling" is an incorrect = description. The NAT is supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time traffic. = J =

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and possible). =

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become = =E2=80=9CTURN=E2=80=A6to identify WebRTC flows=E2=80=9D

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues =E2=80=9Cbecause it is all about = bandwidth=E2=80=9D, =E2=80=9Cit will resolve itself with time=E2=80=9D = etc., I strongly object! That is wrong and will be very detrimental for = WebRTC usage. We already see it and I can give numerous examples of how = much less quality demanding VoIP is/is not handled quality wise and that = it matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = =E2=80=93 At least forward thinking carrier=E2=80=99s realize that = already. Web RTC will happen. Which customers want to pay for an access = with blocked WebRTC? The carrier=E2=80=99s offering/assuring good WebRTC = will rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this=E2=80=A6) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone.

 

Skype, Hangouts, Facetime are doing billions of minutes per = week and the Internet has not melted yet. If we need to do flow = identification to allow traffic to be prioritized, fine (see above = regarding my preferred approach), but forcing all WebRTC traffic through = a MITM (TURN server) is a much bigger jump that I don't yet see the = justification for.

 

In short: TURN is a technology that is supposed to fade = away with the move to IPv6. I don't think we want to make it a critical = element of WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=C3=A5n: Dan Wing = [mailto:dwing@cisco.= com] =
Skickat: den 11 februari 2014 18:25
Till: = Marc = Blanchet
Kopia: Justin Uberti; tireddy@icis= co.com; Karl = Stahl; tram@ietf.or= g; Simon = Perreault


=C3=84= mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs

 

 

On Feb 11, = 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:

 

Le = 2014-02-11 =C3=A0 00:39, Dan Wing <dwing@cisco.com> a =C3=A9crit :

 


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@go= ogle.com> = wrote:

 

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at all).

 

Dan, while = I agree in principle, I doubt that a user could ever say "I want = mobility or I want NAT traversal". I think the user only want the = call to succeed, whatever the properties of its network point of = attachment are.

 

So what can = we do?  Should the TURN server provide any and all services the = TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the = user might gain through TURN (e.g., enhanced privacy)?

 

-d

 

 

 

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these use-cases.

 

-d<= span lang=3DEN-US>

 

 

 

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl= @intertex.se> = wrote:

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=C3=A5n: tram [mailto:tram-bounc= es@ietf.org] = F=C3=B6r Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: = Karl Stahl; tram@ietf.= org; tireddy@ic= isco.com
=C3=84= mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =C3=A9crit :
> - Note that to achieve some of the above points, = TURN must be favored
> over STUN to enforce that the TURN-path = actually is used. (The Anycast
> method suggested below, = =E2=80=9Cautomatically=E2=80=9D does this.)

I understand the STUN = vs TURN priority issue. But I don't see how anycast affects it in any = way. Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the =E2=80=9Cautomatically=E2=80=9D within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be good.)



&g= t; - 3^rd The Anycast method below =E2=80=93 I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) =E2=80=93 The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://pos= tellation.viagenie.ca
NAT64/= DNS64 open-source        --> http://ecd= ysis.viagenie.ca
STUN/T= URN server               = --> http://num= b.viagenie.ca
______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

__= _____________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.= org
https://ww= w.ietf.org/mailman/listinfo/tram

 

 

<= /div>

 


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

 

 

------=_NextPart_000_01A5_01CF2E48.EB977B50-- From nobody Thu Feb 20 05:35:56 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DA91A0160 for ; Thu, 20 Feb 2014 05:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 qyRquQkKIRVd for ; Thu, 20 Feb 2014 05:35:35 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id C687E1A0163 for ; Thu, 20 Feb 2014 05:35:33 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402201435266879; Thu, 20 Feb 2014 14:35:26 +0100 From: "Karl Stahl" To: "'Pal Martinsen \(palmarti\)'" , "'Tirumaleswar Reddy \(tireddy\)'" References: <913383AAA69FF945B8F946018B75898A242AD1CF@xmb-rcd-x10.cisco.com> <006701cf28af$9c2a27f0$d47e77d0$@stahl@intertex.se> <913383AAA69FF945B8F946018B75898A242AD996@xmb-rcd-x10.cisco.com> <03d901cf2be1$a4b78400$ee268c00$@stahl@intertex.se> In-Reply-To: Date: Thu, 20 Feb 2014 14:35:25 +0100 Message-ID: <01a901cf2e40$9c888110$d5998330$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01AA_01CF2E48.FE4CE910" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPK+GsGlWR8bzsTUukQ41JgJobVpq809cA//+8JRA= Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Orl_mq_etjG1M6BOVcSg9xvmxug Cc: tram@ietf.org, "'Dan Wing \(dwing\)'" Subject: Re: [tram] QoS for RTC over the Internet, DISCUSS: Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 13:35:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01AA_01CF2E48.FE4CE910 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01AB_01CF2E48.FE4CE910" ------=_NextPart_001_01AB_01CF2E48.FE4CE910 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi P=E5l and Tiru, =20 I was just about to catch up and respond to some of the points raised = below, but see that P=E5l has addressed a lot of them to which I mostly agree. = See below and inline to move this further: =20 Let me also point out the attached draft-deng-tram-isp-turn-00 from = China Mobile that appeared on this mailing list yesterday. It points out the = need and willingness from the ISP/NSP side to do something about QoS for = WebRTC traffic, that they expect to be large and have to bring to their = customers with best QoE. In fact they and some more (a huge European carrier and = the cable operators in general - CableLabs) have expressed similar concerns = to me =93This is exactly something we want to work on as the current way = will cause severe problem on traffic when rtcweb applications get popular=94 = is a direct quote from one of those. =20 So, in answer to Simon Perreault [simon.perreault@viagenie.ca]=92s = question in another thread the 13th: a) Is this a real problem that is worth fixing? I think we can be confident that the answer is *YES*. Only these three ISP/NSP referred to, may represent 50%(?) of the universe=92s IP = accesses! And the other will follow these most forward looking carriers.=20 =20 Even if the mission to bring quality to real-time traffic over our best effort Internet is a huge mission, I am convinced it not a huge task =96 = We just be a bit clever here J. I only see these few standard steps = required, before it can happen! =20 A) Auto-discovered TURN servers=20 =20 B) Enforcing the real-time traffic through the offered/discovered TURN servers=20 (Discussed below: Detecting a flow is not enough =96 we need to enforce = =96 more input below.)=20 =20 C) Providing real-time traffic information from the application/browser = to the network element that has the flow and can apply QoS measures (that = would be =93the box containing the TURN server=94**)=20 (DISCUSS- or draft-thomson-tram-turn-bandwidth-00.txt-like methods are = being discussed, but they do not do it all e.g. provide info of incoming = traffic and varying bandwidth requirements of smart codecs.) =20 D) Adding real-time traffic information to the media packets themselves, = to fix QoS where the above is not sufficient. This can both fix the lack of type and bandwidth info of incoming traffic (even varying) at the TURN points and also be of a great help across network boundaries/peering = points, where DSCP-bits are changed and when going into reservation type of = networks (cable and mobile) since DSCP-bits gives no clue of what bandwidth needs = to be reserved =20 Here I see the recreation of the idea/intention of the RTP payload type = (PT) header as the obvious (and only?) solution. (That payload type info is = no longer available though, since we use dynamic payload types and the SDP where it says what it is all about, nowadays cannot be said to be = available to the network (usually encrypted and somewhere else than the media = flow). There is a trivial way of doing this although it has been =93considered impossible=94, see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html.=20 =20 It is simply to add the bandwidth requirement and traffic type into two parameters in the RTP header extension (which is visible in also in SRTP = =96 it is outside the encrypted payload - and the network can read it). That information should also stay with the traffic (and not be changed around like DSCP bits). The application/browser will also be able to change = this info during a call, e.g. to announce higher or lower bandwidth = requirements of varying bandwidth type of codecs or from application measures taken = by QoS feedback via RTCP. Further, these RTP extension header bits are = easily set by any browser using any operating system (which is not the case = with DSCP-bits). =20 =20 This =93trivial=94 thing is needed for the =93huge mission=94 of = =93bringing quality to real-time traffic over the best effort Internet=94. A framework is = even done in=20 http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00.=20 =20 *Time to get it done!* =20 Some further detail discussion inline below: Some of which are *IMPORTANT*. =20 Fr=E5n: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]=20 Skickat: den 19 februari 2014 12:21 Till: Karl Stahl Kopia: Tirumaleswar Reddy (tireddy); Dan Wing (dwing); tram@ietf.org =C4mne: Re: QoS for RTC over the Internet, DISCUSS: [tram] Milestone 3: = TURN server auto-discovery mechanism for enterprise and ISPs =20 =20 On 17 Feb 2014, at 14:10 pm, Karl Stahl wrote: Tiru > I did not did not understand how TURN server will identify if = it=92s WebRTC media streams or gaming traffic or some other data traffic = relayed through it to set the diffserv bits correctly ! --- I think you do understand=85 =96 but I will spell out that = DISCUSS/MALICE does it better and with useful detail J =20 P=E5l, Tiru, Dan and you other thinking about these things: =20 What has been discussed by me here so far, to give us quality of = real-time traffic over the Internet (not a small task) is: =20 1) To direct the real-time traffic to where the network can handle such traffic (using a network offered TURN servers) (which is not within the scope of DISCUSS) =20 I can se the usefulness of a TURN server to OTT service providers that = have their own backhaul network to transport the packets. Using such a = provider might enable a user to avoid =93hot potato=94 routing problems that = might occur on the Internet. If you quickly want to get your packets into such a OTT network service TURN is a good alternative.=20 [Karl] Mentioning OTT (as the mobile world like to call their Internet) = are you hinting at the same that comes into my mind? Their DPI box is a good place (the obvious?) for a TURN server (the DPI box then really has the = flow to dig deeper into) and may apply quality measures (reservation type) through their PCRF policy server. In such case we cannot assume that the = DPI also is the default gate (or can we?) where DISCUSS-STUN could be used. = We need to direct/enforce the flow using TURN (and could then use =93DISCUSS-TURN=94). =20 [TR] I still don=92t understand the need to force the media traffic to = be sent through the TURN server either with DISCUSS or PCP. [Karl] Another hands-on example where we have to enforce the real-time traffic flow using TURN (instead of just detecting it at the default = gateway which is the consequence of STUN) is the way quality already is implemented/deployed in >>millions of fixed line accesses. Just think = about the residential =93triple play=94 offerings (I/Intertex/Ingate do such = access boxes), where you have three IP-pipes separated at lower levels = (ADSL/ATM, VLAN on Ethernet or MPLS etc). The =93Surf Pipe=94 is the default = gateway (it is there a STUN flow happens), but the quality pipe we want to direct the real-time traffic through is another one of these pipes (so far for = voice or IP-TV), where we can and must use TURN to direct/enforce the real-time = media flow into.=20 =20 [Karl] Also, considering the enterprise case (the enterprise providing = the auto-discovered TURN server); It needs to use TURN (not STUN) to BYPASS = the firewall. - For NAT/firewall traversal reasons: TURN is required to bypass if the enterprise wants to maintain a restrictive firewall policy that does not allow STUN. - For Quality Reasons (the same): TURN is required to bypass if the enterprise wants to maintain a restrictive firewall policy that does not allow STUN. =20 *[Karl]* So, in short, we need TURN and its usage to be enforced by the auto-discovery. =20 [Karl] Tiru, I have not (had time to) check up PCP. Do you have a = pointer? Is it still relevant? =20 But, in such a scenario I would like the ICE agent to actually be able = to detect that this is the best path. We currently miss a few bits to be = able to do this. The discuss draft might help with some of that, but there = are still bits missing. =20 *[Karl]* That is interesting =96 I did not think that was possible and = may have answered someone incorrectly (was it Oleg?) whether this is = possible. Does it not conflict with the usage of auto-detected TURN server that I think we need to allow the browser to have some control over for special cases? I am thinking of: =20 WEB BROWSER BEHAVIOUR: =20 Network provided TURN servers will not appear over night, applications = may for long provide a TURN server address, and there are exceptions where = the TURN server address is preferred to be =93manually=94 configured. It is previously suggested, and to some extent discussed, that the WebRTC = browser should select the TURN server to use in the following priority order, = where ICE would assure that you get some connectivity if several candidates = are found and needs to be tested: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing) 2) TURN server address configured by the network administrator via an = =93admin policy template=94 or a WPAD method as mentioned below (Justin=92s) 3) TURN server address auto-discovered by the mechanism discussed here = [TRAM Milestone 3] 4) TURN server address being supplied by the web application =20 With a good step 3), step 2) becomes obsolete since the network administrator e.g. simply can set a route in the enterprise firewall to = use the Anycast mechanism instead.=20 =20 P=E5l, are you thinking of a modification of ICE to allow the browser to = tell ICE to do this selection? =20 To me this is not a QoS feature, it is a way to avoid potential =93hot = potato=94 routing problems.=20 [Karl] The examples I just gave above shows it is both =20 2) When such a TURN server flow is allocated, it can ASSUME that it is = going to used for real-time traffic and instruct the network (e g via setting diffserve bits) to prioritize the assumed real-time traffic. (Giving the same prioritization to all TURN traffic works quite well. =96 Only if we = fill the whole pipe with prioritized traffic (best effort totally pushed off) = is it important that e.g. voice if prioritized higher than video). =20 I think to assume that TURN equals real-time traffic is wrong. It is a generic relay service and should be treated like that.=20 [Karl] My capitalizaition of ASSUME indicated that I fully agree J (I = just pointed out what is possible =96 not recommended) =20 3) When the TURN server sees the flow coming in (Note: in both = directions) it can do smarter guesswork of what traffic it is (like a DPI-box), e.g. what is RTP and what is data channel to instruct the network better. =20 Yes. The would be able to see most of the traffic and may make smart correlations. But again there is no guarantee in the future that the = traffic will be as symmetric as it is today. As long as you have set the permissions correct, the TURN server would forward you the packets. [Karl] Again, I fully agree J (=93guesswork=94 indicates it is possible = =96 not recommended) [TR] This assumption is not right and could result in false positives.=20 [TR] I don=92t think DPI will help, how will the TURN server = differentiate b/w audio and video streams when it is DTLS-SRTP ?=20 Even the Home Router needs to treat these media streams differently but = may not see the need to deploy a TURN server.=20 [Karl] I think we also agree that there are better methods we should use (even if =93guesswork=94 could be even smarter by linking RTP ids into = flows, making assumptions about that voice are smaller packets, video are full packets etc. etc). Also, we don=92t want to waste CPU power on smart = guesswork if there are better ways and further, we don=92t want to prioritize more = than required (thus vasting valuable quality bandwidth). So I fully agree to = use better methods available. =20 =20 Now after browsing http://tools.ietf.org/html/draft-martinsen-tram-discuss-00 =20 4) DISCUSS transfers information directly from the application to the network at the time of setup of the STUN or TURN(?) server, which it therefore can do with better detail and prediction. This is valuable, = also for reserving bandwidth in non diffserve networks like Cable and Mobile where one reserves bandwidth rather than use diffserve for QoS. Yes. =20 But the values are expected to change, so the network should be able to = pick up any STUN messages carrying this information even after the sessions established. We want to limit the information exchange during the ICE connectivity check to a bare minimum, but still be able to possibly take smarter path decisions once the connectivity checks are finished. Once = the session is established some security can probably be relaxed and we have more time to actually signal more detailed information.=20 =20 *[Karl]* If we enforce TURN usage of the auto-discovered TURN server, we don=92t need to fix such obstacle, do we? =20 =20 5) Isn=92t DISCUSS usable with TURN? Maybe even better! And it can be = used with 1) above J You can transfer the same information in the TURN allocate request as in = the STUN binding request, can=92t you?. I searched for =93TURN=94 in the = DISCUSS draft, but could not see it spelled out. TURN is an extension to STUN, = so maybe it is just obvious? =96 I have not checked details in the specs so = P=E5l, Tiru or Dan knowing better, please confirm or correct! =20 Yes. The discuss draft only defines a se of new STUN attributes. They = can be used in any STUN/TURN message. [Karl] Very good J =20 But there are some interesting pitfalls though. TURN allocation messages = are sent during the ICE candidate discovery phase. Once the connectivity = checks commences we will have some STUN Binding Request tunnelled over the allocation in Send and Data indication messages. Some thought should be done on how the network element between the TURN agent and TURN server should treat such messages if both of them contain some discuss = attributes. (How =93deep=94 should it search for STUN packets containing discuss = attributes, and what would they tell you) *[Karl]* Can this be said to relate to what I (above and otherwise) said about that DISCUSS only apply to outgoing traffic (not incoming). [I = admit not having read/grasped all details of DISCUSS]. Can/is this addressed = by using info from my D) above: Adding the bandwidth requirement and = traffic type info into the RTP header extension? =20 I will try to write something describing this in the next version of the discuss draft.=20 *[Karl]* Please consider my D) above: Whether adding the bandwidth requirement and traffic type into the RTP header extension can ease or = fix this! Some observations: =20 a. In DISCUSS using STUN, the network element doing the diffserv or reservation settings WOULD be in the default gateway. b. In DISCUSS using TURN, the TURN server doing the diffserv or = reservation settings COULD be in the default gateway. (The auto-discovery of the = TURN server would simply point out the default gateway.) =20 Sound very similar: Could not DISCUSS over TURN always be used? =20 Sure discuss attributes can be used with TURN allocation and session = refresh messages to inform possible discuss aware network elements on that path = what is going on.=20 c. With DISCUSS using TURN, the application would directly talk to the network device doing the diffserve settings etc. (instead of through it, where typically the default gateway would snope that talk). Would that = not easy some of the concerns in the draft left for further discussion? =20 Adding discuss attributes to TURN messages would help between the agent = and the TURN server. Those messages would not go end to end, and would not = help other network elements to =93do the right thing=94. This is useful, but = a limiting factor.=20 d. Can we add info in the response? E.g. if the network device is only willing to give 1 Mbps instead of needed 3 Mbps, so the application can = be informed to reduce his video resolution? Would be a nice mechanism when = RTC alone starts filling our pipes. (I saw a similar idea by P=E5l in the = previous email I just commented.) =20 There is a ECN like response in discuss that allows you to faster rate = limit instead of waiting for the RTCP reports to do the trick.=20 =20 Reporting available bandwidth consistently from a network element is = tricky. It varies from device to device that it can report. Is it the entire downlink speed, or maximum bandwidth pr user/ip or pr application. If we = can figure out a consistent way to report that, it would be very useful to = the ICE state machine when choosing the path.=20 =20 =20 6) Please add to the DISCUSS draft that it also could reserve bandwidth = in bandwidth reservation type of networks like Cable and Mobile networks! =20 We have on purpose avoided wording like reservation. It implies user authentication and that opens up another can of worms. But reusing some = of the discuss attributes and adding functionality to do reservation in = another draft makes sense.=20 =20 The discuss draft have a very limited scope. We want to keep it simple = to implement for both applications and network elements. If it brings any = real value needs more discussion. Hopefully those discussion can happen here = in TRAM. **[Karl]* For similar reasons I have started to say things like =93the = box containing the TURN server=94. We should not change the TURN server spec = into including specific QoS methods to apply (like reservation, changing DSCP bits or applying traffic shaping mechanism). What is happening here is = that we share the traffic information that the TURN server gets hold of, with = a QoS applying function (that will be different for different networks) in =93the same box=94. With =93the same box=94 I mean that we for now = don=92t care about the interface/commands for sharing information between the TURN server = and the QoS applying function. There may be a future need to = specify/standardize this, but if we start doing that now and in TRAM, we risk ending up in a 10-year process before having something in place (which without a spec automatically will happen in vendor=92s product development, by putting = the TURN server into already available =93QoS applying function=94 boxes = (like firewalls or the mobile DPI/PCRF combination). =20 *What we need to consider and specify, is only what traffic info is = required (to be provided by the application/browser) for =93QoS applying = functions=94 in different networks (including the very common reservation types) to do = job (i.e. giving us good QoE for real-time applications).* /Karl =20 .-. P=E5l-Erik =20 A few more things are needed for the ultimate goal, bringing end-to-end = QoS or QoE for real-time communication to Best Effort Internet (which does = not seem impossible, but quite doable now J ) remains though. I=92ll come = back to those. =20 It will e.g. relate to how to do with INCOMING traffic, especially in reservation type of networks, and the wild changing/stripping of = diffserve bits between ISPs. =20 You may want to check this old discussion to see if this useful: http://www.ietf.org/mail-archive/web/rtcweb/current/msg09128.html http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =20 /Karl =20 =20 Fr=E5n: Tirumaleswar Reddy (tireddy) [ mailto:tireddy@cisco.com]=20 Skickat: den 13 februari 2014 17:47 Till: Karl Stahl Kopia: tram@ietf.org =C4mne: RE: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 Hi Karl, =20 I did not understand how TURN server will identify if it=92s WebRTC = media streams or gaming traffic or some other data traffic relayed through it = to set the diffserv bits correctly ! =20 -Tiru. From: Karl Stahl [ mailto:karl.stahl@intertex.se]=20 Sent: Thursday, February 13, 2014 5:05 PM To: Tirumaleswar Reddy (tireddy); 'Hutton, Andrew'; 'Justin Uberti'; = Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; 'Simon Perreault'; 'Oleg Moskalenko'; tram@ietf.org; 'Marc = Blanchet'; Dan Wing (dwing) Subject: IMPORTANT CLARIFICATIONS: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 On the side of this TRAM-list, I also got this question: > Regarding the enterprise case, I am not sure I follow your argument. > Do you mean that by setting up an enterprise TURN server, and open the firewall for media over UDP from/to TURN server be the solution? ---- As we all realize, that would of course not help or improve things =20 The intended solution in the enterprise case has not yet been spelled = out in this TRAM-list discussion, so for better understanding, let me copy a = few things from the discussion in September/October on the RTCWEB-list and = what is (since long) spelled out in the draft-ietf-rtcweb-use-cases-and-requirements. =20 For better understanding, I also want to point out that a TURN can have = two interfaces (acting like a router for media between different networks). = This allows to easier understand that can TURN servers can direct a best = media path (rather than just thinking that a TURN service is a device which = media just bounces against at one interface). =20 And, we can also hope for that a TURN server becomes a (common) = component of a firewall, which would allow the firewall to understand that the media directed to it is RTC and should be prioritized whereby the firewall can traffic shaped (back-off data traffic that may be filling its Internet = pipe) as well as e.g. set diffserve bits or take other measures to assist = proper quality handling thought the network. (These are common mechanisms = available and used in firewalls/NATs/access routers, but TURN servers are not yet included such devices.) The same goes for access routers/default = gateways, DPIs in the transport network itself =96 TURN servers included in such = points were media can pass and quality measures applied may/will be very useful = to get us WebRTC media with through networks without quality destruction. =20 >From the RTCWEB mailing list September 20th (by me): An enterprise network that want to keep a restrictive firewall not = allowing UDP traffic, could provide a real-time path using a TURN server = paralleling the firewall, instead of tunneling RTP through always open http or https ports resulting in RTP media over TCP =96 with severe quality problems = from TCP retransmissions of dropped packets. The TURN server address is most easily provided in the same way as the IP address and DNS address. (That would also put the right party in control =96 The network provider (here = the enterprise) decides what is allowed on his network.) =20 The browser should select which available TURN server address to use in = the following priority order, where ICE could be used to try several: =20 1) TURN server address configured in the browser by the user (special = cases, normally not used) 2) TURN server address configured by the network administrator via an = =93admin policy template=94 3) TURN server address supplied by DHCP or similar automatic network = method 4) TURN server address being supplied by the web application" =20 =20 And from yesterdays(!) http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-1= 4 these enterprise things and necessity are spelled out in: =20 F19 The browser must be able to use several STUN and TURN servers ---------------------------------------------------------------- =20 A22 =20 3.3.5. Simple Video Communication Service, enterprise aspects =20 3.3.5.1. Description This use-case is similar to the Simple Video Communication Service use-case ( Section 3.3.1). =20 What is added is aspects when using the service in enterprises. ICE is assumed in the further description of this use-case. =20 An enterprise that uses a RTCWEB based web application for communication desires to audit all RTCWEB based application sessions used from inside the company towards any external peer. To be able to do this they deploy a TURN server that straddles the boundary between the internal and the external network. =20 The firewall will block all attempts to use STUN with an external destination unless they go to the enterprise auditing TURN server. In cases where employees are using RTCWEB applications provided by an external service provider they still want the traffic to stay inside their internal network and in addition not load the straddling TURN server, thus they deploy a STUN server allowing the RTCWEB client to determine its server reflexive address on the internal side. Thus enabling cases where peers are both on the internal side to connect without the traffic leaving the internal network. It must be possible to configure the browsers used in the enterprise with network specific STUN and TURN servers. This should be possible to achieve by auto-configuration methods. The RTCWEB functionality will need to utilize both network specific STUN and TURN resources and STUN and TURN servers provisioned by the web application. =20 3.3.5.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F20 The browser must support the use of STUN and TURN servers that are supplied by entities other than the web application (i.e. the network provider). ---------------------------------------------------------------- =20 There are further requirement listed, helping us to understand the need = for auto discovery and a network provided TURN-server should be used to = ENFORCE that media takes that path (and thus, other paths e.g. suggested by the remote MUST not happen to be used). This is related to the mobility = aspect (valid even without the roaming idea): =20 3.3.6. Simple Video Communication Service, access change =20 3.3.6.1. Description This use-case is almost identical to the Simple Video Communication Service use-case ( Section 3.3.1). The difference is that the user changes network access during the session. =20 The communication device used by one of the users has several network adapters (Ethernet, WiFi, Cellular). The communication device is accessing the Internet using Ethernet, but the user has to start a trip during the session. The communication device automatically changes to use WiFi when the Ethernet cable is removed and then moves to cellular access to the Internet when moving out of WiFi coverage. The session continues even though the access method changes. =20 3.3.6.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- =20 3.3.7. Simple Video Communication Service, QoS =20 3.3.7.1. Description This use-case is almost identical to the Simple Video Communication Service, access change use-case ( Section 3.3.6). The use of Quality of Service (QoS) capabilities is added: =20 The user in the previous use case that starts a trip is behind a common residential router that supports prioritization of traffic. In addition, the user's provider of cellular access has QoS support enabled. The user is able to take advantage of the QoS support both when accessing via the residential router and when using cellular. =20 3.3.7.2. Additional Requirements ---------------------------------------------------------------- REQ-ID DESCRIPTION ---------------------------------------------------------------- F17 The communication session must survive across a change of the network interface used by the session ---------------------------------------------------------------- F22 The browser must be able to receive streams and data from multiple peers concurrently. ---------------------------------------------------------------- =20 Further from the RTCWEB mailing list September 20th (by me): =20 There are several reasons for a network service provider to supply a = TURN server as part of his offered access: - to keep media paths short, specifically not sending media outside its = own network to some distant application provided TURN server - to support mobility, i.e. you may want to move from a LAN with a configured TURN server to accessing via WiFi or 3G/4G OTT channels - to offer a media path with better quality (than best effort data = traffic). Getting =93WebRTC-ready=94 access and we look forward to telepresence = for everyone. =20 =20 I hope this (a bit lengthy) summary of already thought-out and discussed aspects/requirements will help us understand that the auto-discovered = TURN server is an ORDER from the enterprise and/or the NSP/ISP to send the = media through this TURN path, and that other media paths that may exist MUST = NOT BE USED. (That is why we especially have to watch/advice that workable = media paths proposed by the remote party not becomes used =93by accident=94. =20 /Karl =20 =20 Fr=E5n: Tirumaleswar Reddy (tireddy) [ mailto:tireddy@cisco.com]=20 Skickat: den 13 februari 2014 04:37 Till: Hutton, Andrew; Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Kopia: tireddy@icisco.com; Simon Perreault; Oleg Moskalenko; tram@ietf.org; Marc Blanchet; = Dan Wing (dwing); Karl Stahl =C4mne: RE: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 Hi Andy, =20 There are other ways to solve the problem for example using PCP. Can you clarify how deploying a TURN server in the Enterprise protects the users = and the network ? =20 -Tiru. From: tram [ = mailto:tram-bounces@ietf.org] On Behalf Of Hutton, Andrew Sent: Thursday, February 13, 2014 1:00 AM To: Justin Uberti; Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan = Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The case where the TURN server is the only option may become common = within enterprise networks and that might be deliberate enterprise policy = because it provides the better path (UDP through the F/W) and protects the users = and the network. =20 Andy =20 =20 From: tram [ = mailto:tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: 12 February 2014 17:46 To: Muthu Arul Mozhi Perumal (mperumal) Cc: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan = Wing (dwing); Karl Stahl Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Agree. If TURN is indeed being provided for the user's benefit, the = client's ICE logic (based on RTT or similar) should result in it preferring the = TURN path. =20 On Wed, Feb 12, 2014 at 1:27 AM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: Yes, I believe the second case is rare, but would be better than a rat = race b/w administrators trying to block p2p traffic and force it through a = TURN server and apps/endpoints finding smarter ways to bypass them. =20 Muthu =20 From: Oleg Moskalenko [mailto: mom040267@gmail.com]=20 Sent: Wednesday, February 12, 2014 1:07 PM To: Muthu Arul Mozhi Perumal (mperumal) Cc: Justin Uberti; Karl Stahl; tireddy@icisco.com; Marc Blanchet; = tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 The TURN server has to be used when it is either the only option, or if = it provides a better path (I guess the second case is rather rare). =20 On Tue, Feb 11, 2014 at 11:32 PM, Muthu Arul Mozhi Perumal (mperumal) < mperumal@cisco.com> wrote: +1 =20 Forcing all traffic through a TURN server and expecting it would provide = the best user experience doesn't look the right approach. Instead, if a path through a TURN server exists and does provide lower RTT, jitter etc, = being able to detect and use (or switch to) that path might be desirable.. =20 Muthu =20 From: tram [mailto: = tram-bounces@ietf.org] On Behalf Of Justin Uberti Sent: Wednesday, February 12, 2014 11:43 AM To: Karl Stahl Cc: tireddy@icisco.com; Marc Blanchet; tram@ietf.org; Dan Wing (dwing); Simon Perreault Subject: Re: [tram] Milestone 3: TURN server auto-discovery mechanism = for enterprise and ISPs =20 Inline. =20 On Tue, Feb 11, 2014 at 2:37 PM, Karl Stahl < karl.stahl@intertex.se> wrote: Listening to this thread, I am afraid we are missing the very point and necessity for this milestone! - There are severe NAT traversal and quality issues that should and can = be dealt with by a good auto-discovery mechanism and the right usage by the turn client (the WebRTC browser) =20 There are ways, not only: Enterprises or ISPs wishing to provide their = own TURN server, in an attempt to reduce so-called "triangle routing",need a = new auto-discovery mechanism But also: - NSPs (Network Service Providers) want to provide a path = where the bandwidth of WebRTC is better coped with. - NSPs or Enterprises want to offer an Internet access quality pipe for prioritized RTC (Real Time Communication) traffic. - Enterprises having restrictive firewalls, want to provide a UDP-path = for WebRTC and possibly also for better quality where RTC do not compete = with data traffic. Also considering - Mobility; It is common to move from a LAN to accessing via WiFi or = 3G/4G OTT channels, all should be able to automatically offer their own = optimal TURN server =20 This leads us into =93TURN=85to identify WebRTC flows=94 etc! It is not = a mistake, but the very need for this milestone! =20 Again, it has not been demonstrated why TURN is the right technology = here, compared to a more transparent flow identification tool like MALICE. We don't force all HTTP requests to locate a HTTP proxy via anycast, I = don't see why we need to do the same for WebRTC.=20 =20 What are the hesitations raised here? > TURN primarily to identify WebRTC flows, as opposed to using it as a = NAT traversal tool. This makes me concerned that we may be using the wrong technology to solve the problem It is correct that ICE/STUN/TURN was designed to address the = NAT/Firewall traversal problem associated with real-time communication (SIP at that time). However, its largest flaw/problem is that quality things were not (could not be?) considered. The method=92s very idea (like all similar = methods for getting RTC through ordinary NAT/Firewalls) is to fool the media = through a NAT/Firewall that is unaware of what is happening. Thus, this is root = of quality issues (and bandwidth allocation optimization) that needs to be dealt with: Real-time traffic fighting with a data traffic crowded congestion point. =20 I think that "fooling" is an incorrect description. The NAT is supposed = to be transparent to the client. =20 But, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate request for a suitable pipe for quality demanding real time traffic. J ICE is a pre-protocol you use because you want a path for real-time = media between parties. Here: The browser says knock knock, I want to get media through (and of course with as good quality as required and possible). =20 If the NAT/Firewall owner and network owner are allowed to see these requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot help! =20 Hope this made it understandable on an overview level how this can = become =93TURN=85to identify WebRTC flows=94 It is also the ONLY way I can see to achieve what we want to achieve and should be the aim and requirement of this milestone. =20 I am talking about general usage of WebRTC over Internet/mobile OTT (not feeding WebRTC into application specific networks like IMS where other methods may exist). =20 This is good, not evil! =20 If the hesitations are raised because of a belief/hope/wish that there = are no or will not be severe quality issues =93because it is all about = bandwidth=94, =93it will resolve itself with time=94 etc., I strongly object! That is = wrong and will be very detrimental for WebRTC usage. We already see it and I = can give numerous examples of how much less quality demanding VoIP is/is not handled quality wise and that it matters. And, what would be bad = considering quality issues and allowing/encouraging methods to deal with them? =20 If the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and would = fight the same battle. But hopefully, those days are (soon) over =96 At least forward thinking carrier=92s realize that already. Web RTC will happen. = Which customers want to pay for an access with blocked WebRTC? The carrier=92s offering/assuring good WebRTC will rather get the customers and income = J. (Maybe the Web browser can detect and encourage this=85)=20 =20 If there are technical concerns of bad result, or better methods = allowing network providers and LAN managers to offer and inform the browser that there are good media paths to be used, and that the web browser automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this milestone. =20 Skype, Hangouts, Facetime are doing billions of minutes per week and the Internet has not melted yet. If we need to do flow identification to = allow traffic to be prioritized, fine (see above regarding my preferred = approach), but forcing all WebRTC traffic through a MITM (TURN server) is a much = bigger jump that I don't yet see the justification for. =20 In short: TURN is a technology that is supposed to fade away with the = move to IPv6. I don't think we want to make it a critical element of WebRTC. =20 /Karl =20 =20 Fr=E5n: Dan Wing [mailto: dwing@cisco.com]=20 Skickat: den 11 februari 2014 18:25 Till: Marc Blanchet Kopia: Justin Uberti; tireddy@icisco.com; = Karl Stahl; tram@ietf.org; Simon Perreault =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs =20 =20 On Feb 11, 2014, at 9:08 AM, Marc Blanchet < marc.blanchet@viagenie.ca> wrote: =20 Le 2014-02-11 =E0 00:39, Dan Wing < = dwing@cisco.com> a =E9crit : =20 On Feb 10, 2014, at 5:30 PM, Justin Uberti < juberti@google.com> wrote: =20 Good to see there is a lot of interest for this milestone. But based on = the description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. This makes = me concerned that we may be using the wrong technology to solve the = problem. =20 +1. =20 I would prefer allowing flows to establish themselves using their 'best' path, and the best path is seldom through a TURN server. When we = imagine IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 firewall. =20 =20 It seems this thread is conflating all the possible reasons / = justifications for TURN: * mobility * NAT traversal (both endpoints are behind endpoint-dependent mapping NATs) * firewall traversal (firewall blocks UDP) * enhancing privacy =20 Unfortunately the TURN server nor the endpoint really know which of = those use-cases is desired (by the user or by the IT network administrator) or necessary (for the call to work at all). =20 Dan, while I agree in principle, I doubt that a user could ever say "I = want mobility or I want NAT traversal". I think the user only want the call = to succeed, whatever the properties of its network point of attachment are. =20 So what can we do? Should the TURN server provide any and all services = the TURN client might possibly want, as that is what a robust TURN server = will do, and the endpoint should prefer TURN candidates over all others = because there might be some functionality / usefulness of TURN that the user = might gain through TURN (e.g., enhanced privacy)? =20 -d =20 =20 =20 This seems problematic. Perhaps we need a way to signal the desired use-case ("trait"), or as Justin suggests, using a different technology = for some of these use-cases. =20 -d =20 =20 =20 =20 On Mon, Feb 10, 2014 at 3:18 PM, Karl Stahl < karl.stahl@intertex.se> wrote: Simon, Good questions - see inline below --> . Some more thought is required! /Karl -----Ursprungligt meddelande----- Fr=E5n: tram [mailto: = tram-bounces@ietf.org] F=F6r Simon Perreault Skickat: den 10 februari 2014 15:16 Till: Karl Stahl; tram@ietf.org; tireddy@icisco.com =C4mne: Re: [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Karl, It is great to see such enthusiasm! Thanks! I have a couple technical questions... Le 2014-02-08 08:11, Karl Stahl a =E9crit : > - Note that to achieve some of the above points, TURN must be favored > over STUN to enforce that the TURN-path actually is used. (The Anycast > method suggested below, =93automatically=94 does this.) I understand the STUN vs TURN priority issue. But I don't see how = anycast affects it in any way. Can you please explain? --- Good point - I was a bit quick here (maybe too quick) We have given this quite bit of thought, since even if a TURN server is provided and discovered, CURRENT usage of ICE may suggest a candidate = from the remote party that will make a connection without the need/usage of = the TURN server (that we wanted to be used for the good purposes listed). The only way we found around this, was to stop STUN through the IP = default gateway (like a restrictive Enterprise firewall does inhibiting ICE connectivity, which others are concerned about...). Since the = provisioning of auto-discovery using the anycast mechanism, would be adding a route = in a default gateway, adding a firewall rule to eat STUN packets would assure that the provisioned TURN server actually becomes used (and not bypassed = "by accident"). (That was the thought behind the =93automatically=94 within = quotes.) BUT, since you brought up the question, assuming that we have the power = to enforce WebRTC usage of ICE, I believe a MUST requirement to use an auto-discovered TURN server instead of STUN, would solve the same = problem. However, thinking further (in relation to your next question - "anyone = could set up a badly-maintained" - enforcing such ICE usage may not be good.) > - 3^rd The Anycast method below =96 I see no problem > > It also has the advantage of encouraging (but not requiring) the > STUN/TURN to be built in the default gateway or NAT/firewall/access > router itself, with a second interface to a public IP address on the > WAN side. (Current volume deployed, low cost NSP triple play modems > usually have a quality assured level 2 or level 3 WAN pipe for just > voice (and another for IPTV) =96 The anycast discovered TURN-server = can > be the access gateway to such quality pipe for WebRTC media, in a > single NSP provided CPE, scaling from residential and up.) Suppose we define well-known anycast TURN server addresses. How would = this not be subject to the same service quality issues that plagued 6to4? = That is, anyone could set up a badly-maintained, under-provisioned TURN = server and announce it over BGP to the world, as it was done for 6to4 relays. Or just bad BGP outbound filter configuration. And how can = we prevent triangle routing? There is nothing guaranteeing that the anycast server you see is being provided to you by your ISP, rather than a = server sitting on the other side of the planet. --- Good point - needs to be resolved. For this I don't have a ready answer... An auto-discovered TURN server must be trusted (whatever method it is discovered by). We are trusting the one providing us with an IP address = and default gateway anyway. It would be easy if we could reuse that trust, instead of another mechanisms. Is there a good way for the browser to check that the anycast address is = not handled beyond the network service provider's default gateway? Ideas? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 =20 _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 ------=_NextPart_001_01AB_01CF2E48.FE4CE910 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= P=E5l and Tiru,

 

I = was just about to catch up and respond to some of the points raised = below, but see that P=E5l has addressed a lot of them to which I mostly = agree. See below and inline to move this = further:

 

Le= t me also point out the attached draft-deng-tram-isp-turn-00 from China = Mobile that appeared on this mailing list yesterday. It points out the = need and willingness from the ISP/NSP side to do something about QoS for = WebRTC traffic, that they expect to be large and have to bring to their = customers with best QoE. In fact they and some more (a huge European = carrier and the cable operators in general - CableLabs) have expressed = similar concerns to me “This is exactly = something we want to work on as the current way will cause severe = problem on traffic when rtcweb applications get popular&#= 8221; is a direct quote from one of those.

 

So= , in answer to Simon Perreault [simon.perreault@viagenie.ca]’s = question in another thread the 13th:

a) Is this a real problem that = is worth fixing?

I = think we can be confident that the answer is *YES*. Only these = three ISP/NSP referred to, may represent 50%(?) of the universe’s = IP accesses! And the other will follow these most forward looking = carriers.

 

Ev= en if the mission to bring quality to real-time traffic over our best = effort Internet is a huge mission, I am convinced it not a huge task = – We just be a bit clever here J. = I only see these few standard steps required, before it can = happen!

 

A)= Auto-discovered TURN servers

=A0=

B)= Enforcing the real-time traffic through the offered/discovered TURN = servers

(D= iscussed below: Detecting a flow is not enough – we need to = enforce – more input below.)

 

C)= Providing real-time traffic information from the application/browser to = the network element that has the flow and can apply QoS measures (that = would be “the box containing the TURN server”**) =

(D= ISCUSS- or draft-thomson-tram-turn-bandwidth-00.txt-like methods are = being discussed, but they do not do it all e.g. provide info of incoming = traffic and varying bandwidth requirements of smart = codecs.)

 

D)= Adding real-time traffic information to the media packets themselves, = to fix QoS where the above is not sufficient. This can both fix the lack = of =A0type and bandwidth info of incoming traffic (even varying) at the = TURN points and also be of a great help across network = boundaries/peering points, where DSCP-bits are changed and when going = into reservation type of networks (cable and mobile) since DSCP-bits = gives no clue of what bandwidth needs to be = reserved

 

He= re I see the recreation of the idea/intention of the RTP payload type = (PT) header as the obvious (and only?) solution. (That payload type info = is no longer available though, since we use dynamic payload types and = the SDP where it says what it is all about, nowadays cannot be said to = be available to the network (usually encrypted and somewhere else than = the media flow). There is a trivial way of doing this although it has = been “considered impossible”, see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html. =

 

It= is simply to add the bandwidth requirement and traffic type into two = parameters in the RTP header extension (which is visible in also in SRTP = – it is outside the encrypted payload - and the network can read = it). That information should also stay with the traffic (and not be = changed around like DSCP bits). The application/browser will also be = able to change this info during a call, e.g. to announce higher or lower = bandwidth requirements of varying bandwidth type of codecs or from = application measures taken by QoS feedback via RTCP. Further, these RTP = extension header bits are easily set by any browser using any operating = system (which is not the case with DSCP-bits).

 

 

Th= is “trivial” thing is needed for the “huge = mission” of “bringing quality to real-time traffic over the = best effort Internet”. =A0A framework is even done in =

h= ttp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00. =

 

*Time to get it done!*

 

So= me further detail discussion inline below:

So= me of which are *IMPORTANT*.

 

Fr=E5n: Pal = Martinsen (palmarti) [mailto:palmarti@cisco.com]
Skickat: den = 19 februari 2014 12:21
Till: Karl Stahl
Kopia: = Tirumaleswar Reddy (tireddy); Dan Wing (dwing); = tram@ietf.org
=C4mne: Re: QoS for RTC over the Internet, = DISCUSS: [tram] Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs

 

 

On 17 Feb 2014, at 14:10 pm, Karl Stahl <karl.stahl@intertex.se> = wrote:



Tiru > I did not did not understand how TURN server will identify = if it’s WebRTC media streams or gaming traffic or some other data = traffic relayed through it to set the diffserv bits correctly = !

--= - I think you do understand… – but I will spell out that = DISCUSS/MALICE does it better and with useful detail J=

&n= bsp;

P=E5= l, Tiru, Dan and you other thinking about these = things:

&n= bsp;

Wh= at has been discussed by me here so far, to give us quality of real-time = traffic over the Internet (not a small task) = is:

&n= bsp;

1)= To direct the real-time traffic to where the network can handle such = traffic (using a network offered TURN servers) (which is not within the = scope of DISCUSS)

&n= bsp;

I can se = the usefulness of a TURN server to OTT service providers that have their = own backhaul network to transport the packets. Using such a provider = might enable a user to avoid “hot potato” routing problems = that might occur on the Internet. If you quickly want to get your = packets into such a OTT network service TURN is a good alternative. =

[K= arl] Mentioning OTT (as the mobile world like to call their Internet) = are you hinting at the same that comes into my mind? Their DPI box is a = good place (the obvious?) for a TURN server (the DPI box then really has = the flow to dig deeper into) and may apply quality measures (reservation = type) through their PCRF policy server. In such case we cannot assume = that the DPI also is the default gate (or can we?) where DISCUSS-STUN = could be used. We need to direct/enforce the flow using TURN (and could = then use “DISCUSS-TURN”).

 

[TR] I still don’t understand the need to force the media = traffic to be sent through the TURN server either with DISCUSS or = PCP.

[K= arl] Another hands-on example where we have to enforce the real-time = traffic flow using TURN (instead of just detecting it at the default = gateway which is the consequence of STUN) is the way quality already is = implemented/deployed in >>millions of fixed line accesses. Just = think about the residential “triple play” offerings = (I/Intertex/Ingate do such access boxes), where you have three IP-pipes = separated at lower levels (ADSL/ATM, VLAN on Ethernet or MPLS etc). The = “Surf Pipe” is the default gateway (it is there a STUN flow = happens), but the quality pipe we want to direct the real-time traffic = through is another one of these pipes (so far for voice or IP-TV), where = we can and must use TURN to direct/enforce the real-time media flow = into.

 

[K= arl] Also, considering the enterprise case (the enterprise providing the = auto-discovered TURN server); =A0It needs to use TURN (not STUN) to = BYPASS the firewall.

- = For NAT/firewall traversal reasons: TURN is required to bypass if the = enterprise wants to maintain a restrictive firewall policy that does not = allow STUN.

- = For Quality Reasons (the same): TURN is required to bypass if the = enterprise wants to maintain a restrictive firewall policy that does not = allow STUN.

 

*<= b>[Karl]* So, in short, we need TURN and its usage to be enforced by = the auto-discovery.

 

[K= arl] Tiru, I have not (had time to) check up PCP. Do you have a pointer? = Is it still relevant?

 

But, = in such a scenario I would like the ICE agent to actually be able to = detect that this is the best path. We currently miss a few bits = to be able to do this. The discuss draft might help with some of that, = but there are still bits missing.

 

*<= b>[Karl]* That is interesting – I did not think that was = possible and may have answered someone incorrectly (was it Oleg?) = whether this is possible.

Do= es it not conflict with the usage of auto-detected TURN server that I = think we need to allow the browser to have some control over for special = cases? I am thinking of:

 

WEB BROWSER BEHAVIOUR:

 

Network provided TURN servers will not appear over night, applications = may for long provide a TURN server address, and there are exceptions = where the TURN server address is preferred to be “manually” = configured. It is previously suggested, and to some extent discussed, = that the WebRTC browser should select the TURN server to use in the = following priority order, where ICE would assure that you get some = connectivity if several candidates are found and needs to be = tested:

 

1) TURN server address configured in the browser by the user (special = cases, normally not used, but handy for testing)

2) TURN server address configured by the network administrator via an = “admin policy template” or a WPAD method as mentioned below = (Justin’s)

3) TURN server address auto-discovered by the mechanism discussed here = [TRAM Milestone 3]

4) TURN server address being supplied by the web = application

 

With a good step 3), step 2) becomes obsolete since the network = administrator e.g. simply can set a route in the enterprise firewall to = use the Anycast mechanism instead.

=A0=

P=E5= l, are you thinking of a modification of ICE to allow the browser to = tell ICE to do this selection?

 

To me this is not a QoS feature, it is a way to avoid = potential “hot potato” routing = problems. 

[K= arl] The examples I just gave above shows it is = both

 

2)= When such a TURN server flow is allocated, it can ASSUME that it is = going to used for real-time traffic and instruct the network (e g via = setting diffserve bits) to prioritize the assumed real-time traffic. = (Giving the same prioritization to all TURN traffic works quite well. = – Only if we fill the whole pipe with prioritized traffic (best = effort totally pushed off) is it important that e.g. voice if = prioritized higher than = video).

 

I = think to assume that TURN equals real-time traffic is wrong. It is a = generic relay service and should be treated like = that. 

[K= arl] My capitalizaition of ASSUME indicated that I fully agree = J = (I just pointed out what is possible – not = recommended)

=

&n= bsp;

3)= When the TURN server sees the flow coming in (Note: in both directions) = it can do smarter guesswork of what traffic it is (like a DPI-box), e.g. = what is RTP and what is data channel to instruct the network = better.

&n= bsp;

Yes. The = would be able to see most of the traffic and may make smart = correlations. But again there is no guarantee in the future that the = traffic will be as symmetric as it is today.  As long as you have = set the permissions correct, the TURN server would forward you the = packets.

[K= arl] =A0Again, I fully agree J = (“guesswork” indicates it is possible – not = recommended)
[TR] This assumption is not right and could result in false = positives.

[TR] I don’t think DPI will help, how will the TURN server = differentiate b/w audio and video streams when it is DTLS-SRTP ? =

Even the Home Router needs to treat these media streams differently but = may not see the need to deploy a TURN server.

[K= arl] I think we also agree that there are better methods we should use = (even if “guesswork” could be even smarter by linking RTP = ids into flows, making assumptions about that voice are smaller packets, = video are full packets etc. etc). Also, we don’t want to waste CPU = power on smart guesswork if there are better ways and further, we = don’t want to prioritize more than required (thus vasting valuable = quality bandwidth). So I fully agree to use better methods = available.

 

 

&n= bsp;

4)= DISCUSS transfers information directly from the application to the = network at the time of setup of the STUN or TURN(?) server, which it = therefore can do with better detail and prediction. This is valuable, = also for reserving bandwidth in non diffserve networks like Cable and =  Mobile where one reserves bandwidth rather than use diffserve for = QoS.

Yes.

 

But the values are expected to change, so the network = should be able to pick up any STUN messages carrying this information = even after the sessions established. We want to limit the information = exchange during the ICE connectivity check to a bare minimum, but still = be able to possibly take smarter path decisions once the connectivity = checks are finished. Once the session is established some security can = probably be relaxed and we have more time to actually signal more = detailed information. 

 

*<= b>[Karl]* If we enforce TURN usage of the auto-discovered TURN = server, we don’t need to fix such obstacle, do = we?

 

&n= bsp;

5)= Isn’t DISCUSS usable with TURN? Maybe even better! And it can be = used with 1) above J=

Yo= u can transfer the same information in the TURN allocate request as in = the STUN binding request, can’t you?. I searched for = “TURN” in the DISCUSS draft, but could not see it spelled = out. TURN is an extension to STUN, so maybe it is just obvious? – = I have not checked details in the specs so P=E5l, Tiru or Dan knowing = better, please confirm or correct!

&n= bsp;

Yes. The = discuss draft only defines a se of new STUN attributes. They can be used = in any STUN/TURN message.

[K= arl] Very good J

 

But there are some interesting pitfalls though. TURN = allocation messages are sent during the ICE candidate discovery phase. =  Once the connectivity checks commences we will have some STUN = Binding Request tunnelled over the allocation in Send and Data = indication messages.  Some thought should be done on how the = network element between the TURN agent and TURN server should treat such = messages if both of them contain some discuss attributes.  (How = “deep” should it search for STUN packets containing discuss = attributes, and what would they tell you)

*[= Karl]* = Can this be said to relate to what I (above and otherwise) said about = that DISCUSS only apply to outgoing traffic (not incoming). [I admit not = having read/grasped all details of DISCUSS]. Can/is this addressed by = using info from my D) above: Add= ing the bandwidth requirement and traffic type info into the RTP header = extension?

 

I will try to write something describing this in the = next version of the discuss draft. 

*[= Karl]* = Please consider my D) above: Whether add= ing the bandwidth requirement and traffic type into the RTP header = extension can ease or fix this!



So= me observations:

&n= bsp;

a.= In DISCUSS using STUN, the network element doing the diffserv or = reservation settings WOULD be in the default = gateway.

b.= In DISCUSS using TURN, the TURN server doing the diffserv or = reservation settings COULD be in the default gateway. (The = auto-discovery of the TURN server would simply point out the default = gateway.)

&n= bsp;

So= und very similar: Could not DISCUSS over TURN always be = used?

&n= bsp;

Sure = discuss attributes can be used with TURN allocation and session refresh = messages to inform possible discuss aware network elements on that path = what is going on. 



c.= With DISCUSS using TURN, the application would directly talk to the = network device doing the diffserve settings etc. (instead of through it, = where typically the default gateway would snope that talk). Would that = not easy some of the concerns in the draft left for further = discussion?

&n= bsp;

Adding = discuss attributes to TURN messages would help between the agent and the = TURN server. Those messages would not go end to end, and would not help = other network elements to “do the right thing”. This is = useful, but a limiting factor. 



d.= Can we add info in the response? E.g. if the network device is only = willing to give 1 Mbps instead of needed 3 Mbps, so the application can = be informed to reduce his video resolution? Would be a nice mechanism = when RTC alone starts filling our pipes. (I saw a similar idea by P=E5l = in the previous email I just = commented.)

&n= bsp;

There is = a ECN like response in discuss that allows you to faster rate limit = instead of waiting for the RTCP reports to do the = trick. 

 

Reporting available bandwidth consistently from a = network element is tricky. It varies from device to device that it can = report. Is it the entire downlink speed, or maximum bandwidth pr user/ip = or pr application. If we can figure out a consistent way to report that, = it would be very useful to the ICE state machine when choosing the = path. 

 

&n= bsp;

6)= Please add to the DISCUSS draft that it also could reserve bandwidth in = bandwidth reservation type of networks like Cable and  Mobile = networks!

&n= bsp;

We have = on purpose avoided wording like reservation. It implies user = authentication and that opens up another can of worms. But reusing some = of the discuss attributes and adding functionality to do reservation in = another draft makes sense. 

 

The discuss draft have a very limited scope. We want = to keep it simple to implement for both applications and network = elements. If it brings any real value needs more discussion. Hopefully = those discussion can happen here in TRAM.

**= [Karl]* For similar reasons I have started to say things like = &#= 8220;the box containing the TURN server”. We should not change the = TURN server spec into including specific QoS methods to apply (like = reservation, changing DSCP bits or applying traffic shaping mechanism). = What is happening here is that we share the traffic information that the = TURN server gets hold of, with a QoS applying function (that will be = different for different networks) in “the same box”. With = “the same box” I mean that we for now don’t care about = the interface/commands for sharing information between the TURN server = and the QoS applying function. There may be a future need to = specify/standardize this, but if we start doing that now and in TRAM, we = risk ending up in a 10-year process before having something in place = (which without a spec automatically will happen in vendor’s = product development, by putting the TURN server into already available = “QoS applying function” boxes (like firewalls or the mobile = DPI/PCRF combination).

 

*<= b>What we need to consider and specify, is only what traffic info is = required (to be provided by the application/browser) for “QoS = applying functions” in different networks (including the very = common reservation types) to do job (i.e. giving us good QoE for = real-time applications).*

/K= arl

 

.-.

P=E5l-Erik



&n= bsp;

A = few more things are needed for the ultimate goal, = bringing end-to-end QoS or QoE for real-time communication to Best = Effort Internet (which does not seem impossible, but quite doable = now J&n= bsp;) = remains though. I’ll come back to = those.

&n= bsp;

It= will e.g. relate to how to do with INCOMING traffic, especially in = reservation type of networks, and the wild changing/stripping of = diffserve bits between ISPs.

&n= bsp;

Yo= u may want to check this old discussion to see if this = useful:

http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg09128.html

http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg09129.html

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=E5n: Tirumaleswar= Reddy (tireddy) [mailto:tireddy@cisco.com] 
Skickat: den 13 februari = 2014 = 17:47
Till: Karl = Stahl
Kopia: tram@ietf.org
=C4mne: RE: IMPORTANT CLARIFICATIONS: = [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise = and ISPs

 

Hi Karl,

 

I did not understand how TURN server will identify if it’s = WebRTC media streams or gaming traffic or some other data traffic = relayed through it to set the diffserv bits correctly = !

 

-Tiru.

From:=  Karl Stahl = [mailto:karl.stahl@intertex.se] 
Sent: Thursday, February 13, 2014 = 5:05 PM
To: Tirumaleswar Reddy (tireddy); = 'Hutton, Andrew'; 'Justin Uberti'; Muthu Arul Mozhi Perumal = (mperumal)
Cc: tireddy@icisco.com; 'Simon Perreault'; = 'Oleg Moskalenko'; tram@ietf.org; 'Marc Blanchet'; Dan = Wing (dwing)
Subject: IMPORTANT CLARIFICATIONS: = [tram] Milestone 3: TURN server auto-discovery mechanism for enterprise = and ISPs

 

On= the side of this TRAM-list, I also got this = question:

> Regarding the enterprise case, = I am not sure I follow your argument.

> Do you = mean that by setting up an enterprise TURN server, and open the firewall = for media over UDP from/to TURN server be the = solution?

--= -- As we all realize, that would of course not help or improve = things

&n= bsp;

Th= e intended solution in the enterprise case has not yet been spelled out = in this TRAM-list discussion, so for better understanding, let me copy a = few things from the discussion in September/October on the RTCWEB-list = and what is (since long) spelled out in the = draft-ietf-rtcweb-use-cases-and-requirements.

=

&n= bsp;

Fo= r better understanding, I also want to point out that a TURN can have = two interfaces (acting like a router for media between different = networks). This allows to easier understand that can TURN servers can = direct a best media path (rather than just thinking that a TURN service = is a device which media just bounces against at one = interface).

&n= bsp;

An= d, we can also hope for that a TURN server becomes a (common) component = of a firewall, which would allow the firewall to understand that the = media directed to it is RTC and should be prioritized whereby the = firewall can traffic shaped (back-off data traffic that may be filling = its Internet pipe) as well as e.g. set diffserve bits or take other = measures to assist proper quality handling thought the network. (These = are common mechanisms available and used in firewalls/NATs/access = routers, but TURN servers are not yet included such devices.) The same = goes for access routers/default gateways, DPIs in the transport network = itself – TURN servers included in such points were media can pass = and quality measures applied may/will be very useful to get us WebRTC = media with through networks without quality = destruction.

&n= bsp;

Fr= om the RTCWEB mailing list September 20th (by = me):

An = enterprise network that want to keep a restrictive firewall not allowing = UDP traffic, could provide a real-time path using a TURN server = paralleling the firewall, instead of tunneling RTP through always open = http or https ports resulting in RTP media over TCP – with severe = quality problems from TCP retransmissions of dropped packets. The TURN = server address is most easily provided in the same way as the IP address = and DNS address. (That would also put the right party in control – = The network provider (here the enterprise) decides what is allowed on = his network.)

 <= /p>

The browser should = select which available TURN server address to use in the following = priority order, where ICE could be used to try = several:

 <= /p>

1) TURN server address = configured in the browser by the user (special cases, normally not = used)

2) TURN = server address configured by the network administrator via an = “admin policy template”

3) TURN server address = supplied by DHCP or similar automatic network = method

4) TURN = server address being supplied by the web = application"

&n= bsp;

&n= bsp;

An= d from yesterdays(!) http://tools.ietf.org/html/draft-ietf-rtcweb-use-c= ases-and-requirements-14 these enterprise things and = necessity are spelled out in:

&n= bsp;

F19     The = browser must be able to use several STUN and TURN = servers

   = ----------------------------------------------------------------

 

A22

3.3.5.  Simple Video Communication = Service, enterprise aspects

3.3.5.1.  = Description

   This use-case is = similar to the Simple Video Communication = Service

   use-case (Section = 3.3.1).

 

   What is added is = aspects when using the service in enterprises.  = ICE

   is assumed in the = further description of this use-case.

 

   An enterprise that uses = a RTCWEB based web application for

   communication desires = to audit all RTCWEB based application = sessions

   used from inside the = company towards any external peer.  To be = able

   to do this they deploy = a TURN server that straddles the = boundary

   between the internal = and the external network.

 

   The firewall will block = all attempts to use STUN with an = external

   destination unless they = go to the enterprise auditing TURN = server.

   In cases where = employees are using RTCWEB applications provided by = an

   external service = provider they still want the traffic to stay = inside

   their internal network = and in addition not load the straddling = TURN

   server, thus they = deploy a STUN server allowing the RTCWEB client = to

   determine its server = reflexive address on the internal side.  = Thus

   enabling cases where = peers are both on the internal side to = connect

   without the traffic = leaving the internal network.  It must = be

   possible to configure = the browsers used in the enterprise = with

   network specific STUN = and TURN servers.  This should be possible = to

  achieve by = auto-configuration methods.  The RTCWEB functionality = will

   need to utilize both = network specific STUN and TURN resources = and

   STUN and TURN servers = provisioned by the web application.

3.3.5.2.  Additional = Requirements

   = ----------------------------------------------------------------

   = REQ-ID      = DESCRIPTION

   = ----------------------------------------------------------------

   = F20     The browser must support the use of STUN and = TURN

           = servers that are supplied by entities other = than

           the = web application (i.e. the network = provider).

   = ----------------------------------------------------------------

&n= bsp;

Th= ere are further requirement listed, helping us to understand the need = for auto discovery and a network provided TURN-server should be used to = ENFORCE that media takes that path (and thus, other paths e.g. suggested = by the remote MUST not happen to be used). This is related to the = mobility aspect (valid even without the roaming = idea):

3.3.6.  Simple Video = Communication Service, access change

3.3.6.1.  = Description
   This use-case is almost = identical to the
   Simple Video Communication =
Service use-case (Section =
3.3.1).  The
   difference is that the user =
changes network access during the
   session.
 
   The communication device used by =
one of the users has several network
   adapters (Ethernet, WiFi, =
Cellular).  The communication device is
   accessing the Internet using =
Ethernet, but the user has to start a
   trip during the session.  =
The communication device automatically
   changes to use WiFi when the =
Ethernet cable is removed and then moves
   to cellular access to the =
Internet when moving out of WiFi coverage.
   The session continues even =
though the access method changes.
3.3.6.2.  = Additional Requirements
   = ----------------------------------------------------------------
   =
REQ-ID      DESCRIPTION
   =
----------------------------------------------------------------
   F17     The =
communication session must survive across a
       &nbs=
p;   change of the network interface used by the
       &nbs=
p;   session
   =
----------------------------------------------------------------

3.3.7.  Simple Video = Communication Service, QoS

3.3.7.1.  = Description
   This use-case is almost = identical to the
   Simple Video Communication =
Service, access change use-case
   (Section =
3.3.6).  The use of Quality of Service (QoS) =
capabilities is
   added:
 
   The user in the previous use =
case that starts a trip is behind a
   common residential router that =
supports prioritization of traffic.
   In addition, the user's provider =
of cellular access has QoS support
   enabled.  The user is able =
to take advantage of the QoS support both
   when accessing via the =
residential router and when using cellular.
3.3.7.2.  = Additional Requirements
   = ----------------------------------------------------------------
   =
REQ-ID      DESCRIPTION
   =
----------------------------------------------------------------
   F17     The =
communication session must survive across a
  =
         change of the =
network interface used by the
       &nbs=
p;   session
   =
----------------------------------------------------------------
   F22     The =
browser must be able to receive streams and
       &nbs=
p;   data from multiple peers concurrently.
   =
----------------------------------------------------------------

&n= bsp;

Fu= rther from the RTCWEB mailing list September 20th (by = me):

&n= bsp;

There are = several reasons for a network service provider to supply a TURN server = as part of his offered access:

- to keep media paths = short, specifically not sending media outside its own network to some = distant application provided TURN = server

- to = support mobility, i.e. you may want to move from a LAN with a configured = TURN server to accessing via WiFi or 3G/4G OTT = channels

- to offer = a media path with better quality (than best effort data = traffic).

Getting = “WebRTC-ready” access and we look forward to telepresence = for everyone.

&n= bsp;

&n= bsp;

I = hope this (a bit lengthy) summary of already thought-out and discussed = aspects/requirements will help us understand that the auto-discovered = TURN server is an ORDER from the enterprise and/or the NSP/ISP  to = send the media through this TURN path, and that other media paths that = may exist MUST NOT BE USED. (That is why we especially have to = watch/advice that workable media paths proposed by the remote party not = becomes used “by = accident”.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=E5n: Tirumaleswar= Reddy (tireddy) [mailto:tireddy@cisco.com] 
Skickat: den 13 februari 2014 = 04:37
Till: Hutton, Andrew; Justin = Uberti; Muthu Arul Mozhi Perumal (mperumal)
Kopia: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing = (dwing); Karl Stahl
=C4mne: RE: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

Hi Andy,

 

There are other ways to solve the problem for example using PCP. Can = you clarify how deploying a TURN server in the Enterprise protects the = users and the network ?

 

-Tiru.

From:=  tram [mailto:tram-bounces@ietf.org] On Behalf Of Hutton, = Andrew
Sent: Thursday, February 13, 2014 = 1:00 AM
To: Justin Uberti; Muthu Arul = Mozhi Perumal (mperumal)
Cc: tireddy@icisco.com; Simon Perreault; = Oleg Moskalenko; tram@ietf.org; Marc Blanchet; Dan Wing = (dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

The case where the TURN server is the only option may become common = within enterprise networks and that might be deliberate enterprise = policy because it provides the better path (UDP through the F/W) and = protects the users and the network.

 

Andy

 

 

From:=  tram = [mailto:tram-bounces@ietf.org] On Behalf Of Justin = Uberti
Sent: 12 February 2014 = 17:46
To: Muthu Arul Mozhi Perumal = (mperumal)
Cc: tireddy@icisco.com; Simon = Perreault; Oleg Moskalenko; tram@ietf.org; Marc = Blanchet; Dan Wing (dwing); Karl Stahl
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

Agree. If TURN is indeed being = provided for the user's benefit, the client's ICE logic (based on RTT or = similar) should result in it preferring the TURN = path.

 

On Wed, Feb 12, 2014 at 1:27 AM, = Muthu Arul Mozhi Perumal (mperumal) <mperumal@cisco.com> = wrote:

Yes, I = believe the second case is rare, but would be better than a rat race b/w = administrators trying to block p2p traffic and force it through a TURN = server and apps/endpoints finding smarter ways to bypass = them.

 

Muthu

 

From:=  Oleg = Moskalenko [mailto:mom040267@gmail.com] 
Sent: Wednesday, February 12, 2014 = 1:07 PM
To: Muthu Arul Mozhi Perumal = (mperumal)
Cc: Justin Uberti; Karl = Stahl; tireddy@icisco.com; Marc = Blanchet; tram@ietf.org; Dan Wing = (dwing); Simon Perreault


Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

The TURN server has to be used when = it is either the only option, or if it provides a better path (I guess = the second case is rather rare).

 

On Tue, Feb 11, 2014 at 11:32 PM, = Muthu Arul Mozhi Perumal (mperumal) <mperumal@cisco.com> = wrote:

+1

 

Forcing all traffic through a TURN server and expecting it would = provide the best user experience doesn't look the right approach. = Instead, if a path through a TURN server exists and does provide lower = RTT, jitter etc, being able to detect and use (or switch to) that path = might be desirable..

 

Muthu

 

From:=  tram = [mailto:tram-bounces@ietf.org] On Behalf Of Justin = Uberti
Sent: Wednesday, February 12, 2014 = 11:43 AM
To: Karl Stahl
Cc: tireddy@icisco.com; Marc = Blanchet; tram@ietf.org; Dan Wing = (dwing); Simon Perreault
Subject: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

Inline.

 

On Tue, Feb 11, 2014 at 2:37 PM, = Karl Stahl <karl.stahl@intertex.se> = wrote:

Li= stening to this thread, I am afraid we are missing the very point and = necessity for this milestone!

- = There are severe NAT traversal and quality issues that should and can be = dealt with by a good auto-discovery mechanism and the right usage by the = turn client (the WebRTC browser)

&n= bsp;

Th= ere are ways, not only: Enterprises or ISPs = wishing to provide their own TURN server, in an attempt to reduce = so-called "triangle routing",need a new auto-discovery = mechanism

Bu= t also: - NSPs (Network Service Providers) want to provide a path where = the bandwidth of WebRTC is better coped = with.

- = NSPs or Enterprises want to offer an Internet access quality pipe for = prioritized RTC (Real Time Communication) = traffic.

- = Enterprises having restrictive firewalls, want to provide a UDP-path for = WebRTC and possibly also for better quality where RTC do not compete = with data traffic.

Al= so considering

- = Mobility; It is common to move from a LAN to accessing via WiFi or 3G/4G = OTT channels, all should be able to automatically offer their own = optimal TURN server

&n= bsp;

Th= is leads us into  R= 20;TURN…to identify WebRTC flows” etc! It is not a mistake, but the very need for = this milestone!

 

Again, it has not been demonstrated = why TURN is the right technology here, compared to a more transparent = flow identification tool like MALICE. We don't force all HTTP requests = to locate a HTTP proxy via anycast, I don't see why we need to do the = same for WebRTC. 

&n= bsp;

Wh= at are the hesitations raised = here?

> TURN = primarily to identify WebRTC flows, as opposed to using it as a NAT = traversal tool. This makes me concerned that we may be using the wrong = technology to solve the problem

It= is correct that ICE/STUN/TURN was designed to address the NAT/Firewall = traversal problem associated with real-time communication (SIP at that = time). However, its largest flaw/problem is that quality things were not = (could not be?) considered. The method’s very idea (like all = similar methods for getting RTC through ordinary NAT/Firewalls) is to = fool the media through a NAT/Firewall that is unaware of what is = happening. Thus, this is root of quality issues (and bandwidth = allocation optimization) that needs to be dealt with: Real-time traffic = fighting with a data traffic crowded congestion = point.

 

I think that "fooling" is = an incorrect description. The NAT is supposed to be transparent to the = client.

&n= bsp;

Bu= t, a BLESSING of ICE/STUN/TURN is that it can be seen as a legitimate = request for a suitable pipe for quality demanding real time = traffic. J=

IC= E is a pre-protocol you use because you want a path for real-time media = between parties. Here: The browser says knock knock, I want to get media = through (and of course with as good quality as required and = possible).

&n= bsp;

If= the NAT/Firewall owner and network owner are allowed to see these = requests, they can help/assist in achieving the good media path. If they = are not aware, they cannot = help!

&n= bsp;

Ho= pe this made it understandable on an overview level how this can = become “TUR= N…to identify WebRTC = flows”

It= is also the ONLY way I can see to achieve what we want to achieve and = should be the aim and requirement of this = milestone.

&n= bsp;

I = am talking about general usage of WebRTC over Internet/mobile OTT (not = feeding WebRTC into application specific networks like IMS where other = methods may exist).

&n= bsp;

Th= is is good, not evil!

&n= bsp;

If= the hesitations are raised because of a belief/hope/wish that there are = no or will not be severe quality issues “because it is all about = bandwidth”, “it will resolve itself with time” etc., I = strongly object! That is wrong and will be very detrimental for WebRTC = usage. We already see it and I can give numerous examples of how much = less quality demanding VoIP is/is not handled quality wise and that it = matters. And, what would be bad considering quality issues and = allowing/encouraging methods to deal with = them?

&n= bsp;

If= the hesitations are raised, because of suspicion that the methods we = may recommend may be misused to stop/block/destroy WebRTC usage (e.g. to = protect income from carrier telephony traffic), I could understand and = would fight the same battle. But hopefully, those days are (soon) over = – At least forward thinking carrier’s realize that already. = Web RTC will happen. Which customers want to pay for an access with = blocked WebRTC? The carrier’s offering/assuring good WebRTC will = rather get the customers and income J. = (Maybe the Web browser can detect and encourage = this…) 

&n= bsp;

If= there are technical concerns of bad result, or better methods allowing = network providers and LAN managers to offer and inform the browser that = there are good media paths to be used, and that the web browser = automatically can chose those, then let us all understand those, so we = can achieve what should be achieved by this = milestone.

 

Skype, Hangouts, Facetime are doing = billions of minutes per week and the Internet has not melted yet. If we = need to do flow identification to allow traffic to be prioritized, fine = (see above regarding my preferred approach), but forcing all WebRTC = traffic through a MITM (TURN server) is a much bigger jump that I don't = yet see the justification = for.

 

In short: TURN is a technology that = is supposed to fade away with the move to IPv6. I don't think we want to = make it a critical element of = WebRTC.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=E5n: Dan Wing = [mailto:dwing@cisco.com] 
Skickat: den 11 februari 2014 = 18:25
Till: Marc = Blanchet
Kopia: Justin Uberti; tireddy@icisco.com; Karl = Stahl; tram@ietf.org; Simon = Perreault


=C4mne: Re: [tram] Milestone 3: TURN = server auto-discovery mechanism for enterprise and = ISPs

 

 

On Feb 11, 2014, at 9:08 AM, Marc Blanchet <marc.blanchet@viagenie.ca> = wrote:

 

Le 2014-02-11 =E0 00:39, Dan Wing <dwing@cisco.com> a = =E9crit :

 


On = Feb 10, 2014, at 5:30 PM, Justin Uberti <juberti@google.com> = wrote:

 

Good to = see there is a lot of interest for this milestone. But based on the = description here, it seems like we want to use TURN primarily to = identify WebRTC flows, as opposed to using it as a NAT traversal tool. = This makes me concerned that we may be using the wrong technology to = solve the problem.

 

+1.=

 

I would = prefer allowing flows to establish themselves using their 'best' path, = and the best path is seldom through a TURN server.  When we imagine = IPv6 in our future, we don't want to force an application-level proxy = (TURN) server on the path solely for traversing an IPv6 = firewall.

 

 

It seems = this thread is conflating all the possible reasons / justifications for = TURN:

  * = mobility

  * = NAT traversal (both endpoints are behind endpoint-dependent mapping = NATs)

  = * firewall traversal (firewall blocks = UDP)

  * = enhancing privacy

 

Unfortunat= ely the TURN server nor the endpoint really know which of those = use-cases is desired (by the user or by the IT network administrator) or = necessary (for the call to work at = all).

 

Dan, while I agree in principle, I doubt that a user = could ever say "I want mobility or I want NAT traversal". I = think the user only want the call to succeed, whatever the properties of = its network point of attachment = are.

 

So what can we do?  Should the TURN server = provide any and all services the TURN client might possibly want, as = that is what a robust TURN server will do, and the endpoint should = prefer TURN candidates over all others because there might be some = functionality / usefulness of TURN that the user might gain through TURN = (e.g., enhanced privacy)?

 

-d

 

 

 

 This= seems problematic.  Perhaps we need a way to signal the desired = use-case ("trait"), or as Justin suggests, using a different = technology for some of these = use-cases.

 

-d<= o:p>

 

 

 

 

On Mon, = Feb 10, 2014 at 3:18 PM, Karl Stahl <karl.stahl@intertex.se> = wrote:

Simon,
=
Good questions - see inline below --> .
Some more thought is = required!

/Karl

-----Ursprungligt = meddelande-----
Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r = Simon Perreault
Skickat: den 10 februari 2014 15:16
Till: Karl = Stahl; tram@ietf.org; tireddy@icisco.com
=C4mne= : Re: [tram] Milestone 3: TURN server auto-discovery mechanism for = enterprise and ISPs


Karl,<= br>
It is great to see such enthusiasm! Thanks!

I have a = couple technical questions...

Le 2014-02-08 08:11, Karl Stahl a = =E9crit :
> - Note that to achieve some of the above points, TURN = must be favored
> over STUN to enforce that the TURN-path actually = is used. (The Anycast
> method suggested below, = “automatically” does this.)

I understand the STUN vs = TURN priority issue. But I don't see how anycast affects it in any way. = Can you please explain?

--- Good = point - I was a bit quick here (maybe too quick)
We have given this = quite bit of thought, since even if a TURN server is provided and = discovered, CURRENT usage of ICE may suggest a candidate from the remote = party that will make a connection without the need/usage of the TURN = server (that we wanted to be used for the good purposes = listed).

The only way we found around this, was to stop STUN = through the IP default gateway (like a restrictive Enterprise firewall = does inhibiting ICE connectivity, which others are concerned about...). = Since the provisioning of auto-discovery using the anycast mechanism, = would be adding a route in a default gateway, adding a firewall rule to = eat STUN packets would assure that the provisioned TURN server actually = becomes used (and not bypassed "by accident"). (That was the = thought behind the “automatically” within = quotes.)

BUT, since you brought up the question, assuming that we = have the power to enforce WebRTC usage of ICE, I believe a MUST = requirement to use an auto-discovered TURN server instead of STUN, would = solve the same problem. However, thinking further (in relation to your = next question - "anyone could set up a badly-maintained" - = enforcing such ICE usage may not be = good.)



&g= t; - 3^rd The Anycast method below – I see no = problem
>
> It also has the advantage of encouraging (but = not requiring) the
> STUN/TURN to be built in the default gateway = or NAT/firewall/access
> router itself, with a second interface to = a public IP address on the
> WAN side. (Current volume deployed, = low cost NSP triple play modems
> usually have a quality assured = level 2 or level 3 WAN pipe for just
> voice (and another for = IPTV) – The anycast discovered TURN-server can
> be the = access gateway to such quality pipe for WebRTC media, in a
> = single NSP provided CPE, scaling from residential and = up.)

Suppose we define well-known anycast TURN server addresses. = How would this not be subject to the same service quality issues that = plagued 6to4? That is, anyone could set up a badly-maintained, = under-provisioned TURN server and announce it over BGP to the world, as = it was done for
6to4 relays. Or just bad BGP outbound filter = configuration. And how can we prevent triangle routing? There is nothing = guaranteeing that the anycast server you see is being provided to you by = your ISP, rather than a server sitting on the other side of the = planet.

--- Good = point - needs to be resolved. For this I don't have a ready = answer...
An auto-discovered TURN server must be trusted (whatever = method it is discovered by). We are trusting the one providing us with = an IP address and default gateway anyway. It would be easy if we could = reuse that trust, instead of another mechanisms.

Is there a good = way for the browser to check that the anycast address is not handled = beyond the network service provider's default gateway? = Ideas?



Thanks,
Simon
--
DTN made easy, lean, and smart = --> http://postellation.viagenie.ca
NAT64/= DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/T= URN server               = --> http://numb.viagenie.ca
______= _________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

__= _____________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

__________= _____________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram


______= _________________________________________
tram mailing = list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

 

 


_______________________________________________
tram = mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram<= /a>

=

 

------=_NextPart_001_01AB_01CF2E48.FE4CE910-- ------=_NextPart_000_01AA_01CF2E48.FE4CE910 Content-Type: text/plain; name="draft-deng-tram-isp-turn-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-deng-tram-isp-turn-00.txt" =20 MPTCP Working Group L. Deng INTERNET-DRAFT P. Fan Intended Status: Informational Hui Deng Expires: August 14, 2014 China Mobile February 14, 2014 ISP Turn Server For Third Party WEBRTC Traffic Relay draft-deng-tram-isp-turn-00 Abstract This document describes usecases and requirements for ISP to provide their own TURN servers to relay third party WEBRTC traffic.=20 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect =20 Expires August 14, 2014 [Page 1] =0C INTERNET DRAFT February 14, 2014 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Use-cases for Network deployed TURN servers . . . . . . . . . . 3 3.1 Traffic Locality . . . . . . . . . . . . . . . . . . . . . . 3 3.2 Resource Sharing . . . . . . . . . . . . . . . . . . . . . . 4 3.3 ISP QoS Support . . . . . . . . . . . . . . . . . . . . . . 4 4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 =20 Expires August 14, 2014 [Page 2] =0C INTERNET DRAFT February 14, 2014 1 Introduction Historically, stun/turn servers are not deployed by ISPs, as ICE is designed to allow network-agnostic feature. =20 It is envisioned that driven by WEBRTC movement, third party ICE (stun and turn) would see increasingly deployment boost in the coming years, as webrtc-compatible browsers rely on ICE framework to enable NAT traversal capabilities for peer-to-peer media communication. For turn, which is essentially a media relay gateway for peer-to-peer media traffic, relying exclusively in a network agnostic way is clearly not an efficient way of large volume traffic routing from the ISP's point of view. It may result in a second thought for the ISP on whether or not it should provide public TURN server facilities to third party WEBRTC applications. On the other hand, from the perspective of WEBRTC applications, cooperation with ISP deployed turn server could also mean another chance of further exploring network capability in delivering better user experience. 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3 Use-cases for Network deployed TURN servers Three cases are discussed in current draft. 3.1 Traffic Locality From an ISP's point of view, for two local WEBRTC users communicating via an third party TURN server usually result in sub-optimal outcome. If the SP's TURN server is located outside the ISP's network, the media traffic it relays has to go through the inter-working point to another ISP twice, which is usually the most congested points for the user and most expensive links for the local ISP.=20 In this case, using a local (network deployed) TURN server would result in a win-win situation. =20 Expires August 14, 2014 [Page 3] =0C INTERNET DRAFT February 14, 2014 3.2 Resource Sharing For large WEBRTC SPs, it may be tempting to build up their own relay overlay and gain sufficient efficiency for targeted areas.=20 However, small or integrated WEBRTC SPs, may prefer to make use of ISP's locally deployed relay network to reduce CAPEX and OPEX for emerging markets. On the other hand, by providing public accessible relay network and share it with multiple third party applications, the construction/management cost for an ISP is considerably small in comparison to each SP building up a private one. 3.3 ISP QoS Support For QoS sensitive traffic like WEBRCT media, it would bring substantial enhancement to user experience if relevant QoS requirement be honored and properly handled by the network devices along the way. Although there has been work on DSCP setting for various WEBRTC media packet, there is no guarantee that these end2end setting be honored by an ISP, unless they are officially recognized by the network from a QoS-enabled boundary device and/or be explicitly promised to be honored by agreement. By utilizing ISP deployed TURN server, there is an explicit way of indicating to the network the traffic is real-time interactive and should be QoS enabled. 4 Summary According to the above discussion, it is believed that making explicit usage of ISP deployed relay network would be a plus to both third party WEBRTC SPs as well as local ISPs. To enable flexible application, the ISP needs to be given an opportunity to advertise/announce to the application/WebRTC browser the availability of an optimal TURN server to use. This should also be the TURN server to use, unless there are other concerns than best quality/user experience for the application to be considered. The auto-discovery mechanism of TURN servers discussed, is a way to realize and meet the needs for the ISP to announce and enforce the usage of an optimal TURN server for quality considerations, and should not in anyway conflict with the need for NAT/firewall traversal. =20 Expires August 14, 2014 [Page 4] =0C INTERNET DRAFT February 14, 2014 5 Security Considerations TBA. 6 Acknowledgements The authors wish to thank Karl Stahl for providing comments, feedback, text and improvement proposals on the document. 7 IANA Considerations There is no IANA action in this document. =20 Expires August 14, 2014 [Page 5] =0C INTERNET DRAFT February 14, 2014 6 References 6.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Brower-based Applications", I-D.ietf-rtcweb- overview (Work in Progress), september 2013. =20 Expires August 14, 2014 [Page 6] =0C INTERNET DRAFT February 14, 2014 Authors' Addresses Lingli Deng China Mobile Email: Email: denglingli@chinamobile.com Peng Fan China Mobile Email: Email: fanpeng@chinamobile.com Hui Deng China Mobile Email: Email: denghui@chinamobile.com Expires August 14, 2014 [Page 7] ------=_NextPart_000_01AA_01CF2E48.FE4CE910-- From nobody Thu Feb 20 05:36:44 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB511A0162 for ; Thu, 20 Feb 2014 05:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 iQXo7_oO1u6L for ; Thu, 20 Feb 2014 05:36:37 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 32FEF1A0163 for ; Thu, 20 Feb 2014 05:36:36 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402201436317120; Thu, 20 Feb 2014 14:36:31 +0100 From: "Karl Stahl" To: "'Alan Johnston'" , References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> In-Reply-To: Date: Thu, 20 Feb 2014 14:36:30 +0100 Message-ID: <01af01cf2e40$c31ebd30$495c3790$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B0_01CF2E49.24E32530" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8sHMJyCzQV1hQ5R5mBacy4UF3a0gB727Ng Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/AoXru3z6FtZ4Pk__AZrfoIPuA7U Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 13:36:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01B0_01CF2E49.24E32530 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alan, =20 Can you comment/elaborate on the purpose and intended usage of this draft-thomson-tram-turn-bandwidth-00.txt? =20 I am not clear about how the negotiation of bandwidth between a TURN = client and a TURN server can be useful considering how bandwidth is shared on = the Internet today and the QoS/QoE implications of this. =20 On this mailing list, this draft has been discussed as useful for = QoS/QoE improvement, which I cannot see it is. For such purposes, richer = information than the total bandwidth needs to be conveyed to the TURN server / = network, compare e.g. DISCUSS/MALICE http://tools.ietf.org/html/draft-martinsen-tram-discuss-00. =20 In the Introduction of draft-thomson-tram-turn-bandwidth-00.txt: The operator of a TURN server will likely wish to provide fairness between relayed sessions. A TURN server might also wish to limit the use of service to audio-only sessions, or low bandwidth video and audio sessions. In addition, the server may apply rate-limiting policy depending on the credential used for authentication, or the origin of the client. Without the BANDWIDTH attribute, there is no way for a client to indicate the expected bandwidth utilization, or for the server to indicate the maximum bandwidth utilization allowed before rate limiting could be applied. =20 I interpret that this draft is about conveying a =93fairness policy=94 = etc. to the TURN server / network, without specifying how this could be realized = or implemented. Correct? More is needed for a possible the realization considering QoS/QoE. =20 If richer information is needed for the realization, that may be the attributes conveyed by DISCUSS/MALICE (but used for TURN, not STUN, see discussion in previous email). =20 On the other hand, if the information conveyed here (draft-thomson-tram-turn-bandwidth-00.txt) already is available = (directly or indirectly) in the DISCUSS attributes, maybe we could end up with a = single draft that includes the real-time traffic information and sharing policy that needs to be conveyed to the TURN server / network? Is that = something to consider? =20 Or if recreating the payload type (PT) idea/intent in RTP packets (by = now conveying bandwidth and traffic type in the RTP extension header http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is sufficient for QoS/QoE in combination with auto-discussed TURN servers, maybe draft-thomson-tram-turn-bandwidth-00.txt is the only thing we need = in addition (not the DISCUSS attributes). =20 =20 For better understanding of these QoS/QoE problems, and methods for improving (not specifically discussing the policies of sharing real-time traffic space), I would like to explain: =20 Over an IP pipe only used for real-traffic (no TCP data traffic), it is sufficient that the pipe is wide enough for good QoS. That is often used = and implemented by separating IP pipes at a lower level using e.g. Ethernet VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can enforce real-traffic into such pipes and QoS is achieved. Let=92s call = this Level 2 QoS (Network level) =20 Over an IP pipe shared between quality requiring real-time traffic and = less demanding data or streaming (usually TCP) traffic, we have the sharing between these two traffic classes to consider. The main method (and the mechanism making today=92s real-time QoE as good as it often is) is that = TCP endpoints back-off and share their bandwidth usage. Real-time traffic = using UDP transport do not back-off, the endpoints using UDP occupy the = bandwidth needed. When an IP pipe gets filled, it is all endpoint=92s TCP = bandwidth usage that is back-off and shared between them, leaving room for the UDP traffic. This is mechanism we experience everyday over the Internet, = using our =93Surf IP pipes=94. Let=92s call this Level 4 QoS (Transport level) =20 However, this Level 4 QoS is based on that at congestion times (which = happen every time we click =96 setting up a TCP flow and transferring some = amount of data as quick as possible) the router handling the most narrow part of = the pipe (the congestion point) drop packets. It is this packet dropping = that (i) signals to TCP endpoints to reduce their bandwidth (via TCP=92s = error correction/retransmission mechanism) and (ii) destroys the QoE of = real-time traffic. (Both TCP and UDP packets are dropped in this process that is triggered by flow intensive TCP traffic.) =20 We need (i) but don=92t want (ii) and to improve on this we can e.g. use diffserve, DSCP bits in IP packets to instruct routers to always forward = the real-time traffic before any unmarked TCP traffic (which usually fills = most of the pipe). Then QoS is then achieved for real-time traffic. This is = Level 3 QoS (IP level). The method used is =93traffic shaping=94: backing off = data traffic, leaving real-time traffic free passage without packet loss. =20 Here, in TRAM we want to go beyond Level 4 QoS (already available and working as good as it can on the Internet), to give quality demanding = WebRTC real-time traffic better QoE by: a. Forcing real-time traffic into IP-pipes having Level 2 QoS (using auto-discovered TURN servers)=20 or b. Forcing real-time traffic into IP-pipes having Level 3 QoS (using auto-discovered TURN servers). Here we must have traffic shaping = mechanisms working, and with correct and sufficient information to do the job. This = is why we in TRAM discuss DISCUSS/MALICE, draft-thomson-tram-turn-bandwidth-00.txt attributes and recreating the payload type (PT) idea/intent in RTP packets (by now conveying bandwidth = and traffic type in the RTP extension header http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html. =20 How these QoS/QoE things are done and used in practice is also illustrated/exemplified in this email discussion: http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html=20 =20 Prioritization of individual real-time packets (e.g. using diffserve = DSCP bits) have today little impact on the QoE, UNLESS a pipe full with only real-time traffic (which is unusual), because in today=92s IP pipes with = high bandwidth, packets are not stored for later delivery, but rather dropped = by routers implementing diffserve (after only a short time period =3D small buffer size). The only good remedy is higher bandwidth, that can handle = ALL real-time traffic.=20 =20 Prioritization of real-time packets (any diffserve DSCP bits marking) = =93makes QoS perfect=94, when there are best effort (=3Dno DSCP bits set) TCP = (=3Dnon real-time) traffic going over the IP pipe that can be pushed off. = Routers implementing diffserve do that. =20 =20 Having gone through all of this, I want to point out that the huge = mission to bring quality to real-time traffic over our best effort Internet, is = not a question of huge investments in new bandwidth (that happens anyway for data and streaming video needs) or about sharing bandwidth (bandwidth is available in access if we only consider the real-time need). It is about borrowing some already existing bandwidth from data usage. And there are only unnoticeable consequences of this borrowing; A delay of a fraction = of a second or so for click-responses or watching a movie. So the huge = mission, may be a an easy task if we do it cleverly. =20 =20 And finally, the purpose of this = draft-thomson-tram-turn-bandwidth-00.txt seems is related to how to request or buy or limit or pay for access to = the good real-time IP pipes for best QoE. =20 Isn=92t that the case Alan, rather than intended to be used as QoS/QoE improvement method (as it has been discussed). =20 /Karl =20 =20 =20 Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Alan Johnston Skickat: den 17 februari 2014 21:14 Till: tram@ietf.org =C4mne: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 All, =20 We have written a new I-D on a bandwidth attribute for TURN. The use = case is to allow a TURN client to indicate to the server the bandwidth it = expects to use for the relayed candidate, or for a TURN server to indicate to = the client the maximum bandwidth before the TURN server might apply rate limiting. =20 Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent = which was discussed in the past, but this draft does not propose an ICE use = case for consent. =20 Comments most welcome! =20 - Alan - ---------- Forwarded message ---------- From: Date: Thu, Feb 13, 2014 at 9:07 PM Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Bandwidth Attribute for TURN Authors : Martin Thomson Bernard Aboba Alan Johnston Oleg Moskalenko Filename : draft-thomson-tram-turn-bandwidth-00.txt Pages : 8 Date : 2014-02-13 Abstract: An attribute is defined for Session Traversal Utilities for NAT (STUN) that allows for declarations of bandwidth limits on the negotiated flow. The application of this attribute is the negotiation of bandwidth between a Traversal Using Relays around NAT (TURN) client and a TURN server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwidth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce =20 Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt =20 ------=_NextPart_000_01B0_01CF2E49.24E32530 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= Alan,

 

Ca= n you comment/elaborate on the purpose and intended usage of this = draft-thomson-tram-turn-bandwidth-00.txt?

 

I =
am not clear about how the ne=
gotiation of bandwidth between a TURN client and a TURN server can be =
useful considering how bandwidth is shared on the Internet today and the =
QoS/QoE implications of this.
 
On=
 this mailing list, this draft has been discussed as useful for QoS/QoE =
improvement, which I cannot see it is. For such purposes, richer =
information than the total bandwidth needs to be conveyed to the TURN =
server / network, compare e.g. DISCUSS/MALICE http://tools.ietf.org/html/draft-martinsen-tram-di=
scuss-00.
 
In=
 the Introduction of =
draft-thomson-tram-turn-bandwidth-00.txt:
=A0=A0 The operator =
of a TURN server will likely wish to provide =
fairness
=A0=A0 between =
relayed sessions.=A0 A TURN server might also wish to limit =
the
=A0=A0 use of service to audio-only sessions, or low bandwidth =
video and
=A0=A0 audio =
sessions.=A0 In addition, the server may apply =
rate-limiting
=A0 =A0policy =
depending on the credential used for authentication, or =
the
=A0=A0 origin of the client.=A0 Without the BANDWIDTH =
attribute, there is no
=A0=A0 way for a =
client to indicate the expected bandwidth utilization, =
or
=A0=A0 for the server to indicate the maximum bandwidth =
utilization allowed
=A0=A0 =
before rate limiting could be applied.
 
I =
interpret that this draft is about conveying a “fairness =
policy” etc. to the TU=
RN server / network, without specifying how this could be realized or =
implemented. Correct? More is needed for a possible the realization =
considering QoS/QoE.
 
If=
 richer information is needed for the realization, that may be the =
attributes conveyed by DISCUSS/MALICE (but used for TURN, not STUN, see =
discussion in previous email).
 
On=
 the other hand, if the information conveyed here =
(draft-thomson-tram-turn-bandwidth-00.txt) already is available =
(directly or indirectly) in the DISCUSS attributes, maybe we could end =
up with a single draft that includes the real-time traffic information =
and sharing policy that needs to be conveyed to the TURN server / =
network? Is that something to =
consider?
 
Or=
 if re=
creating the payload type (PT) idea/intent in RTP packets (by now =
conveying bandwidth and traffic type in the RTP extension header =
http://www.ietf.org/mail-archive/web/rtcweb/curren=
t/msg09129.html is sufficient for QoS/QoE in combination with =
auto-discussed TURN servers, maybe =
draft-thomson-tram-turn-bandwidth-00.txt is the only thing we need in =
addition (not the DISCUSS attributes).
 
 
Fo=
r better understanding of these QoS/QoE problems, and methods for =
improving (not specifically discussing the policies of sharing real-time =
traffic space), I would like to =
explain:
 
Ov=
er an IP pipe only used for real-traffic (no TCP data traffic), it is =
sufficient that the pipe is wide enough for good QoS. That is often used =
and implemented by separating IP pipes at a lower level using e.g. =
Ethernet VLAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN =
servers can =A0enforce real-traffic into such pipes and QoS is achieved. =
Let’s call this Level 2 QoS (Network =
level)
 
Ov=
er an IP pipe shared between quality requiring real-time traffic and =
less demanding data or streaming (usually TCP) traffic, we have the =
sharing between these two traffic classes to consider. The main method =
(and the mechanism making today’s real-time QoE as good as it =
often is) is that TCP endpoints back-off and share their bandwidth =
usage. Real-time traffic using UDP transport do not back-off, the =
endpoints using UDP occupy the bandwidth needed. When an IP pipe gets =
filled, it is all endpoint’s TCP bandwidth usage that is back-off =
and shared between them, leaving room for the UDP traffic. This is =
mechanism we experience everyday over the Internet, using our =
“Surf IP pipes”. Let’s call this Level 4 QoS =
(Transport level)
 
Ho=
wever, this Level 4 QoS is based on that at congestion times (which =
happen every time we click – setting up a TCP flow and =
transferring some amount of data as quick as possible) the router =
handling the most narrow part of the pipe (the congestion point) drop =
packets. It is this packet dropping that (i) signals to TCP endpoints to =
reduce their bandwidth (via TCP’s error correction/retransmission =
mechanism) and (ii) destroys the QoE of real-time traffic. (Both TCP and =
UDP packets are dropped in this process that is triggered by flow =
intensive TCP traffic.)
 
We=
 need (i) but don’t want (ii) and to improve on this we can e.g. =
use diffserve, DSCP bits in IP packets to instruct routers to always =
forward the real-time traffic before any unmarked TCP traffic (which =
usually fills most of the pipe). Then QoS is then achieved for real-time =
traffic. This is Level 3 QoS (IP level). The method used is =
“traffic shaping”: backing off data traffic, leaving =
real-time traffic free passage without packet =
loss.
 
He=
re, in TRAM we want to go beyond Level 4 QoS (already available and =
working as good as it can on the Internet), to give quality demanding =
WebRTC real-time traffic better QoE =
by:
a.=
 Forcing real-time traffic into IP-pipes having Level 2 QoS (using =
auto-discovered TURN servers) 
or=

b.= Forcing real-time traffic into IP-pipes having Level 3 QoS (using = auto-discovered TURN servers). Here we must have traffic shaping = mechanisms working, and with correct and sufficient information to do = the job. This is why we in TRAM discuss DI= SCUSS/MALICE, draft-thomson-tram-turn-bandwidth-00.txt attributes and = recreating the payload type (PT) idea/intent in RTP packets (by now = conveying bandwidth and traffic type in the RTP extension header = http://www.ietf.org/mail-archive/web/rtcweb/curren= t/msg09129.html.

 
Ho=
w these QoS/QoE things are done and used in practice is also =
illustrated/exemplified in this email =
discussion:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html =

 
Pr=
ioritization of individual real-time packets (e.g. using diffserve DSCP =
bits) have today little impact on the QoE, UNLESS a pipe full with only =
real-time traffic (which is unusual), because in today’s IP pipes =
with high bandwidth, packets are not stored for later delivery, but =
rather dropped by routers implementing diffserve (after only a short =
time period =3D small buffer size). The only good remedy is higher =
bandwidth, that can handle ALL real-time traffic. =

 
Pr=
ioritization of real-time packets (any diffserve DSCP bits marking) =
“makes QoS perfect”, when there are best effort (=3Dno DSCP =
bits set) TCP (=3Dnon real-time) traffic going over the IP pipe that can =
be pushed off. Routers implementing diffserve do =
that.
 
 =
=A0
Ha=
ving gone through all of this, I want to point out that the hu=
ge mission to bring quality to real-time traffic over our best effort =
Internet, is not a question of huge investments in new bandwidth (that =
happens anyway for data and streaming video needs) or about sharing =
bandwidth (bandwidth is available in access if we only consider the =
real-time need). It is about borrowing some already existing bandwidth =
from data usage. And there are only unnoticeable consequences of this =
borrowing; A delay of a fraction of a second or so for click-responses =
or watching a movie. So the huge mission, may be a an easy task if we do =
it cleverly.
 
 
An=
d finally, the purpose of this draft-thomson-tram-turn-bandwidth-00.txt =
seems is related to how to request or buy or limit or pay for access to =
the good real-time IP pipes for best =
QoE.
 
Is=
n’t that the case Alan, rather than intended to be used as QoS/QoE =
improvement method (as it has been =
discussed).
 
/K=
arl
 
 

 

Fr=E5n: tram = [mailto:tram-bounces@ietf.org] F=F6r Alan = Johnston
Skickat: den 17 februari 2014 21:14
Till: = tram@ietf.org
=C4mne:<= /b> = [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

All,

 

We have written a new I-D on a bandwidth attribute for = TURN.  The use case is to allow a TURN client to indicate to the = server the bandwidth it expects to use for the relayed candidate, or for = a TURN server to indicate to the client the maximum bandwidth before the = TURN server might apply rate limiting.

 

Note some of the text is = from draft-thomson-mmusic-rtcweb-bw-consent which was discussed in = the past, but this draft does not propose an ICE use case for = consent.

 

Comments most welcome!

 

- Alan -

---------- Forwarded message ----------
From: = <internet-drafts@ietf.org>=
Date: Thu, Feb 13, 2014 at 9:07 PM
Subject: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts = directories.


        Title     =       : A Bandwidth Attribute for TURN
    =     Authors         : Martin = Thomson
                =           Bernard Aboba
      =                     = Alan Johnston
                =           Oleg Moskalenko
    =     Filename        : = draft-thomson-tram-turn-bandwidth-00.txt
        = Pages           : 8
      =   Date            : = 2014-02-13

Abstract:
   An attribute is defined for = Session Traversal Utilities for NAT
   (STUN) that allows = for declarations of bandwidth limits on the
   negotiated = flow.  The application of this attribute is the
  =  negotiation of bandwidth between a Traversal Using Relays around = NAT
   (TURN) client and a TURN server.


The IETF = datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-thomson-tram-tur= n-bandwidth/

There's also a htmlized version available = at:
http://tools.ietf.org/html/draft-thomson-tram-turn-band= width-00


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/

________= _______________________________________
I-D-Announce mailing = list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
I= nternet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 

------=_NextPart_000_01B0_01CF2E49.24E32530-- From nobody Thu Feb 20 05:40:44 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C1B1A0162 for ; Thu, 20 Feb 2014 05:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MSGID_MULTIPLE_AT=1] autolearn=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 1pdEu4cvBkxT for ; Thu, 20 Feb 2014 05:40:41 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id C4D4B1A016C for ; Thu, 20 Feb 2014 05:40:40 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402201440358237; Thu, 20 Feb 2014 14:40:35 +0100 From: "Karl Stahl" To: "'Pal Martinsen \(palmarti\)'" , , "'Tirumaleswar Reddy \(tireddy\)'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> <6BAD559F-A526-4215-A566-9A21632AED08@cisco.com> In-Reply-To: <6BAD559F-A526-4215-A566-9A21632AED08@cisco.com> Date: Thu, 20 Feb 2014 14:40:33 +0100 Message-ID: <01c901cf2e41$545b1140$fd1133c0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPLVepL0ox0vNFkUCS65m4/NS1C5q8XDsw Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/hGA-C-ZboZj9TXb1iVscwhjfuPI Cc: 'Simon Perreault' Subject: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 13:40:43 -0000 Hi Pal, Thank you for the go through below - I think that was very = relevant/necessary and I have put some further thoughts inline, that = spans even further. In the email before this one, I asked Alan to elaborate on how this = draft-thomson-tram-turn-bandwidth-00.txt relates to the QoS/QoE issues = discussed here in TRAM. I actually think its purpose is to "convey = polices" rather that traffic information for use by functions that can = implement QoS/QoE remedies.=20 In there I also "happened to describe" the main QoS/QoE issues and = remedies (and how they work) in as short, simple and understandable way = I am able to, and hope that may be beneficial for everyone to understand = the underlying things of what is proposed and discussed here. In case the discussion continuous on this thread, I also repeat the = necessity to complete the QoS/QoE mission of TRAM and the A) B) C) D) = steps I see in the standardization work to reach the goal. Maybe this = can discussed in London? Let me also point out draft-deng-tram-isp-turn-00=20 http://www.ietf.org/mail-archive/web/tram/current/msg00214.html from = China Mobile that appeared on this mailing list yesterday. It points out = the need and willingness from the ISP/NSP side to do something about QoS = for WebRTC traffic, that they expect to be large and have to bring to = their customers with best QoE. In fact they and some more (a huge = European carrier and the cable operators in general - CableLabs) have = expressed similar concerns to me =E2=80=9CThis is exactly something we = want to work on as the current way will cause severe problem on traffic = when rtcweb applications get popular=E2=80=9D is a direct quote from one = of those. So, in answer to Simon Perreault [simon.perreault@viagenie.ca]=E2=80=99s = question in another thread the 13th: a) Is this a real problem that is worth fixing? I think we can be confident that the answer is *YES*. Only these three = ISP/NSP referred to, may represent 50%(?) of the universe=E2=80=99s IP = accesses! And the other will follow these most forward looking carriers. = Even if the mission to bring quality to real-time traffic over our best = effort Internet is a huge mission, I am convinced it not a huge task = =E2=80=93 We just be a bit clever here :). I only see these few standard = steps required, before it can happen! A) Auto-discovered TURN servers=20 =20 B) Enforcing the real-time traffic through the offered/discovered TURN = servers=20 (Discussed below: Detecting a flow is not enough =E2=80=93 we need to = enforce =E2=80=93 more input below.)=20 C) Providing real-time traffic information from the application/browser = to the network element that has the flow and can apply QoS measures = (that would be =E2=80=9Cthe box containing the TURN server=E2=80=9D**)=20 (DISCUSS- or draft-thomson-tram-turn-bandwidth-00.txt-like methods are = being discussed, but they do not do it all e.g. provide info of incoming = traffic and varying bandwidth requirements of smart codecs.) D) Adding real-time traffic information to the media packets themselves, = to fix QoS where the above is not sufficient. This can both fix the lack = of type and bandwidth info of incoming traffic (even varying) at the = TURN points and also be of a great help across network = boundaries/peering points, where DSCP-bits are changed and when going = into reservation type of networks (cable and mobile) since DSCP-bits = gives no clue of what bandwidth needs to be reserved.=20 Here I see the recreation of the idea/intention of the RTP payload type = (PT) header as the obvious (and only?) solution. (That payload type info = is no longer available though, since we use dynamic payload types and = the SDP where it says what it is all about, nowadays cannot be said to = be available to the network (usually encrypted and somewhere else than = the media flow). There is a trivial way of doing this although it has = been =E2=80=9Cconsidered impossible=E2=80=9D, see = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html .=20 It is simply to add the bandwidth requirement and traffic type into two = parameters in the RTP header extension (which is visible in also in SRTP = =E2=80=93 it is outside the encrypted payload - and the network can read = it). That information should also stay with the traffic (and not be = changed around like DSCP bits). The application/browser will also be = able to change this info during a call, e.g. to announce higher or lower = bandwidth requirements of varying bandwidth type of codecs or from = application measures taken by QoS feedback via RTCP. Further, these RTP = extension header bits are easily set by any browser using any operating = system (which is not the case with DSCP-bits). This =E2=80=9Ctrivial=E2=80=9D thing is needed for the =E2=80=9Chuge = mission=E2=80=9D of =E2=80=9Cbringing quality to real-time traffic over = the best effort Internet=E2=80=9D. A framework is even done in=20 http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 .=20 *Time to get it done!* Don't forget the inline comments below --> /Karl Footnote **[Karl]* For similar reasons I have started to say things like = =E2=80=9Cthe box containing the TURN server=E2=80=9D. We should not = change the TURN server spec into including specific QoS methods to apply = (like reservation, changing DSCP bits or applying traffic shaping = mechanism). What is happening here is that we share the traffic = information that the TURN server gets hold of, with a QoS applying = function (that will be different for different networks) in =E2=80=9Cthe = same box=E2=80=9D. With =E2=80=9Cthe same box=E2=80=9D I mean that we = for now don=E2=80=99t care about the interface/commands for sharing = information between the TURN server and the QoS applying function. There = may be a future need to specify/standardize this, but if we start doing = that now and in TRAM, we risk ending up in a 10-year process before = having something in place (which without a spec automatically will = happen in vendor=E2=80=99s product development, by putting the TURN = server into already available =E2=80=9CQoS applying function=E2=80=9D = boxes (like firewalls or the mobile DPI/PCRF combination). *What we need to consider and specify, is only what traffic info is = required (to be provided by the application/browser) for =E2=80=9CQoS = applying functions=E2=80=9D in different networks (including the very = common reservation types) to do job (i.e. giving us good QoE for = real-time applications).* -----Ursprungligt meddelande----- Fr=C3=A5n: tram [mailto:tram-bounces@ietf.org] F=C3=B6r Pal Martinsen = (palmarti) Skickat: den 19 februari 2014 10:48 Till: tram@ietf.org Kopia: Muthu Arul Mozhi Perumal (mperumal); Oleg Moskalenko; Simon = Perreault =C3=84mne: Re: [tram] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt Hi, I like the idea of a bandwidth attribute telling the TURN server what to = expect from that particular allocation. Especially when it comes to = allocations that carry for example RTCP, BFCP and other =E2=80=9Clow = chatter=E2=80=9D data protocols. When it comes to more = =E2=80=9Celastic=E2=80=9D media protocols (video especially) a static = bandwidth attribute can be a bit problematic. This is somewhat described = in the draft that burst above the maximum should be expected. But due to = very good video encoding efficiency in for example a talking head only = scenario, the bandwidth usage may be significantly lower than the = maximum bandwidth the agent signalled in the allocation message.=20 So how is this bandwidth attribute useful for the TURN server when = signalled from the allocating agent? What can it do when the bandwidth = is exceeded, and when does it know that the bandwidth is exceeded? There = might be different network paths to the TURN server. One path may be = congested well before any TURN bandwidth is exceeded.=20 I am trying to argue that the possible choke point in the network is not = necessarily where the TURN server is placed, and that reduces the = usefulness of a bandwidth attribute in some scenarios. When it comes to = draft-thomson-tram-turn-bandwidth we must be careful to explain what = problems it solves. I am afraid that this attribute might be (miss?)used = as a QoS solution on the entire media path. [Karl] You hit the point here that concerned me when trying to catch up = on the discussions. I asked Alan to clarify in the previous email. One possible use case for this draft to solve is to get better pr = session/call/?? bandwidth utilisation. If for example a user pays to = get 3Mbit through the TURN server. The users endpoint is capable of = sending 1 audio and 3 video (Head, room and slides) streams and one BFCP = stream. The agent needs to do 9 allocations (4xRTP, 4xRTCP, 1xBFCP), 5 = of those allocations are very low bandwidth. The agent itself knows best = how to utilise the remaining bandwidth, but how should we cope with = changing needs. How do we signal; I know that I have 3Mbit available, = and I am dynamically going to use that bandwidth over those 4 = allocations, and by the way I have 5 more allocations that only needs a = packet sent now and then.. (And yes I know of BUNDLE, but the media = streams may not have the same src/dst IP) Separate from QoS/QoE means we need to get in place.=20 [Karl] Same. You hit the point here that concerned me when trying to = catch up on the discussions. I asked Alan to clarify in the previous = email. I don't think the draft-thomson-tram-turn-bandwidth-00.txt is = meant cope with this. When it comes to DSCP and ECN, as Simon point out putting them in a STUN = attribute would help getting the values transported unmangled over the = Internet.=20 [Karl] When you say "putting them in a STUN attribute" do you also = include the TURN allocate request (since TURN is an extension of STUN = and I believe the attributes you can use are exactly the same - correct = me if I am wrong!)? (You have already confirmed this is possible = elsewhere - I just want to bring in that usage here) It is TURN we to = control where the flow goes, so this it is highly important that we can = get the application's knowledge to the TURN-server having the traffic = flow, and hopefully "in the same box"** having QoS functions to = help/assure/control that we can the best QoE. This is especially important in this scenario as a NAT sitting between = the agent and the TURN server might ignore those bits when forwarding = the packets.=20 [Karl] Here you hit an important point again, stressing why it is good = to use TURN server attributes to transfer information about the traffic = to the point (the TURN-server box) where there are means to deal with = quality things. [Karl] Another way of doing this to mark each RTP packet with relevant = information (which I saw necessary for the more difficult to solve how = have knowledge of *incoming* real-time traffic, when DSCP usually are = lost over the Internet). But it of course could be useful here also. [Karl] The marking is RTP packet with relevant information for network = elements to use, is recreating the payload type (PT) marking idea/intent = of RTP packets (by now conveying bandwidth and traffic type in the RTP = extension header = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html (Step = D above) The remaining problem with DSCP is that there is no strict defining of = what the bits actually means. Some definitions can be found in = draft-dhesikan-tsvwg-rtcweb-qos, but it is likely that different ISPs or = networks will use different values. As Muthu pointed out, this is = essentially the motivation for the draft-martinsen-tram-discuss draft. [Karl] Step D above, putting the bandwidth and traffic type in the RTP = extension header = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html will = greatly help/remedy this issue. Better than DSCP-bits are available and = unchanged in every RTP packet, and they are easily by the = application/browser without the concern that DSCP bits seldom can be = conveyed through our OSs. /Karl .-. P=C3=A5l-Erik _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram From nobody Thu Feb 20 06:26:33 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A421A018C for ; Thu, 20 Feb 2014 06:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 C5gg1ulvUozJ for ; Thu, 20 Feb 2014 06:26:24 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6CE1A019D for ; Thu, 20 Feb 2014 06:26:23 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id a1so1476174wgh.34 for ; Thu, 20 Feb 2014 06:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AvSvyk6J4M1aXRfPrEOeY2Yp6aUAKBNNaLERV7wyWOY=; b=RUuSMF8V0KPjtjBCJpoenXZ4THnVorO5V27VszXQYTZvJ1R01ku2SrR1Upp08+S1uz iKmsqghIr08ABy60u2dxbABFiX3aD+AbY0dQGLFtwA3OALbVIoLGpXKWt1nOYhSGM6QA 6RsX61Z7rhI6K1ducP9+jQ1cp3uwmWwIDTlKMqkFh0ANc+reAToff6XLLtP6coryER2h T3iCCFaio0LuIccgs7wkQo7ZNOMWpnLUHdXjEiW89RAkJXm9AkCcvRFMUurejzGi0nod pJOhlr8KHzOtObA9GFkn0Rsttm3ECcQBQWCrf/w7EUl+AhdNumcBx07IcdDqRic5VgV2 Rgyg== MIME-Version: 1.0 X-Received: by 10.194.185.165 with SMTP id fd5mr2183420wjc.95.1392906378505; Thu, 20 Feb 2014 06:26:18 -0800 (PST) Received: by 10.217.152.10 with HTTP; Thu, 20 Feb 2014 06:26:18 -0800 (PST) In-Reply-To: <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> Date: Thu, 20 Feb 2014 08:26:18 -0600 Message-ID: From: Alan Johnston To: Karl Stahl Content-Type: multipart/alternative; boundary=047d7bdc7e2ae5727304f2d749e3 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/qpZuPBFwtauqhGEhYu_e16ThJ34 Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 14:26:31 -0000 --047d7bdc7e2ae5727304f2d749e3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Karl, Thanks for your comments and feedback on the draft. You are correct in saying that the BANDWIDTH extension is not about QoS. It is about fairness between users of a TURN server, and a TURN server being able to indicate rate limiting policy to users. Personally, I am not sure how much QoS is actually in scope for TRAM. Have you been following RMCAT where congestion avoidance for RTP is being developed? I see some overlap in your goals and the goals of that work. - Alan - On Thu, Feb 20, 2014 at 7:36 AM, Karl Stahl wrote: > Hi Alan, > > > > Can you comment/elaborate on the purpose and intended usage of this > draft-thomson-tram-turn-bandwidth-00.txt? > > > > I am not clear about how the negotiation of bandwidth between a TURN clie= nt and a TURN server can be useful considering how bandwidth is shared on t= he Internet today and the QoS/QoE implications of this. > > > > On this mailing list, this draft has been discussed as useful for QoS/QoE= improvement, which I cannot see it is. For such purposes, richer informati= on than the total bandwidth needs to be conveyed to the TURN server / netwo= rk, compare e.g. DISCUSS/MALICE http://tools.ietf.org/html/draft-martinsen-= tram-discuss-00. > > > > In the Introduction of draft-thomson-tram-turn-bandwidth-00.txt: > > The operator of a TURN server will likely wish to provide fairness > > between relayed sessions. A TURN server might also wish to limit the > > use of service to audio-only sessions, or low bandwidth video and > > audio sessions. In addition, the server may apply rate-limiting > > policy depending on the credential used for authentication, or the > > origin of the client. Without the BANDWIDTH attribute, there is no > > way for a client to indicate the expected bandwidth utilization, or > > for the server to indicate the maximum bandwidth utilization allowed > > before rate limiting could be applied. > > > > I interpret that this draft is about conveying a "fairness policy" etc. t= o the TURN server / network, without specifying how this could be realized = or implemented. Correct? More is needed for a possible the realization cons= idering QoS/QoE. > > > > If richer information is needed for the realization, that may be the attr= ibutes conveyed by DISCUSS/MALICE (but used for TURN, not STUN, see discuss= ion in previous email). > > > > On the other hand, if the information conveyed here (draft-thomson-tram-t= urn-bandwidth-00.txt) already is available (directly or indirectly) in the = DISCUSS attributes, maybe we could end up with a single draft that includes= the real-time traffic information and sharing policy that needs to be conv= eyed to the TURN server / network? Is that something to consider? > > > > Or if recreating the payload type (PT) idea/intent in RTP packets (by now= conveying bandwidth and traffic type in the RTP extension header http://ww= w.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is sufficient for = QoS/QoE in combination with auto-discussed TURN servers, maybe draft-thomso= n-tram-turn-bandwidth-00.txt is the only thing we need in addition (not the= DISCUSS attributes). > > > > > > For better understanding of these QoS/QoE problems, and methods for impro= ving (not specifically discussing the policies of sharing real-time traffic= space), I would like to explain: > > > > Over an IP pipe only used for real-traffic (no TCP data traffic), it is s= ufficient that the pipe is wide enough for good QoS. That is often used and= implemented by separating IP pipes at a lower level using e.g. Ethernet VL= AN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can enforc= e real-traffic into such pipes and QoS is achieved. Let's call this Level 2= QoS (Network level) > > > > Over an IP pipe shared between quality requiring real-time traffic and le= ss demanding data or streaming (usually TCP) traffic, we have the sharing b= etween these two traffic classes to consider. The main method (and the mech= anism making today's real-time QoE as good as it often is) is that TCP endp= oints back-off and share their bandwidth usage. Real-time traffic using UDP= transport do not back-off, the endpoints using UDP occupy the bandwidth ne= eded. When an IP pipe gets filled, it is all endpoint's TCP bandwidth usage= that is back-off and shared between them, leaving room for the UDP traffic= . This is mechanism we experience everyday over the Internet, using our "Su= rf IP pipes". Let's call this Level 4 QoS (Transport level) > > > > However, this Level 4 QoS is based on that at congestion times (which hap= pen every time we click - setting up a TCP flow and transferring some amoun= t of data as quick as possible) the router handling the most narrow part of= the pipe (the congestion point) drop packets. It is this packet dropping t= hat (i) signals to TCP endpoints to reduce their bandwidth (via TCP's error= correction/retransmission mechanism) and (ii) destroys the QoE of real-tim= e traffic. (Both TCP and UDP packets are dropped in this process that is tr= iggered by flow intensive TCP traffic.) > > > > We need (i) but don't want (ii) and to improve on this we can e.g. use di= ffserve, DSCP bits in IP packets to instruct routers to always forward the = real-time traffic before any unmarked TCP traffic (which usually fills most= of the pipe). Then QoS is then achieved for real-time traffic. This is Lev= el 3 QoS (IP level). The method used is "traffic shaping": backing off data= traffic, leaving real-time traffic free passage without packet loss. > > > > Here, in TRAM we want to go beyond Level 4 QoS (already available and wor= king as good as it can on the Internet), to give quality demanding WebRTC r= eal-time traffic better QoE by: > > a. Forcing real-time traffic into IP-pipes having Level 2 QoS (using auto= -discovered TURN servers) > > or > > b. Forcing real-time traffic into IP-pipes having Level 3 QoS (using > auto-discovered TURN servers). Here we must have traffic shaping mechanis= ms > working, and with correct and sufficient information to do the job. This = is > why we in TRAM discuss DISCUSS/MALICE, > draft-thomson-tram-turn-bandwidth-00.txt attributes and recreating the > payload type (PT) idea/intent in RTP packets (by now conveying bandwidth > and traffic type in the RTP extension header > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html. > > > > How these QoS/QoE things are done and used in practice is also illustrate= d/exemplified in this email discussion: > > http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html > > > > Prioritization of individual real-time packets (e.g. using diffserve DSCP= bits) have today little impact on the QoE, UNLESS a pipe full with only re= al-time traffic (which is unusual), because in today's IP pipes with high b= andwidth, packets are not stored for later delivery, but rather dropped by = routers implementing diffserve (after only a short time period =3D small bu= ffer size). The only good remedy is higher bandwidth, that can handle ALL r= eal-time traffic. > > > > Prioritization of real-time packets (any diffserve DSCP bits marking) "ma= kes QoS perfect", when there are best effort (=3Dno DSCP bits set) TCP (=3D= non real-time) traffic going over the IP pipe that can be pushed off. Route= rs implementing diffserve do that. > > > > > > Having gone through all of this, I want to point out that the huge missio= n to bring quality to real-time traffic over our best effort Internet, is n= ot a question of huge investments in new bandwidth (that happens anyway for= data and streaming video needs) or about sharing bandwidth (bandwidth is a= vailable in access if we only consider the real-time need). It is about bor= rowing some already existing bandwidth from data usage. And there are only = unnoticeable consequences of this borrowing; A delay of a fraction of a sec= ond or so for click-responses or watching a movie. So the huge mission, may= be a an easy task if we do it cleverly. > > > > > > And finally, the purpose of this draft-thomson-tram-turn-bandwidth-00.txt= seems is related to how to request or buy or limit or pay for access to th= e good real-time IP pipes for best QoE. > > > > Isn't that the case Alan, rather than intended to be used as QoS/QoE impr= ovement method (as it has been discussed). > > > > /Karl > > > > > > > > *Fr=E5n:* tram [mailto:tram-bounces@ietf.org] *F=F6r *Alan Johnston > *Skickat:* den 17 februari 2014 21:14 > *Till:* tram@ietf.org > *=C4**mne:* [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.= txt > > > > All, > > > > We have written a new I-D on a bandwidth attribute for TURN. The use cas= e > is to allow a TURN client to indicate to the server the bandwidth it > expects to use for the relayed candidate, or for a TURN server to indicat= e > to the client the maximum bandwidth before the TURN server might apply ra= te > limiting. > > > > Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent whic= h > was discussed in the past, but this draft does not propose an ICE use cas= e > for consent. > > > > Comments most welcome! > > > > - Alan - > > ---------- Forwarded message ---------- > From: > Date: Thu, Feb 13, 2014 at 9:07 PM > Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : A Bandwidth Attribute for TURN > Authors : Martin Thomson > Bernard Aboba > Alan Johnston > Oleg Moskalenko > Filename : draft-thomson-tram-turn-bandwidth-00.txt > Pages : 8 > Date : 2014-02-13 > > Abstract: > An attribute is defined for Session Traversal Utilities for NAT > (STUN) that allows for declarations of bandwidth limits on the > negotiated flow. The application of this attribute is the > negotiation of bandwidth between a Traversal Using Relays around NAT > (TURN) client and a TURN server. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwidth/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00 > > > 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/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7bdc7e2ae5727304f2d749e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Karl,

Thanks for your comments and= feedback on the draft.

You are correct in saying that the BANDWIDTH extension is not about QoS. &n= bsp;It is about fairness between users of a TURN server, and a TURN server = being able to indicate rate limiting policy to users.

Personally, I am not sure how much QoS= is actually in scope for TRAM. Have you been following RMCAT where congest= ion avoidance for RTP is being developed?  I see some overlap in your = goals and the goals of that work.

- Alan -
On Thu, Feb 20, 2014 at 7:36 AM, Karl Stahl= <karl.stahl@intertex.se> wrote:

Hi Alan,

 

Can you commen= t/elaborate on the purpose and intended usage of this draft-thomson-tram-tu= rn-bandwidth-00.txt?

 

I am not clear ab=
out how the negotiation of bandwid=
th between a TURN client and a TURN server can be useful considering how ba=
ndwidth is shared on the Internet today and the QoS/QoE implications of thi=
s.
 
On this mailing list, this draft has be= en discussed as useful for QoS/QoE improvement, which I cannot see it is. F= or such purposes, richer information than the total bandwidth needs to be c= onveyed to the TURN server / network, compare e.g. DISCUSS/MALICE http://tools.ietf.org/html/draft-martinsen-tram-discuss-00. 
 
In the Introduction of draft-thomson-tr= am-turn-bandwidth-00.txt: 
   The operator of a TURN server will like=
ly wish to provide fairness
   between relayed sessions.  A TURN server might also wis=
h to limit the
   use of service to audio-only sessions, =
or low bandwidth video and
   audio sessions.  In addition, the server may apply rate-=
limiting
   policy depending on the credential used=
 for authentication, or the
   origin of the client.  Without the BANDWIDTH attribute,=
 there is no
   way for a client to indicate the expect=
ed bandwidth utilization, or
   for the server to indicate the maximum bandwidth utilizatio=
n allowed
   before rate limiting could be applied.<=
/span>
 
I interpret that this draft is ab=
out conveying a “fairness policy” etc. to the TURN server / network, without specifying how this =
could be realized or implemented. Correct? More is needed for a possible th=
e realization considering QoS/QoE.
 
If richer information is needed for the= realization, that may be the attributes conveyed by DISCUSS/MALICE (but us= ed for TURN, not STUN, see discussion in previous email). 
 
On the other hand, if the informatio= n conveyed here (draft-thomson-tram-turn-bandwidth-00.txt) already is avail= able (directly or indirectly) in the DISCUSS attributes, maybe we could end= up with a single draft that includes the real-time traffic information and= sharing policy that needs to be conveyed to the TURN server / network? Is = that something to consider? 
 
= 
Or if recreating the payload type (PT) idea/intent in RTP packets (=
by now conveying bandwidth and traffic type in the RTP extension header http://www.ietf.org/mail-archive/web/rtcweb/current/msg09=
129.html is sufficient for QoS/QoE in combination with auto-disc=
ussed TURN servers, maybe draft-thomson-tram-turn-bandwidth-00.txt is the o=
nly thing we need in addition (not the DISCUSS attributes).
 
= 
 
For better understanding of these=
 QoS/QoE problems, and methods for improving (not specifically discussing t=
he policies of sharing real-time traffic space), I would like to explain:
 
= 
Over an IP pipe only used for rea=
l-traffic (no TCP data traffic), it is sufficient that the pipe is wide eno=
ugh for good QoS. That is often used and implemented by separating IP pipes=
 at a lower level using e.g. Ethernet VLAN, MPLS, Ethernet over ATM (std fo=
r ADSL modems). TURN servers can  enforce real-traffic into such pipes=
 and QoS is achieved. Let’s call this Level 2 QoS (Network level)<=
/u>
 
= 
Over an IP pipe shared between qu=
ality requiring real-time traffic and less demanding data or streaming (usu=
ally TCP) traffic, we have the sharing between these two traffic classes to=
 consider. The main method (and the mechanism making today’s real-tim=
e QoE as good as it often is) is that TCP endpoints back-off and share thei=
r bandwidth usage. Real-time traffic using UDP transport do not back-off, t=
he endpoints using UDP occupy the bandwidth needed. When an IP pipe gets fi=
lled, it is all endpoint’s TCP bandwidth usage that is back-off and s=
hared between them, leaving room for the UDP traffic. This is mechanism we =
experience everyday over the Internet, using our “Surf IP pipes&rdquo=
;. Let’s call this Level 4 QoS (Transport level)=

 
= 
However, this Level 4 QoS is base=
d on that at congestion times (which happen every time we click – set=
ting up a TCP flow and transferring some amount of data as quick as possibl=
e) the router handling the most narrow part of the pipe (the congestion poi=
nt) drop packets. It is this packet dropping that (i) signals to TCP endpoi=
nts to reduce their bandwidth (via TCP’s error correction/retransmiss=
ion mechanism) and (ii) destroys the QoE of real-time traffic. (Both TCP an=
d UDP packets are dropped in this process that is triggered by flow intensi=
ve TCP traffic.)
 
= 
We need (i) but don’t want =
(ii) and to improve on this we can e.g. use diffserve, DSCP bits in IP pack=
ets to instruct routers to always forward the real-time traffic before any =
unmarked TCP traffic (which usually fills most of the pipe). Then QoS is th=
en achieved for real-time traffic. This is Level 3 QoS (IP level). The meth=
od used is “traffic shaping”: backing off data traffic, leaving=
 real-time traffic free passage without packet loss.

 
=

Here, in TRAM we want to go beyon=
d Level 4 QoS (already available and working as good as it can on the Inter=
net), to give quality demanding WebRTC real-time traffic better QoE by:<=
/u>


a. Forcing real-time traffic into=
 IP-pipes having Level 2 QoS (using auto-discovered TURN servers) 


or
b. Forcing real-tim=
e traffic into IP-pipes having Level 3 QoS (using auto-discovered TURN serv=
ers). Here we must have traffic shaping mechanisms working, and with correc=
t and sufficient information to do the job. This is why we in TRAM discuss =
DISCUSS/MALICE, draft-thomson-tram=
-turn-bandwidth-00.txt attributes and recreating the payload type (PT) idea=
/intent in RTP packets (by now conveying bandwidth and traffic type in the =
RTP extension header http://www.ietf.org/mail-archive/w=
eb/rtcweb/current/msg09129.html.<=
/u>


 
=

How these QoS/QoE things are done=
 and used in practice is also illustrated/exemplified in this email discuss=
ion:


http://www.i=
etf.org/mail-archive/web/rtcweb/current/msg09031.html 


 
=

Prioritization of individual real=
-time packets (e.g. using diffserve DSCP bits) have today little impact on =
the QoE, UNLESS a pipe full with only real-time traffic (which is unusual),=
 because in today’s IP pipes with high bandwidth, packets are not sto=
red for later delivery, but rather dropped by routers implementing diffserv=
e (after only a short time period =3D small buffer size). The only good rem=
edy is higher bandwidth, that can handle ALL real-time traffic. <=
/u>


 
=

Prioritization of real-time packe=
ts (any diffserve DSCP bits marking) “makes QoS perfect”, when =
there are best effort (=3Dno DSCP bits set) TCP (=3Dnon real-time) traffic =
going over the IP pipe that can be pushed off. Routers implementing diffser=
ve do that.


 
=

  

Having gone through all of this, =
I want to point out that the hu=
ge mission to bring quality to real-time traffic over our best effort Inter=
net, is not a question of huge investments in new bandwidth (that happens a=
nyway for data and streaming video needs) or about sharing bandwidth (bandw=
idth is available in access if we only consider the real-time need). It is =
about borrowing some already existing bandwidth from data usage. And there =
are only unnoticeable consequences of this borrowing; A delay of a fraction=
 of a second or so for click-responses or watching a movie. So the huge mis=
sion, may be a an easy task if we do it cleverly.

 
=

 


And finally, the purpose of this =
draft-thomson-tram-turn-bandwidth-00.txt seems is related to how to request=
 or buy or limit or pay for access to the good real-time IP pipes for best =
QoE.


 
=

Isn’t that the case Alan, r=
ather than intended to be used as QoS/QoE improvement method (as it has bee=
n discussed).


 
=

/Karl


 
=

 


 


Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Alan Johnston<=
br>
Skickat: den 17 februari 2014 21:14
Till: tram@ietf.org
=C4mne: [tram] Fwd: I-D Action: draft-thom=
son-tram-turn-bandwidth-00.txt


 
All,
 
We have written a new I-D on a bandw=
idth attribute for TURN.  The use case is to allow a TURN client to in=
dicate to the server the bandwidth it expects to use for the relayed candid=
ate, or for a TURN server to indicate to the client the maximum bandwidth b=
efore the TURN server might apply rate limiting.


 
Note some of the text is from draft-thomson-mmusic-rt=
cweb-bw-consent which was discussed in the past, but this draft does not pr=
opose an ICE use case for consent.


 
Comments most welcome!
 

- Alan -
---------- Forwarded =
message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Feb 13, 2=
014 at 9:07 PM

Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
To: i-d-announce@ietf.org<=
/a>



A New Internet-Draft is available from the on-line Inter=
net-Drafts directories.



        Title          =
; : A Bandwidth Attribute for TURN
        Authors &=
nbsp;       : Martin Thomson
        =
                  Bernard Abob=
a
                    =
      Alan Johnston
          &n=
bsp;               Oleg Moskalenko

        Filename        : draft-tho=
mson-tram-turn-bandwidth-00.txt
        Pages  =
         : 8
        Date  =
          : 2014-02-13

Abstract:
  =
 An attribute is defined for Session Traversal Utilities for NAT

   (STUN) that allows for declarations of bandwidth limits on the=

   negotiated flow.  The application of this attribute i=
s the
   negotiation of bandwidth between a Traversal Using Re=
lays around NAT
   (TURN) client and a TURN server.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwi=
dth/


There's also a htmlized version available at:
http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00


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

Internet-=
Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/

_____________________________________=
__________
I-D-Announce mailing list
I-D-Announce@ietf.org

https://www.ietf.org/mailman/listinfo/i-d-announce
I=
nternet-Draft directories: http://www.ietf.org/shadow.html

or =
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 

______= _________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--047d7bdc7e2ae5727304f2d749e3-- From nobody Thu Feb 20 09:25:55 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13D31A0224 for ; Thu, 20 Feb 2014 09:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 oypPL36amF8f for ; Thu, 20 Feb 2014 09:25:52 -0800 (PST) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 70C5C1A0221 for ; Thu, 20 Feb 2014 09:25:51 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id oz11so2148218veb.15 for ; Thu, 20 Feb 2014 09:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=coBI9u7R8SxzkZu7Pp6l8i2i5A/QF9GPZOya3ylngTs=; b=Zon9E6laHSuK2FIdTezH1uubqI6MDVY1ernd9SoSr9I0tCoQNw9mMQdKxpWFRikj0a FzapjCuVwwC5kIWiPzGFI6sta21aoxPA+2dEZ7nbcfctaItKgTa5SKkLZmKw0Pf8z1Yu gJ+6miMU6eE1PXXvI4LvzpC94jRhZVk7XNuEc21UAaAVufEKnsI0c2GdtnhuHSwfQJmv 96d3qk+MeRhXd2g0CL6Fq0eVI/cy0221b3N+kEXjfQcvwKYq31ka7WI1nDV9LeBdGF1r Sbe+euxf+Wfjnt+2W0k1Itpbm5iiW3FcPPKZ4Ojfy8+53Dy3AiGe0z3jRNx+RzlzA46m SDAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=coBI9u7R8SxzkZu7Pp6l8i2i5A/QF9GPZOya3ylngTs=; b=VGWGXseHgOVb6U4Z2OFWqVM9cKQUqHneFe4DeLl578LZRhO1bWaZkgreDYXG8eSPvc xHpnTizwyj6YX9OF6v07DxZtNg+7eNDjUP8Zsldfma/PyAbhh/q4L895Tyl2xOW62KxK WriKHmO2Rhm5pwVw7LveE/gVA0rFCVLXWWNzcRhWHk8wl/qe/FCUn/WvqraL3TXj1mLw kT3WfP7tHQ1e/OYxccbj3cKCqOQdF/jHwEoavnbPzLEjDrf8OFfAGiZf2WTQEqoUaidc AbzqUF01uLJmnBKY4lclICUuPTGpiUIBPHKphxMjGLJFC4T8y9AxniRcFgsC2qhR0H7N FfCw== X-Gm-Message-State: ALoCoQmidSEYXMJ1vXhUmC7/BDG1pc7LwKG/CfuaV/PZ71ToWWnuU3FXiM0ZIomX2lkLMONxv9e6tC8Z1CAVS2rNuvEFdIovU/oSgYA9GGOY2ELUsMpEX7xgnIaSYKlF7WZKLWxr28BfRfCsPrUyGb+MIQxApVwUxzBeayYnNBem3Um4MgJA/OjUMZMIRQA5scCAzWG+GIt7 X-Received: by 10.221.73.73 with SMTP id yr9mr1697032vcb.76.1392917147528; Thu, 20 Feb 2014 09:25:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Thu, 20 Feb 2014 09:25:27 -0800 (PST) In-Reply-To: <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> From: Justin Uberti Date: Thu, 20 Feb 2014 09:25:27 -0800 Message-ID: To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=001a11365196c7c78304f2d9cb69 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/e83Fu0OoZaA3kh7reZPqw0OkeEw Cc: Simon Perreault , Oleg Moskalenko , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 17:25:54 -0000 --001a11365196c7c78304f2d9cb69 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 20, 2014 at 3:50 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > > On 20 Feb 2014, at 08:15 am, Oleg Moskalenko wrote: > [cut] > > > > > > So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may > expect that attribute... > > > I just noticed that as well. Funny.. > > > So, I reconsider my opinion: let's not use the address-family in the > REFRESH at all, and refresh all relay endpoints regardless of their > protocols. > > > Well it is nice to have in there as the refresh is also used to delete an > allocation. So if you after ICE is completed ends up only using the IPv6 > allocation you can delete the IPv4 allocation. This frees up resources on > the TURN server. > Yeah, that was my thinking as well. If RAF is absent, the refresh applies to all allocations. If the RAF is specified, the specific allocations are refreshed/deleted, or an error if the RAF doesn't match the existing allocations. --001a11365196c7c78304f2d9cb69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 20, 2014 at 3:50 AM, Pal Martinsen (palmarti) <palmar= ti@cisco.com> wrote:

On 20 Feb 2014, at 08:15 am, Oleg Moskalenko <mom040267@gmail.com> wrote:
[cut]
>
>
> So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may = expect that attribute...
>
I just noticed that as well. Funny..

> So, I reconsider my opinion: let's not use the address-family in t= he REFRESH at all, and refresh all relay endpoints regardless of their prot= ocols.
>
Well it is nice to have in there as the refresh is also used to delet= e an allocation. So if you after ICE is completed ends up only using the IP= v6 allocation you can delete the IPv4 allocation. This frees up resources o= n the TURN server.

Yeah, that was my thinking as well. If RAF= is absent, the refresh applies to all allocations. If the RAF is specified= , the specific allocations are refreshed/deleted, or an error if the RAF do= esn't match the existing allocations.
--001a11365196c7c78304f2d9cb69-- From nobody Thu Feb 20 09:30:58 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915C31A0209 for ; Thu, 20 Feb 2014 09:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 zxGxskEtMx7Z for ; Thu, 20 Feb 2014 09:30:53 -0800 (PST) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F3B971A0227 for ; Thu, 20 Feb 2014 09:30:51 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so2190882vcb.3 for ; Thu, 20 Feb 2014 09:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=01bEgWTIBn2xnWPiac8ZMwedUYkCx7CHKu/UOzkiiaI=; b=AEkIqDePI/SAW85amnI+EsHDLAGT9Dd462l0ZlrgpZgOAg+ZY9W0B2IOfTkCzP8fdM w94ObugIn0J4pFURyasV2WEij5KfwMUoyLc8J0g5V+vTC/bx1guLvqgr5hiR/OtoCTtd iVAo8dLRJl+/pjXK8PvHP7rBjlf/JrfbqcQG/9tBZvw/5EZcjSrUF5aR5/WROD7byK8o esz1CJq1Wvj9n4GdWcJmOCdCuoe7xmDRkNpbzKlOUQ+x9Kfk42x0bQi/R10tcKGzJCYH c/dt2i3o/r/OmffPzHPMr0eAqZk2NTfF+bLK1wCN90O7wCzUB6ycMLyEPDfeCBhNT7K3 OmAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=01bEgWTIBn2xnWPiac8ZMwedUYkCx7CHKu/UOzkiiaI=; b=BNO2bHrNo6GDvwwY0EFHq+L4a9GVNoW+k+1raMNMdhJOrJLD8SRFFN0DjMMoAb+m23 6Ej1sXD0eM+sHnc35JS2Ns75pJ05PFMGIJVS88CekACrHBcygGvlNqtZ1IarJx0wM6Jl tdzFXjBR+NdmqEhL/6DtRmOhCpdgWibJuT6jFOOJNML1uShVuWsad4TWbG5TeLTmpV1l bbe6LMqndUCvsdgjBN0S3u2uhSRcVUMPNMxBS9IT7kKZIPMSElVmiXnVhVZlsM5jCV71 9D+kv/ub0jVxbw8tOnF6PRDauKXdgjhmRIKzsBis88zpFtcJOEZWbCOX1X6SnGhq3DmS a9pg== X-Gm-Message-State: ALoCoQlitZGZo1593YfM7g4u8pHaDgHFPK48SCfH79DIObeYZSdg0PH8GJfTitneq4+ODuxFPiv24sc73GvdojVZhGyshC0eo1sWdoQcTgvw229xk2yCPnTITTIlktBB9A6fsqt+zi1lmtqphmK2pVjK0K5NeuNJ9gfhej97k6EKtbWalsNNTeogRzmJfJ8y7asgbv7cIl0/ X-Received: by 10.220.50.18 with SMTP id x18mr1709235vcf.66.1392917447886; Thu, 20 Feb 2014 09:30:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Thu, 20 Feb 2014 09:30:27 -0800 (PST) In-Reply-To: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> From: Justin Uberti Date: Thu, 20 Feb 2014 09:30:27 -0800 Message-ID: To: Alan Johnston Content-Type: multipart/alternative; boundary=047d7b34427aaeee9a04f2d9ddbe Archived-At: http://mailarchive.ietf.org/arch/msg/tram/M2u0aVD25N6C1V2NLha6jJpa2sQ Cc: Karl Stahl , "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 17:30:56 -0000 --047d7b34427aaeee9a04f2d9ddbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable QoS does not even appear in the TRAM charter: https://datatracker.ietf.org/doc/charter-ietf-tram/ While some of the pieces we are building may be useful for QoS, it is not an explicit goal of this WG, and I would prefer to focus on the concrete milestones that have already been identified. On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston w= rote: > Hi Karl, > > Thanks for your comments and feedback on the draft. > > You are correct in saying that the BANDWIDTH extension is not about QoS. > It is about fairness between users of a TURN server, and a TURN server > being able to indicate rate limiting policy to users. > > Personally, I am not sure how much QoS is actually in scope for TRAM. Hav= e > you been following RMCAT where congestion avoidance for RTP is being > developed? I see some overlap in your goals and the goals of that work. > > - Alan - > > On Thu, Feb 20, 2014 at 7:36 AM, Karl Stahl wrote= : > >> Hi Alan, >> >> >> >> Can you comment/elaborate on the purpose and intended usage of this >> draft-thomson-tram-turn-bandwidth-00.txt? >> >> >> >> I am not clear about how the negotiation of bandwidth between a TURN cli= ent and a TURN server can be useful considering how bandwidth is shared on = the Internet today and the QoS/QoE implications of this. >> >> >> >> On this mailing list, this draft has been discussed as useful for QoS/Qo= E improvement, which I cannot see it is. For such purposes, richer informat= ion than the total bandwidth needs to be conveyed to the TURN server / netw= ork, compare e.g. DISCUSS/MALICE http://tools.ietf.org/html/draft-martinsen= -tram-discuss-00. >> >> >> >> In the Introduction of draft-thomson-tram-turn-bandwidth-00.txt: >> >> The operator of a TURN server will likely wish to provide fairness >> >> between relayed sessions. A TURN server might also wish to limit the >> >> use of service to audio-only sessions, or low bandwidth video and >> >> audio sessions. In addition, the server may apply rate-limiting >> >> policy depending on the credential used for authentication, or the >> >> origin of the client. Without the BANDWIDTH attribute, there is no >> >> way for a client to indicate the expected bandwidth utilization, or >> >> for the server to indicate the maximum bandwidth utilization allowed >> >> before rate limiting could be applied. >> >> >> >> I interpret that this draft is about conveying a =E2=80=9Cfairness polic= y=E2=80=9D etc. to the TURN server / network, without specifying how this c= ould be realized or implemented. Correct? More is needed for a possible the= realization considering QoS/QoE. >> >> >> >> If richer information is needed for the realization, that may be the att= ributes conveyed by DISCUSS/MALICE (but used for TURN, not STUN, see discus= sion in previous email). >> >> >> >> On the other hand, if the information conveyed here (draft-thomson-tram-= turn-bandwidth-00.txt) already is available (directly or indirectly) in the= DISCUSS attributes, maybe we could end up with a single draft that include= s the real-time traffic information and sharing policy that needs to be con= veyed to the TURN server / network? Is that something to consider? >> >> >> >> Or if recreating the payload type (PT) idea/intent in RTP packets (by no= w conveying bandwidth and traffic type in the RTP extension header http://w= ww.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is sufficient for= QoS/QoE in combination with auto-discussed TURN servers, maybe draft-thoms= on-tram-turn-bandwidth-00.txt is the only thing we need in addition (not th= e DISCUSS attributes). >> >> >> >> >> >> For better understanding of these QoS/QoE problems, and methods for impr= oving (not specifically discussing the policies of sharing real-time traffi= c space), I would like to explain: >> >> >> >> Over an IP pipe only used for real-traffic (no TCP data traffic), it is = sufficient that the pipe is wide enough for good QoS. That is often used an= d implemented by separating IP pipes at a lower level using e.g. Ethernet V= LAN, MPLS, Ethernet over ATM (std for ADSL modems). TURN servers can enfor= ce real-traffic into such pipes and QoS is achieved. Let=E2=80=99s call thi= s Level 2 QoS (Network level) >> >> >> >> Over an IP pipe shared between quality requiring real-time traffic and l= ess demanding data or streaming (usually TCP) traffic, we have the sharing = between these two traffic classes to consider. The main method (and the mec= hanism making today=E2=80=99s real-time QoE as good as it often is) is that= TCP endpoints back-off and share their bandwidth usage. Real-time traffic = using UDP transport do not back-off, the endpoints using UDP occupy the ban= dwidth needed. When an IP pipe gets filled, it is all endpoint=E2=80=99s TC= P bandwidth usage that is back-off and shared between them, leaving room fo= r the UDP traffic. This is mechanism we experience everyday over the Intern= et, using our =E2=80=9CSurf IP pipes=E2=80=9D. Let=E2=80=99s call this Leve= l 4 QoS (Transport level) >> >> >> >> However, this Level 4 QoS is based on that at congestion times (which ha= ppen every time we click =E2=80=93 setting up a TCP flow and transferring s= ome amount of data as quick as possible) the router handling the most narro= w part of the pipe (the congestion point) drop packets. It is this packet d= ropping that (i) signals to TCP endpoints to reduce their bandwidth (via TC= P=E2=80=99s error correction/retransmission mechanism) and (ii) destroys th= e QoE of real-time traffic. (Both TCP and UDP packets are dropped in this p= rocess that is triggered by flow intensive TCP traffic.) >> >> >> >> We need (i) but don=E2=80=99t want (ii) and to improve on this we can e.= g. use diffserve, DSCP bits in IP packets to instruct routers to always for= ward the real-time traffic before any unmarked TCP traffic (which usually f= ills most of the pipe). Then QoS is then achieved for real-time traffic. Th= is is Level 3 QoS (IP level). The method used is =E2=80=9Ctraffic shaping= =E2=80=9D: backing off data traffic, leaving real-time traffic free passage= without packet loss. >> >> >> >> Here, in TRAM we want to go beyond Level 4 QoS (already available and wo= rking as good as it can on the Internet), to give quality demanding WebRTC = real-time traffic better QoE by: >> >> a. Forcing real-time traffic into IP-pipes having Level 2 QoS (using aut= o-discovered TURN servers) >> >> or >> >> b. Forcing real-time traffic into IP-pipes having Level 3 QoS (using >> auto-discovered TURN servers). Here we must have traffic shaping mechani= sms >> working, and with correct and sufficient information to do the job. This= is >> why we in TRAM discuss DISCUSS/MALICE, >> draft-thomson-tram-turn-bandwidth-00.txt attributes and recreating the >> payload type (PT) idea/intent in RTP packets (by now conveying bandwidth >> and traffic type in the RTP extension header >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html. >> >> >> >> How these QoS/QoE things are done and used in practice is also illustrat= ed/exemplified in this email discussion: >> >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html >> >> >> >> Prioritization of individual real-time packets (e.g. using diffserve DSC= P bits) have today little impact on the QoE, UNLESS a pipe full with only r= eal-time traffic (which is unusual), because in today=E2=80=99s IP pipes wi= th high bandwidth, packets are not stored for later delivery, but rather dr= opped by routers implementing diffserve (after only a short time period =3D= small buffer size). The only good remedy is higher bandwidth, that can han= dle ALL real-time traffic. >> >> >> >> Prioritization of real-time packets (any diffserve DSCP bits marking) = =E2=80=9Cmakes QoS perfect=E2=80=9D, when there are best effort (=3Dno DSCP= bits set) TCP (=3Dnon real-time) traffic going over the IP pipe that can b= e pushed off. Routers implementing diffserve do that. >> >> >> >> >> >> Having gone through all of this, I want to point out that the huge missi= on to bring quality to real-time traffic over our best effort Internet, is = not a question of huge investments in new bandwidth (that happens anyway fo= r data and streaming video needs) or about sharing bandwidth (bandwidth is = available in access if we only consider the real-time need). It is about bo= rrowing some already existing bandwidth from data usage. And there are only= unnoticeable consequences of this borrowing; A delay of a fraction of a se= cond or so for click-responses or watching a movie. So the huge mission, ma= y be a an easy task if we do it cleverly. >> >> >> >> >> >> And finally, the purpose of this draft-thomson-tram-turn-bandwidth-00.tx= t seems is related to how to request or buy or limit or pay for access to t= he good real-time IP pipes for best QoE. >> >> >> >> Isn=E2=80=99t that the case Alan, rather than intended to be used as QoS= /QoE improvement method (as it has been discussed). >> >> >> >> /Karl >> >> >> >> >> >> >> >> *Fr=C3=A5n:* tram [mailto:tram-bounces@ietf.org] *F=C3=B6r *Alan Johnsto= n >> *Skickat:* den 17 februari 2014 21:14 >> *Till:* tram@ietf.org >> *=C3=84**mne:* [tram] Fwd: I-D Action: >> draft-thomson-tram-turn-bandwidth-00.txt >> >> >> >> All, >> >> >> >> We have written a new I-D on a bandwidth attribute for TURN. The use >> case is to allow a TURN client to indicate to the server the bandwidth i= t >> expects to use for the relayed candidate, or for a TURN server to indica= te >> to the client the maximum bandwidth before the TURN server might apply r= ate >> limiting. >> >> >> >> Note some of the text is from draft-thomson-mmusic-rtcweb-bw-consent >> which was discussed in the past, but this draft does not propose an ICE = use >> case for consent. >> >> >> >> Comments most welcome! >> >> >> >> - Alan - >> >> ---------- Forwarded message ---------- >> From: >> Date: Thu, Feb 13, 2014 at 9:07 PM >> Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt >> To: i-d-announce@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : A Bandwidth Attribute for TURN >> Authors : Martin Thomson >> Bernard Aboba >> Alan Johnston >> Oleg Moskalenko >> Filename : draft-thomson-tram-turn-bandwidth-00.txt >> Pages : 8 >> Date : 2014-02-13 >> >> Abstract: >> An attribute is defined for Session Traversal Utilities for NAT >> (STUN) that allows for declarations of bandwidth limits on the >> negotiated flow. The application of this attribute is the >> negotiation of bandwidth between a Traversal Using Relays around NAT >> (TURN) client and a TURN server. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwidth/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00 >> >> >> 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/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > --047d7b34427aaeee9a04f2d9ddbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
QoS does not even appear in the TRAM charter:=C2=A0https://datatracke= r.ietf.org/doc/charter-ietf-tram/

While some of the = pieces we are building may be useful for QoS, it is not an explicit goal of= this WG, and I would prefer to focus on the concrete milestones that have = already been identified.


On Thu,= Feb 20, 2014 at 6:26 AM, Alan Johnston <alan.b.johnston@gmail.com= > wrote:
= Hi Karl,

Thanks for your comments and feedback on the draft.

You are correct in saying that the BANDWIDTH extension is not about QoS. = =C2=A0It is about fairness between users of a TURN server, and a TURN serve= r being able to indicate rate limiting policy to users.

Personally, I am not sure how much QoS= is actually in scope for TRAM. Have you been following RMCAT where congest= ion avoidance for RTP is being developed? =C2=A0I see some overlap in your = goals and the goals of that work.

- Alan -
On Thu, Feb 20, 2014= at 7:36 AM, Karl Stahl <karl.stahl@intertex.se> wrote:=

Hi Alan,

=C2=A0

Can you commen= t/elaborate on the purpose and intended usage of this draft-thomson-tram-tu= rn-bandwidth-00.txt?

=C2=A0

I am not clear ab=
out how the negotiation of bandwid=
th between a TURN client and a TURN server can be useful considering how ba=
ndwidth is shared on the Internet today and the QoS/QoE implications of thi=
s.
=C2=A0
On this mailing list, this draft has be= en discussed as useful for QoS/QoE improvement, which I cannot see it is. F= or such purposes, richer information than the total bandwidth needs to be c= onveyed to the TURN server / network, compare e.g. DISCUSS/MALICE http://tools.ietf.org/html/draft-martinsen-tram-discuss-00. 
=C2=A0
In the Introduction of draft-thomson-tr= am-turn-bandwidth-00.txt: 
=C2=A0=C2=A0 The operator of a TURN server will like=
ly wish to provide fairness
=C2=A0=C2=A0 between relayed sessions.=C2=A0 A TURN server might also wis=
h to limit the
=C2=A0=C2=A0 use of service to audio-only sessions, =
or low bandwidth video and
=C2=A0=C2=A0 audio sessions.=C2=A0 In addition, the server may apply rate-=
limiting
=C2=A0 =C2=A0policy depending on the credential used=
 for authentication, or the
=C2=A0=C2=A0 origin of the client.=C2=A0 Without the BANDWIDTH attribute,=
 there is no
=C2=A0=C2=A0 way for a client to indicate the expect=
ed bandwidth utilization, or
=C2=A0=C2=A0 for the server to indicate the maximum bandwidth utilizatio=
n allowed
=C2=A0=C2=A0 before rate limiting could be applied.<=
/span>
=C2=A0
I interpret that this draft is ab=
out conveying a =E2=80=9Cfairness policy=E2=80=9D etc. to the TURN server / network, without specifying how t=
his could be realized or implemented. Correct? More is needed for a possibl=
e the realization considering QoS/QoE.
=C2=A0
If richer information is needed for the= realization, that may be the attributes conveyed by DISCUSS/MALICE (but us= ed for TURN, not STUN, see discussion in previous email). 
=C2=A0
On the other hand, if the informatio= n conveyed here (draft-thomson-tram-turn-bandwidth-00.txt) already is avail= able (directly or indirectly) in the DISCUSS attributes, maybe we could end= up with a single draft that includes the real-time traffic information and= sharing policy that needs to be conveyed to the TURN server / network? Is = that something to consider? 
=C2=A0
= 
Or if recreating the payload type (PT) idea/intent in RTP packets (=
by now conveying bandwidth and traffic type in the RTP extension header http://www.ietf.org/mail-archive/web/rtcweb/current/msg09=
129.html is sufficient for QoS/QoE in combination with auto-disc=
ussed TURN servers, maybe draft-thomson-tram-turn-bandwidth-00.txt is the o=
nly thing we need in addition (not the DISCUSS attributes).
=C2=A0
= 
=C2=A0
For better understanding of these=
 QoS/QoE problems, and methods for improving (not specifically discussing t=
he policies of sharing real-time traffic space), I would like to explain:
=C2=A0
= 
Over an IP pipe only used for rea=
l-traffic (no TCP data traffic), it is sufficient that the pipe is wide eno=
ugh for good QoS. That is often used and implemented by separating IP pipes=
 at a lower level using e.g. Ethernet VLAN, MPLS, Ethernet over ATM (std fo=
r ADSL modems). TURN servers can =C2=A0enforce real-traffic into such pipes=
 and QoS is achieved. Let=E2=80=99s call this Level 2 QoS (Network level)
=C2=A0
= 
Over an IP pipe shared between qu=
ality requiring real-time traffic and less demanding data or streaming (usu=
ally TCP) traffic, we have the sharing between these two traffic classes to=
 consider. The main method (and the mechanism making today=E2=80=99s real-t=
ime QoE as good as it often is) is that TCP endpoints back-off and share th=
eir bandwidth usage. Real-time traffic using UDP transport do not back-off,=
 the endpoints using UDP occupy the bandwidth needed. When an IP pipe gets =
filled, it is all endpoint=E2=80=99s TCP bandwidth usage that is back-off a=
nd shared between them, leaving room for the UDP traffic. This is mechanism=
 we experience everyday over the Internet, using our =E2=80=9CSurf IP pipes=
=E2=80=9D. Let=E2=80=99s call this Level 4 QoS (Transport level)<=
/u>
=C2=A0
= 
However, this Level 4 QoS is base=
d on that at congestion times (which happen every time we click =E2=80=93 s=
etting up a TCP flow and transferring some amount of data as quick as possi=
ble) the router handling the most narrow part of the pipe (the congestion p=
oint) drop packets. It is this packet dropping that (i) signals to TCP endp=
oints to reduce their bandwidth (via TCP=E2=80=99s error correction/retrans=
mission mechanism) and (ii) destroys the QoE of real-time traffic. (Both TC=
P and UDP packets are dropped in this process that is triggered by flow int=
ensive TCP traffic.)
=C2=A0
= 
We need (i) but don=E2=80=99t wan=
t (ii) and to improve on this we can e.g. use diffserve, DSCP bits in IP pa=
ckets to instruct routers to always forward the real-time traffic before an=
y unmarked TCP traffic (which usually fills most of the pipe). Then QoS is =
then achieved for real-time traffic. This is Level 3 QoS (IP level). The me=
thod used is =E2=80=9Ctraffic shaping=E2=80=9D: backing off data traffic, l=
eaving real-time traffic free passage without packet loss.
=C2=A0
= 
Here, in TRAM we want to go beyon=
d Level 4 QoS (already available and working as good as it can on the Inter=
net), to give quality demanding WebRTC real-time traffic better QoE by:<=
/u>
a. Forcing real-time traffic into=
 IP-pipes having Level 2 QoS (using auto-discovered TURN servers) 
or

b. Forcing real-tim= e traffic into IP-pipes having Level 3 QoS (using auto-discovered TURN serv= ers). Here we must have traffic shaping mechanisms working, and with correc= t and sufficient information to do the job. This is why we in TRAM discuss = DISCUSS/MALICE, draft-thomson-tram= -turn-bandwidth-00.txt attributes and recreating the payload type (PT) idea= /intent in RTP packets (by now conveying bandwidth and traffic type in the = RTP extension header http://www.ietf.org/mail-archive/w= eb/rtcweb/current/msg09129.html.<= /u>

=C2=A0
= 
How these QoS/QoE things are done=
 and used in practice is also illustrated/exemplified in this email discuss=
ion:
http://www.i=
etf.org/mail-archive/web/rtcweb/current/msg09031.html 
=C2=A0
= 
Prioritization of individual real=
-time packets (e.g. using diffserve DSCP bits) have today little impact on =
the QoE, UNLESS a pipe full with only real-time traffic (which is unusual),=
 because in today=E2=80=99s IP pipes with high bandwidth, packets are not s=
tored for later delivery, but rather dropped by routers implementing diffse=
rve (after only a short time period =3D small buffer size). The only good r=
emedy is higher bandwidth, that can handle ALL real-time traffic. 
=C2=A0
= 
Prioritization of real-time packe=
ts (any diffserve DSCP bits marking) =E2=80=9Cmakes QoS perfect=E2=80=9D, w=
hen there are best effort (=3Dno DSCP bits set) TCP (=3Dnon real-time) traf=
fic going over the IP pipe that can be pushed off. Routers implementing dif=
fserve do that.
=C2=A0
= 
 =C2=A0



Having gone through all of this, =
I want to point out that the hu=
ge mission to bring quality to real-time traffic over our best effort Inter=
net, is not a question of huge investments in new bandwidth (that happens a=
nyway for data and streaming video needs) or about sharing bandwidth (bandw=
idth is available in access if we only consider the real-time need). It is =
about borrowing some already existing bandwidth from data usage. And there =
are only unnoticeable consequences of this borrowing; A delay of a fraction=
 of a second or so for click-responses or watching a movie. So the huge mis=
sion, may be a an easy task if we do it cleverly.



=C2=A0
=

=C2=A0




And finally, the purpose of this =
draft-thomson-tram-turn-bandwidth-00.txt seems is related to how to request=
 or buy or limit or pay for access to the good real-time IP pipes for best =
QoE.




=C2=A0
=

Isn=E2=80=99t that the case Alan,=
 rather than intended to be used as QoS/QoE improvement method (as it has b=
een discussed).




=C2=A0
=

/Karl




=C2=A0
=

=C2=A0




=C2=A0




Fr=C3=A5n:<=
span lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:"Tahoma"=
;,"sans-serif""> tram [mailto:tram-bounces@ietf.org] F=C3=B6r Alan Joh=
nston



Skickat: den 17 februari 2014 21:14
Till: tram@ietf.org
=C3=84mne: [tram] Fwd: I-D Action: draft-t=
homson-tram-turn-bandwidth-00.txt




=C2=A0

All,

=C2=A0

W= e have written a new I-D on a bandwidth attribute for TURN. =C2=A0The use c= ase is to allow a TURN client to indicate to the server the bandwidth it ex= pects to use for the relayed candidate, or for a TURN server to indicate to= the client the maximum bandwidth before the TURN server might apply rate l= imiting.

=C2=A0

Note some of the text is from=C2=A0draft-thomson-mmusic-rt= cweb-bw-consent which was discussed in the past, but this draft does not pr= opose an ICE use case for consent.

=C2=A0

Comments most welcome!

=C2=A0

- Alan -

---------- Forwarded = message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Feb 13, 2= 014 at 9:07 PM
Subject: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
To: i-d-announce@ietf.org<= /a>



A New Internet-Draft is available from the on-line Inter= net-Drafts directories.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : A Bandwidth Attribute for TURN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors= =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Martin Thomson
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bernard = Aboba
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Alan Johnston
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Oleg Moskalenko=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-tho= mson-tram-turn-bandwidth-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 8
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 2014-02-13

Abstract:
=C2=A0 = =C2=A0An attribute is defined for Session Traversal Utilities for NAT
=C2=A0 =C2=A0(STUN) that allows for declarations of bandwidth limits on the=
=C2=A0 =C2=A0negotiated flow. =C2=A0The application of this attribute i= s the
=C2=A0 =C2=A0negotiation of bandwidth between a Traversal Using Re= lays around NAT
=C2=A0 =C2=A0(TURN) client and a TURN server.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-thomson-tram-turn-bandwi= dth/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-thomson-tram-turn-bandwidth-00

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

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

_____________________________________= __________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
I= nternet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

=C2=A0


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram



_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--047d7b34427aaeee9a04f2d9ddbe-- From nobody Thu Feb 20 09:39:31 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F4E1A0199 for ; Thu, 20 Feb 2014 09:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 6kcbkuf467nf for ; Thu, 20 Feb 2014 09:39:27 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id C37F81A0053 for ; Thu, 20 Feb 2014 09:39:27 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa1so2188077pad.13 for ; Thu, 20 Feb 2014 09:39:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=31H/YeYuFjdZoOiupstVTQR9JfRzmfM81lTRlj4uq1o=; b=hFfOebmDe1McYy5TOZL6uEj674g/wCuUpNUDuRP9gfBHYskhAJTwbgf06/+MbZqXTk SJK6f5Q6r8tpBm8lCj9ftsJS9ga+Q6iBinWU9P5ht4mH8ET8L1vF3059W/DN21Z316rX MPRjx/VEx3XX+j+b6G+Jwx3n19pu4BFNwopS1yX2fdQVBDPzBO5h8Mkq1y6DDV0khfqK /PDGtB92/SB15Z06Bkn50mI9AHKZkNiWE9J4ShoZ2UZJq2ramx2vYooq0IlLIu/QW2HX jePPaj6yXkXRJ0rD5chZFU9VTBuCW3y5mB/NhHrVsVoEzh79jARvR9eeFM1MeZi86VzI kYvQ== MIME-Version: 1.0 X-Received: by 10.68.233.70 with SMTP id tu6mr3595838pbc.34.1392917964168; Thu, 20 Feb 2014 09:39:24 -0800 (PST) Received: by 10.68.147.131 with HTTP; Thu, 20 Feb 2014 09:39:23 -0800 (PST) In-Reply-To: References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> Date: Thu, 20 Feb 2014 09:39:23 -0800 Message-ID: From: Oleg Moskalenko To: Justin Uberti Content-Type: multipart/alternative; boundary=047d7b33d14674a50e04f2d9fc72 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/qWkRhV1R1RWQWibEksKI4lLI5Cg Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 17:39:29 -0000 --047d7b33d14674a50e04f2d9fc72 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 20, 2014 at 9:25 AM, Justin Uberti wrote: > > > So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may >> expect that attribute... >> > >> I just noticed that as well. Funny.. >> >> > So, I reconsider my opinion: let's not use the address-family in the >> REFRESH at all, and refresh all relay endpoints regardless of their >> protocols. >> > >> Well it is nice to have in there as the refresh is also used to delete an >> allocation. So if you after ICE is completed ends up only using the IPv6 >> allocation you can delete the IPv4 allocation. This frees up resources on >> the TURN server. >> > > Yeah, that was my thinking as well. If RAF is absent, the refresh applies > to all allocations. If the RAF is specified, the specific allocations are > refreshed/deleted, or an error if the RAF doesn't match the existing > allocations. > I suppose that this is probably the "least intrusive" option - if we want to be able to free the resources. But I'd like to clarify the terminology. How many allocations we have per TURN session ? I'd suggest to use the term "relay endpoints" for the allocated relay sockets but I'd keep term "allocation" as a synonym to "TURN session" (and then we have a single allocation even if we have two relay endpoints per allocation). Or we can separate "TURN session" and "allocation" and make the "allocation" a synonym to "relay endpoint". We have to agree on a single terminology to avoid the confusions. So, RAF in REFRESH can be: 1) absent - then it is applicable to all available relay endpoints in the session; 2) ipv4 - then it is applicable to ipv4 endpoint only and returns 443 if ipv4 endpoint does not exist; 3) ipv6 - then it is applicable to ipv6 endpoint only and returns 443 if ipv6 endpoint does not exist; 4) ipv4+ipv6 - then it is applicable to both endpoint only and returns 443 if ipv4 OR ipv6 endpoint does not exist; Honestly, I'd remove 443 requirement and if the endpoint does not exist I'd just ignore the request. That would simplify the client code on resource cleaning. But that would make the specs not-backward-compatible so I suggest keeping the 443 error. Oleg --047d7b33d14674a50e04f2d9fc72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 20, 2014 at 9:25 AM, Justin Uberti &l= t;juberti@google.co= m> wrote:

> So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may = expect that attribute...
>
I just noticed that as well. Funny..

> So, I reconsider my opinion: let's not use the address-family in t= he REFRESH at all, and refresh all relay endpoints regardless of their prot= ocols.
>
Well it is nice to have in there as the refresh is also used to delet= e an allocation. So if you after ICE is completed ends up only using the IP= v6 allocation you can delete the IPv4 allocation. This frees up resources o= n the TURN server.

Yeah, that was my thinking as well. = If RAF is absent, the refresh applies to all allocations. If the RAF is spe= cified, the specific allocations are refreshed/deleted, or an error if the = RAF doesn't match the existing allocations.

I suppose that this= is probably the "least intrusive" option - if we want to be able= to free the resources. But I'd like to clarify the terminology. How ma= ny allocations we have per TURN session ? I'd suggest to use the term &= quot;relay endpoints" for the allocated relay sockets but I'd keep= term "allocation" as a synonym to "TURN session" (and = then we have a single allocation even if we have two relay endpoints per al= location).

Or we can separate "TURN session&= quot; and "allocation" and make the "allocation" a syno= nym to "relay endpoint". We have to agree on a single terminology= to avoid the confusions.

So, R= AF in REFRESH can be:

1) absent - t= hen it is applicable to all available relay endpoints in the session;
2) ipv4 - then it is applicable to ipv4 endpoint= only and returns 443 if ipv4 endpoint does not exist;
3) ipv6 - then it= is applicable to ipv6 endpoint only and returns 443 if ipv6 endpoint does = not exist;
4) ipv4+ipv6 - then it is applicable to both endpoint only and returns 443 = if ipv4 OR ipv6 endpoint does not exist;

Honestly, I'd remove 443 requirement and if the endpoint does not= exist I'd just ignore the request. That would simplify the client code= on resource cleaning. But that would make the specs not-backward-compatibl= e so I suggest keeping the 443 error.

Oleg


--047d7b33d14674a50e04f2d9fc72-- From nobody Thu Feb 20 09:42:19 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA33B1A01D5 for ; Thu, 20 Feb 2014 09:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 AjXr-CD_sgPM for ; Thu, 20 Feb 2014 09:42:14 -0800 (PST) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 394651A0199 for ; Thu, 20 Feb 2014 09:42:14 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id jx11so2145275veb.35 for ; Thu, 20 Feb 2014 09:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=8GhgDIti1J09XVDIWx1s7CtpbEKuHOHW+dsGZOnuIuE=; b=iTO+LmaSXXZBoKYMuIG9vOW3t61ZaioZjzJhdbV3WxiLFCR3gIbY0z/U4vQ7aCnsB9 wkrnL1U5GEl174qBNHdYzUKbO1kL5gVx9F69iqv5D3DZydixclQM3XBVuTC2cJzW28dy tq2zmp9tDsS15rBY/IOqQzjcAmTRud5gosADOZuzl54PWYuW+2D7wKzxNEQexu2cwXqR M+YGtrj49OGxo2+BJcRzosTtFgoXl065n92uxnz3NezLh6Zr/HhFzopoTSdQ8PdFEW5H vnDhO4wUlIUGN2uytvhPvYqK4pK7U25vGKJ2l2PZ+zjoAV6zAS10wSz8r5AVNG2d1XAx 6pYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=8GhgDIti1J09XVDIWx1s7CtpbEKuHOHW+dsGZOnuIuE=; b=lWFvhJyDcVpKyt1M7VPGl9vDZ/K+ouFWHbLaUD7UZzhwjhCxNzMOQwkQqQBpGeiMI8 YXCMg6mDQV5VBIChiB8tvy91TAh/TL+Zzo9BCyeFePa7OYw/yjfucQbYh6tphYirFfr7 6No7ev7C6HWjiuY5/wxh/Hrl1JqHkkzUT2esfGkbQvzMNDFvoBQ2VExTky2kZQ5RyjKt bCi8pwS/3LsKw98GbHNmSKxlxINDz00o0pkuN3Rl6oeEaPwTUFn5wJJZuUq3IaWKTVU+ 2luvpgajbfajQMju7PwLE+bKpD4BqGQzf6k7wB7wZ+TPdXKROHTBbLYFvBWKcdzDhQnK XwTw== X-Gm-Message-State: ALoCoQk2BapuDKC0X2PZ2ugoeD8jceyui5XFcnQi9fplJGhxwey7rtsQ9DOgVrf5e/A6HtfCwI6EujYrZtAIMww78eF3DkQAcLfxAfOYHzNZF2skjtrwPcN3vPQmlXDr4D2p6ajcnUC8IURYcCs0KczBMke2hGORtQxX4tcC587aP8ap7ETYnS1QFK3jD/++88o337H0/TUZ X-Received: by 10.221.73.73 with SMTP id yr9mr1743797vcb.76.1392918130418; Thu, 20 Feb 2014 09:42:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Thu, 20 Feb 2014 09:41:50 -0800 (PST) In-Reply-To: References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> From: Justin Uberti Date: Thu, 20 Feb 2014 09:41:50 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a113651965d730704f2da0688 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/2VxHChW2gykYMkscyp3pfC48f5k Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 17:42:16 -0000 --001a113651965d730704f2da0688 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 20, 2014 at 9:39 AM, Oleg Moskalenko wrote: > > > > On Thu, Feb 20, 2014 at 9:25 AM, Justin Uberti wrote: > >> >> > So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may >>> expect that attribute... >>> > >>> I just noticed that as well. Funny.. >>> >>> > So, I reconsider my opinion: let's not use the address-family in the >>> REFRESH at all, and refresh all relay endpoints regardless of their >>> protocols. >>> > >>> Well it is nice to have in there as the refresh is also used to delete >>> an allocation. So if you after ICE is completed ends up only using the IPv6 >>> allocation you can delete the IPv4 allocation. This frees up resources on >>> the TURN server. >>> >> >> Yeah, that was my thinking as well. If RAF is absent, the refresh applies >> to all allocations. If the RAF is specified, the specific allocations are >> refreshed/deleted, or an error if the RAF doesn't match the existing >> allocations. >> > > I suppose that this is probably the "least intrusive" option - if we want > to be able to free the resources. But I'd like to clarify the terminology. > How many allocations we have per TURN session ? I'd suggest to use the term > "relay endpoints" for the allocated relay sockets but I'd keep term > "allocation" as a synonym to "TURN session" (and then we have a single > allocation even if we have two relay endpoints per allocation). > > Or we can separate "TURN session" and "allocation" and make the > "allocation" a synonym to "relay endpoint". We have to agree on a single > terminology to avoid the confusions. > > So, RAF in REFRESH can be: > > 1) absent - then it is applicable to all available relay endpoints in the > session; > 2) ipv4 - then it is applicable to ipv4 endpoint only and returns 443 if > ipv4 endpoint does not exist; > 3) ipv6 - then it is applicable to ipv6 endpoint only and returns 443 if > ipv6 endpoint does not exist; > 4) ipv4+ipv6 - then it is applicable to both endpoint only and returns 443 > if ipv4 OR ipv6 endpoint does not exist; > > Honestly, I'd remove 443 requirement and if the endpoint does not exist > I'd just ignore the request. That would simplify the client code on > resource cleaning. But that would make the specs not-backward-compatible so > I suggest keeping the 443 error. > > I think it would be good for the client to know that its REFRESH request could not be fully handled by the server. Ergo, let's return 443 as indicated in your list above. --001a113651965d730704f2da0688 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 20, 2014 at 9:39 AM, Oleg Moskalenko = <mom040267@gmai= l.com> wrote:



On Thu, Feb 20, 2014= at 9:25 AM, Justin Uberti <juberti@google.com> wrote:

> So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may = expect that attribute...
>
I just noticed that as well. Funny..

> So, I reconsider my opinion: let's not use the address-family in t= he REFRESH at all, and refresh all relay endpoints regardless of their prot= ocols.
>
Well it is nice to have in there as the refresh is also used to delet= e an allocation. So if you after ICE is completed ends up only using the IP= v6 allocation you can delete the IPv4 allocation. This frees up resources o= n the TURN server.

Yeah, that was my thinking as well. = If RAF is absent, the refresh applies to all allocations. If the RAF is spe= cified, the specific allocations are refreshed/deleted, or an error if the = RAF doesn't match the existing allocations.

I suppose tha= t this is probably the "least intrusive" option - if we want to b= e able to free the resources. But I'd like to clarify the terminology. = How many allocations we have per TURN session ? I'd suggest to use the = term "relay endpoints" for the allocated relay sockets but I'= d keep term "allocation" as a synonym to "TURN session"= (and then we have a single allocation even if we have two relay endpoints = per allocation).

Or we can separate "TURN session&= quot; and "allocation" and make the "allocation" a syno= nym to "relay endpoint". We have to agree on a single terminology= to avoid the confusions.

So, R= AF in REFRESH can be:

1) absent - t= hen it is applicable to all available relay endpoints in the session;
2) ipv4 - then it is applicable to ipv4 endpoint= only and returns 443 if ipv4 endpoint does not exist;
3) ipv6 - then it= is applicable to ipv6 endpoint only and returns 443 if ipv6 endpoint does = not exist;
4) ipv4+ipv6 - then it is applicable to both endpoint only and returns 443 = if ipv4 OR ipv6 endpoint does not exist;

Honestly, I'd remove 443 requirement and if the endpoint does not= exist I'd just ignore the request. That would simplify the client code= on resource cleaning. But that would make the specs not-backward-compatibl= e so I suggest keeping the 443 error.


I think it would be good for the client to kn= ow that its REFRESH request could not be fully handled by the server. Ergo,= let's return 443 as indicated in your list above.
--001a113651965d730704f2da0688-- From nobody Thu Feb 20 09:42:46 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75681A0219 for ; Thu, 20 Feb 2014 09:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 7h7rkRMlnnCM for ; Thu, 20 Feb 2014 09:42:42 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AA2E91A0053 for ; Thu, 20 Feb 2014 09:42:42 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id kp14so2198610pab.20 for ; Thu, 20 Feb 2014 09:42:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r/YAt9C8+bx1rfIYTMqZoxTb+24lg/knQym/drDCKqw=; b=0Ra23WxmK1jYR20+k+NezrTWOjcfL0sW8TrHJu2rd7bZGKfhiTlwh2RyhfMcSXVrQv P1zaJnhM6u8PLR1xM9DG7le5SF7TIPAi+iVeDZSDa/Oq8vCzRld2/NLapXv/6p5c1m9V LzzVYrN49pQNZJkQC+AtsXDEn5kuMU6bUL+5dj9K5U13Qfa1K3gn2Rgqa7/jS17rsxJ2 ojq230/53wq7ZRigv5ut1kRTooOX1NzoAlOP9TPfhcNL8iTcfkvQh7pA0Ar5gU3lQHug /BPvFBt+aWE0jXi1CP0LF6cSotUr4TtxtRvRMYsmm8TKTUrLx/kG9LNpxD+3kECKsUZi FW5Q== MIME-Version: 1.0 X-Received: by 10.66.142.233 with SMTP id rz9mr3494315pab.71.1392918158758; Thu, 20 Feb 2014 09:42:38 -0800 (PST) Received: by 10.68.147.131 with HTTP; Thu, 20 Feb 2014 09:42:38 -0800 (PST) In-Reply-To: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> Date: Thu, 20 Feb 2014 09:42:38 -0800 Message-ID: From: Oleg Moskalenko To: Alan Johnston Content-Type: multipart/alternative; boundary=001a113448080dd93104f2da08d1 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/iiui8wI4m65E1MZGdfslIl4J0kI Cc: Karl Stahl , "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 17:42:44 -0000 --001a113448080dd93104f2da08d1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston wrote: > > > > Personally, I am not sure how much QoS is actually in scope for TRAM. Have > you been following RMCAT where congestion avoidance for RTP is being > developed? I see some overlap in your goals and the goals of that work. > - > > I'd concentrate on the TURN application-level functionality, for now, and I'd leave QoS for the future discussions. --001a113448080dd93104f2da08d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston &l= t;alan.b.joh= nston@gmail.com> wrote:



Personally, I am not sure how much QoS= is actually in scope for TRAM. Have you been following RMCAT where congest= ion avoidance for RTP is being developed? =A0I see some overlap in your goa= ls and the goals of that work.
-=

=

I'd conce= ntrate on the TURN application-level functionality, for now, and I'd le= ave QoS for the future discussions.


--001a113448080dd93104f2da08d1-- From nobody Thu Feb 20 10:40:19 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737F41A022D for ; Thu, 20 Feb 2014 10:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 0pOkQV_c6ZMf for ; Thu, 20 Feb 2014 10:40:16 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 86A4E1A01CE for ; Thu, 20 Feb 2014 10:40:16 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3BA84403C2 for ; Thu, 20 Feb 2014 13:40:12 -0500 (EST) Message-ID: <53064C0B.1000302@viagenie.ca> Date: Thu, 20 Feb 2014 13:40:11 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/lAUXSzO_9PcIvlQw0rMd1Q6wGQc Subject: [tram] Scribe X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 18:40:18 -0000 All, Could someone please volunteer now to take notes during the session in London? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Feb 20 10:51:50 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6531A0278; Thu, 20 Feb 2014 10:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 bt2Z-QDVdQoP; Thu, 20 Feb 2014 10:51:44 -0800 (PST) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6701A026E; Thu, 20 Feb 2014 10:51:39 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id m1so2568201oag.20 for ; Thu, 20 Feb 2014 10:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=406s6tBufDmJMwiw+8Me76lYoUZuTYQzBZDf7w4pfl4=; b=TLP+WkIwW7zK+qr6/C17BGqqef2dbnNgHLOoFvUq0cz15ZLcopdIyJdzuVfRiwkF1P qkw7OP9/wZBgVa9JUyaZFUbRpG3Hn1cYJZKUtNrNyULzIdJIe6K2WEPGGqWINhEpgoGP HoRxYnefwnjUaM6E44N/XpfXt/09eFy3EXeaNrlmFyCDolESHodZpmkBuj3YIaG+0jv1 X+4xO8TDvWP7E5VGv4zN1hxaiuJ1qCxsQ24o6bCHW7zrndCNI/dVtVFmZvTJ6ZkomUce /AvvUaa7uOu21SXvuJhw2H1dTZJlf4ydLmn63ORy2YUvR1+lITMEVJju83DfXK8rng6p imJg== X-Received: by 10.60.146.194 with SMTP id te2mr3269176oeb.3.1392922294598; Thu, 20 Feb 2014 10:51:34 -0800 (PST) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id su13sm30589823oeb.1.2014.02.20.10.51.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Feb 2014 10:51:33 -0800 (PST) Message-ID: <53064EB4.7000406@gmail.com> Date: Thu, 20 Feb 2014 12:51:32 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Simon Perreault , "tram@ietf.org" References: <52F8EA80.8000104@viagenie.ca> In-Reply-To: <52F8EA80.8000104@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/JkgHd95xuq2SFLk9uy6Jq6hECFI Cc: "tsv-ads@ietf.org" Subject: Re: [tram] Agenda for London X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 18:51:46 -0000 Dear TRAMsters, You should see an announcement Real Soon Now, but TRAM was approved on the telechat a few minutes ago. I've asked Simon and Gonzalo Camarillo to serve as chairs. I want to express my appreciation to you for the work you did collecting milestones for the charter. I look forward to seeing many of you in London (and the rest of you on the mailing list, where real work gets done). Spencer, as AD On 02/10/2014 09:04 AM, Simon Perreault wrote: > Folks, > > This working group is still forming, but it's less than a month until > IETF 89 in London, so we need to work out our agenda. > > I've already asked the "candidate draft" authors for a BoF-type > presentation focusing on the problem statement. However if our > chartering is accepted, an I am personally optimistic about that, then > that means we're done with stating problems, and we can start the real > work. The first order of business would then be discussing the potential > adoption of candidate drafts. So that's what I think we should be > planning for. > > We have a one hour slot. It will be packed. How about this? > > 0. T + 00:00: Administrativia > 1. T + 00:05: draft-petithuguenin-tram-turn-dtls-00 (?) > 2. T + 00:15: draft-reddy-behave-turn-auth (Tirumaleswar Reddy) > 3. T + 00:25: draft-johnston-tram-stun-origin (Alan Johnston) > 4. T + 00:35: "TURN Extension for Third Party Authorization" (draft to > be published) (Alan Johnston) > 5. T + 00:50: TURN server auto-discovery mechanism (draft to be > published) (?) > 6. T + 01:00: EOF > > Please voice your opinion, suggest changes, etc. > > Simon From nobody Thu Feb 20 10:56:04 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1821A01CE for ; Thu, 20 Feb 2014 10:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548] autolearn=ham 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 COPgs1bvKo70 for ; Thu, 20 Feb 2014 10:56:00 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id B87591A00EC for ; Thu, 20 Feb 2014 10:55:59 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FABhPBlOHCzIm/2dsb2JhbABWA4JCIyE4V8AOgRAWdIIlAQEBAQMSGzoSEAIBCA0BAwQBAQsdByERFAkIAgQBDQUIGodPAxEBokukCg2HUheMT4FkIRAGARGDE4EUBJZDAYhbhW+FRoMtgio X-IronPort-AV: E=Sophos; i="4.97,513,1389762000"; d="scan'208,217"; a="50368607" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 20 Feb 2014 13:55:55 -0500 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 20 Feb 2014 13:42:55 -0500 Received: from AZ-US1EXMB06.global.avaya.com ([fe80::38da:dafb:7358:e6f5]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0174.001; Thu, 20 Feb 2014 13:55:53 -0500 From: "Yoakum, John H (John)" To: Oleg Moskalenko , Alan Johnston Thread-Topic: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: AQHPLmMlcJtLqkuUgEmVgUSRCLyaepq+efWA Date: Thu, 20 Feb 2014 18:55:52 +0000 Message-ID: <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: multipart/alternative; boundary="_000_93BEDDC39A54294B9E78C7860516FA4724AA4422AZUS1EXMB06glob_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/XZNORKXJLjnv8z4jdULXk4M7hKc Cc: Karl Stahl , "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 18:56:02 -0000 --_000_93BEDDC39A54294B9E78C7860516FA4724AA4422AZUS1EXMB06glob_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 I fully agree with the comments that QOS should be a low priority for the i= nitial focus of the TRAM efforts. There are other groups doing QOS work an= d frankly I engage in WebRTC multimedia interactions daily over the Interne= t, enterprise VPNs, and various combinations and seldom suffer egregious qu= ality issues. I am more concerned about carriers doing things to regulate = or degrade WebRTC flows than a failure of existing Internet mechanisms to e= nable them. Significant focus on QOS before we better enable TURN to be easily used in = a browser environment taking advantage or normal web characteristics (as op= posed to historic telephony constructs) would seem to be highly distracting= at this point. Cheers, John AVAYA 1.919.425.8446 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.t= xt On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston > wrote: Personally, I am not sure how much QoS is actually in scope for TRAM. Have = you been following RMCAT where congestion avoidance for RTP is being develo= ped? I see some overlap in your goals and the goals of that work. - I'd concentrate on the TURN application-level functionality, for now, and I= 'd leave QoS for the future discussions. --_000_93BEDDC39A54294B9E78C7860516FA4724AA4422AZUS1EXMB06glob_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

I fully agree with the co= mments that QOS should be a low priority for the initial focus of the TRAM = efforts.  There are other groups doing QOS work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterp= rise VPNs, and various combinations and seldom suffer egregious quality iss= ues.  I am more concerned about carriers doing things to regulate or d= egrade WebRTC flows than a failure of existing Internet mechanisms to enable them.

 <= /p>

Significant focus on QOS = before we better enable TURN to be easily used in a browser environment tak= ing advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at t= his point.

 <= /p>

 <= /p>

= Cheers,

John

<= o:p> 

AV= AYA
1.919.425.8446

 <= /p>

From: tram [ma= ilto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Thursday, February 20, 2014 12:43 PM
To: Alan Johnston
Cc: Karl Stahl; tram@ietf.org
Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwid= th-00.txt

 

 

 

On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <<= a href=3D"mailto:alan.b.johnston@gmail.com" target=3D"_blank">alan.b.johnst= on@gmail.com> wrote:

 

 

 

Personally, I am not sure how much QoS is actually i= n scope for TRAM. Have you been following RMCAT where congestion avoidance = for RTP is being developed?  I see some overlap in your goals and the = goals of that work.

-

 

 

I'd concentrate on th= e TURN application-level functionality, for now, and I'd leave QoS for the = future discussions.

--_000_93BEDDC39A54294B9E78C7860516FA4724AA4422AZUS1EXMB06glob_-- From nobody Thu Feb 20 11:13:03 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866DB1A024A for ; Thu, 20 Feb 2014 11:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 c5lveQyDKUeU for ; Thu, 20 Feb 2014 11:12:58 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id BC8F91A0243 for ; Thu, 20 Feb 2014 11:12:58 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 11:12:56 -0800 From: Michael Hammer To: "yoakum@avaya.com" , "mom040267@gmail.com" , "alan.b.johnston@gmail.com" Thread-Topic: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: AQHPLBx+/w69jI7P3kSEjcKKvn9TyZq+N0pvgAC84wCAABR3AP//fjww Date: Thu, 20 Feb 2014 19:12:55 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF3175B@sc9-ex2k10mb1.corp.yaanatech.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.163] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0215_01CF2E45.D908D6D0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/dmuphx4v7ohMAQC8Hkf3sZG1vIo Cc: "karl.stahl@intertex.se" , "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:13:01 -0000 ------=_NextPart_000_0215_01CF2E45.D908D6D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0216_01CF2E45.D908D6D0" ------=_NextPart_001_0216_01CF2E45.D908D6D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Perhaps one thing TRAM signaling can return to the client is a link to an API for doing QoS control. Then whatever QoS control protocol you want to use could be patched in. Might make this a little more future proof. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Yoakum, John H (John) Sent: Thursday, February 20, 2014 1:56 PM To: Oleg Moskalenko; Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt +1 I fully agree with the comments that QOS should be a low priority for the initial focus of the TRAM efforts. There are other groups doing QOS work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs, and various combinations and seldom suffer egregious quality issues. I am more concerned about carriers doing things to regulate or degrade WebRTC flows than a failure of existing Internet mechanisms to enable them. Significant focus on QOS before we better enable TURN to be easily used in a browser environment taking advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point. Cheers, John AVAYA 1.919.425.8446 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston wrote: Personally, I am not sure how much QoS is actually in scope for TRAM. Have you been following RMCAT where congestion avoidance for RTP is being developed? I see some overlap in your goals and the goals of that work. - I'd concentrate on the TURN application-level functionality, for now, and I'd leave QoS for the future discussions. ------=_NextPart_001_0216_01CF2E45.D908D6D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Perhaps one thing TRAM signaling can return to the client is a link = to an API for doing QoS control.

Then whatever QoS control protocol you want to use could be patched = in.

Might make this a little more future proof.

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite = 120

Milpitas, CA 95035 = USA

 

From:= = tram [mailto:tram-bounces@ietf.org] On Behalf Of Yoakum, John H = (John)
Sent: Thursday, February 20, 2014 1:56 PM
To: = Oleg Moskalenko; Alan Johnston
Cc: Karl Stahl; = tram@ietf.org
Subject: Re: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

+1

I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts.  There are other groups = doing QOS work and frankly I engage in WebRTC multimedia interactions = daily over the Internet, enterprise VPNs, and various combinations and = seldom suffer egregious quality issues.  I am more concerned about = carriers doing things to regulate or degrade WebRTC flows than a failure = of existing Internet mechanisms to enable them.

 

Significant focus on QOS before we better enable TURN to be easily = used in a browser environment taking advantage or normal web = characteristics (as opposed to historic telephony constructs) would seem = to be highly distracting at this point.

 

 

Ch= eers,

Jo= hn

 

AVAY= A
1.9= 19.425.8446

 

From:= = tram [mailto:tram-bounces@ietf.org] = On Behalf Of Oleg Moskalenko
Sent: Thursday, February = 20, 2014 12:43 PM
To: Alan Johnston
Cc: Karl Stahl; = tram@ietf.org
Subject: = Re: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

 

 

On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <alan.b.johnston@gmail.com> = wrote:

 

 

 

Personally, I am not sure how much QoS is actually in = scope for TRAM. Have you been following RMCAT where congestion avoidance = for RTP is being developed?  I see some overlap in your goals and = the goals of that work.

-

 

 

I'd concentrate on the TURN = application-level functionality, for now, and I'd leave QoS for the = future discussions.

------=_NextPart_001_0216_01CF2E45.D908D6D0-- ------=_NextPart_000_0215_01CF2E45.D908D6D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIy MDE5MTI1NFowIwYJKoZIhvcNAQkEMRYEFPybcFnvLIEewCE1yDg+OFpcr8U/MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAURj8qVvGMO/mGip1wZmMPVUGXunrYmHyj+HXdKWK w0eiyySe+kCEiItWsKOsx+s9eottsRnu3bRyZWUC5U64kNQBH/NkzomKrfb9k5CXdo68X5dQiG8f sQ5JDvQ8E1SrjFNteMZ5CPqM6tfoOUhC6tzLqCJH6yev7x+nfvp2LvQgTMQAQ/qwGGy98Py/5EPt 2SHEMcLzv/xaL7vuKi8MQEdLP7mwkOaY//9TOmDm9Zo4jrN+66mGOfzZgHamlHstbYijnA82FMPr 3Z+LpX7/YVWfsX0EMy4HqNiPw4Rbq1TwIO4XQx0PNK8i1auF1576Z5feQ6N8WMc6uIH1O9k9uwAA AAAAAA== ------=_NextPart_000_0215_01CF2E45.D908D6D0-- From nobody Thu Feb 20 11:22:16 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792921A0271 for ; Thu, 20 Feb 2014 11:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 0LyAkf1j8Wkl for ; Thu, 20 Feb 2014 11:22:14 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id ED2391A026B for ; Thu, 20 Feb 2014 11:22:10 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta07.westchester.pa.mail.comcast.net with comcast id UfZ91n0041uE5Es57jN7w9; Thu, 20 Feb 2014 19:22:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id UjN71n0073ZTu2S3cjN767; Thu, 20 Feb 2014 19:22:07 +0000 Message-ID: <530655DF.6080604@alum.mit.edu> Date: Thu, 20 Feb 2014 14:22:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF3175B@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF3175B@sc9-ex2k10mb1.corp.yaanatech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392924127; bh=ZSYeKx5TcGTwp1br9WYEKyIQUl0wqge0GhRduazou/Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=m5OEhPdBmJFzgLCIdXxxvHu0UDFrAN+ycEsSP8qMb/hakrXnQQ0+pvl83ol3n4YXl NjYgHhD2FxiEBMtc0VSpRUjsWutHQkYUvJeqrlJZsVm+mGvnwBJLCbnEii5H9gGaB8 ed/Hoy4+X/FXFngateG57RdTIgwYVOcPEkoPGwTPceNNGRjrjAGwIyDTSjs0ISRLIg 3iGUtr+ZSkiKIW+hBSNrf4Uyyyi0/xFpOJfEbrON/n5qDERZcpKJKiwCbkVQiw7SZy rNsCRhPMfZl4XDP7hspxO+zv8CGOc/BvtvNkI3S6Imk8ccMV8rDFkPLHac87dTdqqc TEi8BiBrCaJ9w== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/nzKJnaaY7Z5YdV8IJciBvXh7K3c Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:22:15 -0000 On 2/20/14 2:12 PM, Michael Hammer wrote: > Perhaps one thing TRAM signaling can return to the client is a link to > an API for doing QoS control. > > Then whatever QoS control protocol you want to use could be patched in. > > Might make this a little more future proof. "A link to an API"????? AFAIK that doesn't make sense. A link that identifies a target and protocol to control QoS makes some sense to me. But then how do you know the client will support the protocol you are offering? Thanks, Paul From nobody Thu Feb 20 11:25:36 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B698D1A027F for ; Thu, 20 Feb 2014 11:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 4CRDjoLw13ay for ; Thu, 20 Feb 2014 11:25:31 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 292881A0279 for ; Thu, 20 Feb 2014 11:25:31 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id v10so2202368pde.41 for ; Thu, 20 Feb 2014 11:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hMyk0G1TdpFaNlQAPPuhx3BokNjyxgKDD09LXlyqhKA=; b=JKO1pNRnFbDPoOGKXvk5URtvy1g12zRx1z7PtTA8LpiGXF2a4vIW/6+V3Ki0kF+09F yMIlbCt9bAABOnnTPhwKMYonOco6mr7pG7DtUBuNZ1pFMVGsBwEjIgJHXDbXaiJtFSJq lo3mzRijlS17AjaPiDXqSEVO4ZGGFTqOojeL0/6hKnc5kGK3rB8MD/dAM1X4J2ZOKNhl p5jrxZiTDuWY4VRkCJaLWtRzLY9SvzjkFcDtoMe7BtAL2iyQHyvLs9R3IgmNGNOxyDIP XI/uz4qAaqB62RVUVGyitGNkRuozQbUNP6vSW30C7ej2i8swQspebdaq9+yoZrDg3fJD SWKg== MIME-Version: 1.0 X-Received: by 10.68.170.66 with SMTP id ak2mr4058526pbc.5.1392924327631; Thu, 20 Feb 2014 11:25:27 -0800 (PST) Received: by 10.68.147.131 with HTTP; Thu, 20 Feb 2014 11:25:27 -0800 (PST) In-Reply-To: <530655DF.6080604@alum.mit.edu> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF3175B@sc9-ex2k10mb1.corp.yaanatech.com> <530655DF.6080604@alum.mit.edu> Date: Thu, 20 Feb 2014 11:25:27 -0800 Message-ID: From: Oleg Moskalenko To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b86d55cbf609d04f2db771a Archived-At: http://mailarchive.ietf.org/arch/msg/tram/pclNLnyb1WLwvv67by_VvJ1NGrs Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:25:32 -0000 --047d7b86d55cbf609d04f2db771a Content-Type: text/plain; charset=ISO-8859-1 Obviously, a "link to API" means here "a URL/URI to REST API to QoS". I am not sure that such web-based API exist. May be, a custom proprietary implementation can be used. But I'd postpone any discussion on that matter. On Thu, Feb 20, 2014 at 11:22 AM, Paul Kyzivat wrote: > On 2/20/14 2:12 PM, Michael Hammer wrote: > >> Perhaps one thing TRAM signaling can return to the client is a link to >> an API for doing QoS control. >> >> Then whatever QoS control protocol you want to use could be patched in. >> >> Might make this a little more future proof. >> > > "A link to an API"????? > > AFAIK that doesn't make sense. > > A link that identifies a target and protocol to control QoS makes some > sense to me. But then how do you know the client will support the protocol > you are offering? > > Thanks, > Paul > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --047d7b86d55cbf609d04f2db771a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Obviously, a "link to API" means here = "a URL/URI to REST API to QoS".

I am not sure that s= uch=A0 web-based API exist. May be, a custom proprietary implementation can= be used.

But I'd postpone any discussion on that matter.

<= br>


On Thu, Feb 20, 2014 at 11:22 AM, Paul Kyzivat <pkyzivat@alum.mit.ed= u> wrote:
On 2/20/14 2:12 PM, Michael = Hammer wrote:
Perhaps one thing TRAM signaling can return to the client is a link to
an API for doing QoS control.

Then whatever QoS control protocol you want to use could be patched in.

Might make this a little more future proof.

"A link to an API"?????

AFAIK that doesn't make sense.

A link that identifies a target and protocol to control QoS makes some sens= e to me. But then how do you know the client will support the protocol you = are offering?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul


_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--047d7b86d55cbf609d04f2db771a-- From nobody Thu Feb 20 11:30:28 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DD21A015F for ; Thu, 20 Feb 2014 11:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 1K8UggzkWsM8 for ; Thu, 20 Feb 2014 11:30:24 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3B01A01F2 for ; Thu, 20 Feb 2014 11:30:24 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 11:30:22 -0800 From: Michael Hammer To: "mom040267@gmail.com" , "pkyzivat@alum.mit.edu" Thread-Topic: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: AQHPLBx+/w69jI7P3kSEjcKKvn9TyZq+N0pvgAC84wCAABR3AP//fjwwgACJGYCAAADugP//emRA Date: Thu, 20 Feb 2014 19:30:21 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF3186E@sc9-ex2k10mb1.corp.yaanatech.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF3175B@sc9-ex2k10mb1.corp.yaanatech.com> <530655DF.6080604@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.163] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_024C_01CF2E48.483ACD90" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/eqROx4G_SZxZq7FoDglHATiKiz0 Cc: "tram@ietf.org" Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:30:27 -0000 ------=_NextPart_000_024C_01CF2E48.483ACD90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_024D_01CF2E48.483ACD90" ------=_NextPart_001_024D_01CF2E48.483ACD90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Paul, Speaking loosely. Meant in the same vein that architecturally, SIP, SDP, RTP, STUN, TURN, ICE, etc. Know how to work collectively, so you don't have to design this monolithically into one protocol. SDP knows how to select codecs, no? I would hope that IETF doesn't create so many that it needs to be negotiated. Hope you catch my drift now. Yes, was hoping that if architecture vision indicates how to separate these protocols, then we can postpone discussion on QoS to another WG to address, if it hasn't already. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 2:25 PM To: Paul Kyzivat Cc: tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Obviously, a "link to API" means here "a URL/URI to REST API to QoS". I am not sure that such web-based API exist. May be, a custom proprietary implementation can be used. But I'd postpone any discussion on that matter. On Thu, Feb 20, 2014 at 11:22 AM, Paul Kyzivat wrote: On 2/20/14 2:12 PM, Michael Hammer wrote: Perhaps one thing TRAM signaling can return to the client is a link to an API for doing QoS control. Then whatever QoS control protocol you want to use could be patched in. Might make this a little more future proof. "A link to an API"????? AFAIK that doesn't make sense. A link that identifies a target and protocol to control QoS makes some sense to me. But then how do you know the client will support the protocol you are offering? Thanks, Paul _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram ------=_NextPart_001_024D_01CF2E48.483ACD90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Paul,

 

Speaking loosely.

Meant in the same vein that architecturally, SIP, SDP, RTP, STUN, = TURN, ICE, etc…

Know how to work collectively, so you don’t have to design this = monolithically into one protocol.

SDP knows how to select codecs, no?

I would hope that IETF doesn’t create so many that it needs to = be negotiated.

Hope you catch my drift now.

 

Yes, was hoping that if architecture vision indicates how to separate = these protocols,

then we can postpone discussion on QoS to another WG to address, if = it hasn’t already.

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite = 120

Milpitas, CA 95035 = USA

 

From:= = tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg = Moskalenko
Sent: Thursday, February 20, 2014 2:25 = PM
To: Paul Kyzivat
Cc: = tram@ietf.org
Subject: Re: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

Obviously, a "link = to API" means here "a URL/URI to REST API to = QoS".

I am not sure that such  web-based = API exist. May be, a custom proprietary implementation can be = used.

But I'd postpone any = discussion on that matter.

 

 

On Thu, Feb 20, 2014 at 11:22 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> = wrote:

On 2/20/14 2:12 PM, = Michael Hammer wrote:

Perhaps one = thing TRAM signaling can return to the client is a link to
an API for = doing QoS control.

Then whatever QoS control protocol you want to = use could be patched in.

Might make this a little more future = proof.

 

"A link to an API"?????

AFAIK that = doesn't make sense.

A link that identifies a target and protocol = to control QoS makes some sense to me. But then how do you know the = client will support the protocol you are offering?

    =     Thanks,
        = Paul



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

 

------=_NextPart_001_024D_01CF2E48.483ACD90-- ------=_NextPart_000_024C_01CF2E48.483ACD90 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIy MDE5MzAyMFowIwYJKoZIhvcNAQkEMRYEFJDXc9vuI5qPwUIR++yEnCIDPHjHMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAADjfCoOuFRf6ntXK6xg26dfmZzD8XU6qcGYt5mwa vIfvnTu4cEEDvNXq4gtsVHNt1YlV3JYB1ZSHY7s9YxoGFMsbp+XpAR4qRpxmn2HnDIYLb/v/VozY UPV/UcGMZ3HKCmfNgNDwD4gwxXcEIBox64pi053YOxJzqlRaTbPeZy5LNHtwOQQThGj+i7d4dnMQ +9fqwUC95mhkVWMCYv4VPbogdCYrB66LQ8zUmqbzLvMwYnY/RvrARPHKopQOBn9Vqdbeiy29s9XX MSMj7lfl/+f8ufnrYkMzF0vhga4krDT4dgBHiLM1xc/FQo1Pz2pSbdLgnuN++SLYn9K+3TLz6gAA AAAAAA== ------=_NextPart_000_024C_01CF2E48.483ACD90-- From nobody Thu Feb 20 11:35:36 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CF41A015F for ; Thu, 20 Feb 2014 11:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 QAYBREOZJ-jJ for ; Thu, 20 Feb 2014 11:35:33 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 67BD51A024F for ; Thu, 20 Feb 2014 11:35:25 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta04.westchester.pa.mail.comcast.net with comcast id UgGu1n00516LCl054jbMLg; Thu, 20 Feb 2014 19:35:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id UjbM1n00F3ZTu2S3SjbMXm; Thu, 20 Feb 2014 19:35:21 +0000 Message-ID: <530658F9.4040001@alum.mit.edu> Date: Thu, 20 Feb 2014 14:35:21 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <00C069FD01E0324C9FFCADF539701DB3BBF3175B@sc9-ex2k10mb1.corp.yaanatech.com> <530655DF.6080604@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392924921; bh=ctHvGxRq6kd21X27J0DB59EJa2pdetQCkVqNUoYqsCg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FnN8xOdlDLoqozcmkIpfSsCB2V0nc6p6tEQPwg4MKwb/EvrZcF5m1JyKDy89hBwXD uWpN9Q/pV2mxC8va/31QxW9oq1jbJYjSrqQeCb/zOLJTFli9P29Fm+vtu05SVcDcJu BW+AN+zUp3lwftAHky+bTDGSsXvn1W5Ii7E6l9aXsmNteLbejrNTInNHPV7ME0Psu4 XDDwHW+lT+ZpnAGKFvMuYp24xLdZL27zAcwrayMHz29r4iXBsjrdYL3rGFQBNIse2F j0tPyEUSvb/WbiWL+GlyO84KKL/F9VVo8M6PGsdIxuVlfp7ExovkJmap781k0f4HqG y7v4V9PUa0biA== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/OvL0BFJ9zf1yt7p4U7GJ3kxbBlk Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:35:34 -0000 On 2/20/14 2:25 PM, Oleg Moskalenko wrote: > Obviously, a "link to API" means here "a URL/URI to REST API to QoS". Maybe that is what was intended. If so - if a single REST API is meant, and the only variable is the target - then fine. That wasn't obvious to me. > I am not sure that such web-based API exist. May be, a custom > proprietary implementation can be used. > > But I'd postpone any discussion on that matter. > > > > > On Thu, Feb 20, 2014 at 11:22 AM, Paul Kyzivat > wrote: > > On 2/20/14 2:12 PM, Michael Hammer wrote: > > Perhaps one thing TRAM signaling can return to the client is a > link to > an API for doing QoS control. > > Then whatever QoS control protocol you want to use could be > patched in. > > Might make this a little more future proof. > > > "A link to an API"????? > > AFAIK that doesn't make sense. > > A link that identifies a target and protocol to control QoS makes > some sense to me. But then how do you know the client will support > the protocol you are offering? > > Thanks, > Paul > > > _________________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/__listinfo/tram > > > > > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > From nobody Thu Feb 20 11:53:49 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 784B11A0273 for ; Thu, 20 Feb 2014 11:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 AqqOUprpXzSD for ; Thu, 20 Feb 2014 11:53:46 -0800 (PST) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D44241A0271 for ; Thu, 20 Feb 2014 11:53:45 -0800 (PST) Received: by mail-ve0-f174.google.com with SMTP id pa12so2364208veb.19 for ; Thu, 20 Feb 2014 11:53:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Fh+YoM0/wckBuK/UhsiM63NI2woUYlK1ABn/Zv2+brw=; b=QugsiTy/xIQnmGZcoYmXv3demBH7x71+/n+SZ6fxi1aNxgYYHlhI3Eb5Yw0AaDKAY4 X1jTGk7OZPf49NywZYgNLuDtjGu4OrCKPgsziFcmpa/+YqgkyTqAkvjmUPw9uZhfXj+h sugyPiz6jIi0mnUdhy5MKMUX5LQRzJ3Dmz4VHc5QWpjPUP9bZwGQzxdVT8VWVKlqoy33 xRH25MeNqmIqNkD7whLbqONA0NCZrplaLmhvERIymegMb9E/OlgrQnr5Ra5oAd0xWRfl Lm0HeVEFL6izYOhOWucRfi8hZgnJnP8I5abGUYm5l+/OmKqFn90xej+KCVJjy0LG3FvD fI3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Fh+YoM0/wckBuK/UhsiM63NI2woUYlK1ABn/Zv2+brw=; b=KeHWg7TY/Y41yOGuYPbb1ScUhaywdFvHvqVb3lgyhKt9Psb82GpwcW2jsGJA8lGVlS ICtVkqZeoNoXtnpSEc7hXE8stUdoAJfUyPS0YfD2opH9pczRuJQkuVmC66BnL8CFA5uc xruWcfEXlDt2MMh7ROvy6+MlnXOgRw8LmPGsNZlAl5SVNDiGVj6PvB5Pk5dAjRKITKbB uhqKWSS4L417CTyp9chtDw4i3Ku2TZlVgkYTK/4P8SP2bys0mci5jKZZjIs4J7VJnHUU 7XWdN3ktaxAjSjCaiIx8mtRG8+D5tbfFa5brZzRr0SWhvDnvwiPHp9yMAzaU1XQbwtu8 n6IA== X-Gm-Message-State: ALoCoQlo/Pij89XW+U/aby+amAhIcCO8OBoygrh9AKdrLdbT3NhIwQN+kMxMxLt6YnRthBEIXBbjV523rX+ag5NLXPlQFb8qkYdDJVrVMhvb5AO6Yry2baGHXoYHB9cG8QNM+9wWy06B95AcCbN0eygIkg013XXzp2eOvDXDgrF4TD1sH03TBEEP/tygpNBniNCzMAHoGmVH X-Received: by 10.220.84.193 with SMTP id k1mr2115026vcl.64.1392926021854; Thu, 20 Feb 2014 11:53:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Thu, 20 Feb 2014 11:53:21 -0800 (PST) In-Reply-To: References: <5304D0CA.9020201@viagenie.ca> <5304DF60.7020200@viagenie.ca> <5304E60F.1020807@viagenie.ca> <5304E9AE.5070202@viagenie.ca> <93BEDDC39A54294B9E78C7860516FA4724AA3FB7@AZ-US1EXMB06.global.avaya.com> <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> From: Justin Uberti Date: Thu, 20 Feb 2014 11:53:21 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a11c221c0bb411a04f2dbdc88 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/DIF2Yk4SPRz7GGfcRHMkIKSzm88 Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:53:48 -0000 --001a11c221c0bb411a04f2dbdc88 Content-Type: text/plain; charset=UTF-8 So how should we proceed with this work? Should this be done as part of a 6156-bis, or is this WG planning to come up with a 5766-bis that subsumes 6156? On Thu, Feb 20, 2014 at 9:41 AM, Justin Uberti wrote: > > > > On Thu, Feb 20, 2014 at 9:39 AM, Oleg Moskalenko wrote: > >> >> >> >> On Thu, Feb 20, 2014 at 9:25 AM, Justin Uberti wrote: >> >>> >>> > So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may >>>> expect that attribute... >>>> > >>>> I just noticed that as well. Funny.. >>>> >>>> > So, I reconsider my opinion: let's not use the address-family in the >>>> REFRESH at all, and refresh all relay endpoints regardless of their >>>> protocols. >>>> > >>>> Well it is nice to have in there as the refresh is also used to delete >>>> an allocation. So if you after ICE is completed ends up only using the IPv6 >>>> allocation you can delete the IPv4 allocation. This frees up resources on >>>> the TURN server. >>>> >>> >>> Yeah, that was my thinking as well. If RAF is absent, the refresh >>> applies to all allocations. If the RAF is specified, the specific >>> allocations are refreshed/deleted, or an error if the RAF doesn't match the >>> existing allocations. >>> >> >> I suppose that this is probably the "least intrusive" option - if we want >> to be able to free the resources. But I'd like to clarify the terminology. >> How many allocations we have per TURN session ? I'd suggest to use the term >> "relay endpoints" for the allocated relay sockets but I'd keep term >> "allocation" as a synonym to "TURN session" (and then we have a single >> allocation even if we have two relay endpoints per allocation). >> >> Or we can separate "TURN session" and "allocation" and make the >> "allocation" a synonym to "relay endpoint". We have to agree on a single >> terminology to avoid the confusions. >> >> So, RAF in REFRESH can be: >> >> 1) absent - then it is applicable to all available relay endpoints in the >> session; >> 2) ipv4 - then it is applicable to ipv4 endpoint only and returns 443 if >> ipv4 endpoint does not exist; >> 3) ipv6 - then it is applicable to ipv6 endpoint only and returns 443 if >> ipv6 endpoint does not exist; >> 4) ipv4+ipv6 - then it is applicable to both endpoint only and returns >> 443 if ipv4 OR ipv6 endpoint does not exist; >> >> Honestly, I'd remove 443 requirement and if the endpoint does not exist >> I'd just ignore the request. That would simplify the client code on >> resource cleaning. But that would make the specs not-backward-compatible so >> I suggest keeping the 443 error. >> >> > I think it would be good for the client to know that its REFRESH request > could not be fully handled by the server. Ergo, let's return 443 as > indicated in your list above. > --001a11c221c0bb411a04f2dbdc88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So how should we proceed with this work? Should this be do= ne as part of a 6156-bis, or is this WG planning to come up with a 5766-bis= that subsumes 6156?


On Thu, Feb 20, 2014 at 9:41 AM, Justin Uberti <juberti@google.com>= ; wrote:


=
On Thu, Feb 20, 2014 at 9:39 AM, Oleg Moskal= enko <mom040267@gmail.com> wrote:



On Thu, Feb 20, 2014 at 9:25 AM= , Justin Uberti <juberti@google.com> wrote:

> So, the client MUST NOT use the REQUESTED-ADDRESS, but the server may = expect that attribute...
>
I just noticed that as well. Funny..

> So, I reconsider my opinion: let's not use the address-family in t= he REFRESH at all, and refresh all relay endpoints regardless of their prot= ocols.
>
Well it is nice to have in there as the refresh is also used to delet= e an allocation. So if you after ICE is completed ends up only using the IP= v6 allocation you can delete the IPv4 allocation. This frees up resources o= n the TURN server.

Yeah, that was my thinking as well. = If RAF is absent, the refresh applies to all allocations. If the RAF is spe= cified, the specific allocations are refreshed/deleted, or an error if the = RAF doesn't match the existing allocations.

I suppose tha= t this is probably the "least intrusive" option - if we want to b= e able to free the resources. But I'd like to clarify the terminology. = How many allocations we have per TURN session ? I'd suggest to use the = term "relay endpoints" for the allocated relay sockets but I'= d keep term "allocation" as a synonym to "TURN session"= (and then we have a single allocation even if we have two relay endpoints = per allocation).

Or we can separate "TURN session&= quot; and "allocation" and make the "allocation" a syno= nym to "relay endpoint". We have to agree on a single terminology= to avoid the confusions.

So, R= AF in REFRESH can be:

1) absent - t= hen it is applicable to all available relay endpoints in the session;
2) ipv4 - then it is applicable to ipv4 endpoint= only and returns 443 if ipv4 endpoint does not exist;
3) ipv6 - then it= is applicable to ipv6 endpoint only and returns 443 if ipv6 endpoint does = not exist;
4) ipv4+ipv6 - then it is applicable to both endpoint only and returns 443 = if ipv4 OR ipv6 endpoint does not exist;

Honestly, I'd remove 443 requirement and if the endpoint does not= exist I'd just ignore the request. That would simplify the client code= on resource cleaning. But that would make the specs not-backward-compatibl= e so I suggest keeping the 443 error.


I think it would be good for the client to know th= at its REFRESH request could not be fully handled by the server. Ergo, let&= #39;s return 443 as indicated in your list above.

--001a11c221c0bb411a04f2dbdc88-- From nobody Thu Feb 20 12:11:51 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E411A02C2 for ; Thu, 20 Feb 2014 12:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 R2I_citX6CC5 for ; Thu, 20 Feb 2014 12:11:47 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 285E11A0270 for ; Thu, 20 Feb 2014 12:11:47 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2C6C6403C2; Thu, 20 Feb 2014 15:11:43 -0500 (EST) Message-ID: <5306617E.2050306@viagenie.ca> Date: Thu, 20 Feb 2014 15:11:42 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti , Oleg Moskalenko References: <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Csahs_V6IS7qLr-WikzZeha8Ac8 Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 20:11:49 -0000 Le 2014-02-20 14:53, Justin Uberti a écrit : > So how should we proceed with this work? Should this be done as part of > a 6156-bis, or is this WG planning to come up with a 5766-bis that > subsumes 6156? Up to the WG to decide, IMHO. What's your opinion? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Feb 20 12:55:09 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 457DB1A02D4 for ; Thu, 20 Feb 2014 12:55:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 2luUEDLikSup for ; Thu, 20 Feb 2014 12:55:05 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id CABCB1A028B for ; Thu, 20 Feb 2014 12:55:05 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id bj1so2421464pad.25 for ; Thu, 20 Feb 2014 12:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j8uLeC36wagm1dt9Y16pUfugBz56YvnFWNal48+QdT4=; b=pt6nyELaikyBD/mKMcYJ9pJqpK2of2SyO+3DYuohELd31ElRCn3mtEENFAl5tvbwkN RLS34C6qTbbrhC0RSJrfaBATyu+1ijbao+dKRok/YLZT5WPOavOsQxwCRxfvbrEpGSip LBuCOP0oQqTsaFWoZO+vsZ4V66URkDyiyP009oCcdA83m/SpFcpU9hIFQ9qqKDhvwgnL 83oyKp7svsb0HKvCiRDQzPAY9avr0po+M0BEaqPWWFap2bUhun+ZG06DNeBWqYxik1zu V4IPT2VcZ0ljhtaYqXxLpHUEbapQ9yw836o4pSH9FndCofz3CbVlnFwKfjFTRAaqD4lu ITPg== MIME-Version: 1.0 X-Received: by 10.68.170.66 with SMTP id ak2mr4495002pbc.5.1392929702303; Thu, 20 Feb 2014 12:55:02 -0800 (PST) Received: by 10.68.147.131 with HTTP; Thu, 20 Feb 2014 12:55:02 -0800 (PST) In-Reply-To: <5306617E.2050306@viagenie.ca> References: <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> <5306617E.2050306@viagenie.ca> Date: Thu, 20 Feb 2014 12:55:02 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=047d7b86d55c1a62ce04f2dcb8dc Archived-At: http://mailarchive.ietf.org/arch/msg/tram/75vYoYEg5kNfJeh_KxexlzAmW1U Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 20:55:07 -0000 --047d7b86d55c1a62ce04f2dcb8dc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Of course that's up to WG. My personal opinion is that because IPv6 is very deeply integrated into the core TURN functionality (by RFC 6156), then may be the new RFC5766-bis has to include IPv6 additions with all new updates. So I'd include it into 5766-bis. Oleg On Thu, Feb 20, 2014 at 12:11 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-02-20 14:53, Justin Uberti a =E9crit : > > So how should we proceed with this work? Should this be done as part of > > a 6156-bis, or is this WG planning to come up with a 5766-bis that > > subsumes 6156? > > Up to the WG to decide, IMHO. > > What's your opinion? > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > --047d7b86d55c1a62ce04f2dcb8dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Of course that's up to WG.

My p= ersonal opinion is that because IPv6 is very deeply integrated into the cor= e TURN functionality (by RFC 6156), then may be the new RFC5766-bis has to = include IPv6 additions with all new updates. So I'd include it into 576= 6-bis.

Oleg


On Thu,= Feb 20, 2014 at 12:11 PM, Simon Perreault <simon.perreault@viag= enie.ca> wrote:
Le 2014-02-20 14:53, Justin Uberti a =E9crit= :
> So how should we proceed with this work? Should this= be done as part of
> a 6156-bis, or is this WG planning to come up with a 5766-bis that
> subsumes 6156?

Up to the WG to decide, IMHO.

What's your opinion?

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

--047d7b86d55c1a62ce04f2dcb8dc-- From nobody Thu Feb 20 13:19:24 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97041A02F2 for ; Thu, 20 Feb 2014 13:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 TTOjarWvx77t for ; Thu, 20 Feb 2014 13:19:21 -0800 (PST) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 25A191A0308 for ; Thu, 20 Feb 2014 13:19:18 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id jw12so2401565veb.40 for ; Thu, 20 Feb 2014 13:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=THMAnVd/fDb6ILz3wjq2RTA7eIvxQkNgLGzmsp7HhXE=; b=TyN/h0HRBmaykiElhrMveXMZAP+olsfKq0LaBtPvTkXO9VBMUsk67ftQhnRqNVVZRK EbcMAeg9QY6XoDfbJI53xAm3JPWW+fYxff2Z/RwmFygAoJwFlTbPercqF8Xy6EWR/4Zr fU1JrUQCWq6yT9ydOsgBmzeEb7U0arqxc7dsv5sEjTXgAE9PY9gOdAl0FNF3gvSUSAoC dRPsBUDVwsezmhkWy+MKOZ4WJ1jKDUBapyLjEW55Jko1bldXTUSWST7sOQ6EsPcm1+Cv SpqEakqDzsDIYzNn0eIUhhNSyXxw7G+ZRU/f8cutGwTxhiupaHxB+owkuOINCGa1jjaQ JGcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=THMAnVd/fDb6ILz3wjq2RTA7eIvxQkNgLGzmsp7HhXE=; b=P9JpwMzmUjMKXb2cUlIthJhMHOrB83xHVo/fozElCB2AwB1G03MvMhKSCLFFNSlL8B lvepSH5EQ0Fo2NR292MQ0+dJ9yWdK+bja7DiUiqxUfcbdOyeMY1l4OOHfAZMLC97Vn7F Fj9+OHAqSC+E8WeQS/M1rItCInRUp0yitSHN4tp3HDzT0q29inGwXEl/1pcaJlSST9bm FQqYqJA8M9O+qt59nVjtCSexxfKLqM4tavnbOGvq1pg6hpu/srDCFEJmtFEVmYTFuD81 tEN4aA5N84SbNoWAxMZ52Pb+LXhqgJpjYlwUOxR2ou6V1MrDtc8aypjejn6P2oFPIWjc uULQ== X-Gm-Message-State: ALoCoQlFIsPQsv45Fzighj+UojlEvA3ZLw7f/KyveumdKQ0SwjH2IU9/NjMeqAHMfm/NCqL17Po80HcXsWtyyhrasKeMqF+ZydhBiWSPEKlO4QxuHr3uMaY8G2LVQXaaCqeej6uXWmBb6P5LC67SuT5MflwvOqVUqNPKqOWj6weHchAWI8b3cLLnucCb23Qpxq+SL4Cr64Yh X-Received: by 10.220.81.71 with SMTP id w7mr2284806vck.71.1392931155135; Thu, 20 Feb 2014 13:19:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Thu, 20 Feb 2014 13:18:54 -0800 (PST) In-Reply-To: References: <53050EBC.3040903@viagenie.ca> <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> <5306617E.2050306@viagenie.ca> From: Justin Uberti Date: Thu, 20 Feb 2014 13:18:54 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=001a1133d54eb2f5b704f2dd0ed1 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Am24PbCULrvADBj8Gmw2je37Sws Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 21:19:23 -0000 --001a1133d54eb2f5b704f2dd0ed1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The downside of doing 6156-bis is that we now have two documents to produce. The upside is that the changes can be much more modest, rather than trying to stuff all of 6156 into 5766-bis. If it turns out that the changes to 5766-bis are small, I would advocate doing a separate 6156-bis document. If we end up doing more major surgery, I think we should probably take the opportunity to produce a combined document. On Thu, Feb 20, 2014 at 12:55 PM, Oleg Moskalenko wrot= e: > Of course that's up to WG. > > My personal opinion is that because IPv6 is very deeply integrated into > the core TURN functionality (by RFC 6156), then may be the new RFC5766-bi= s > has to include IPv6 additions with all new updates. So I'd include it int= o > 5766-bis. > > Oleg > > > On Thu, Feb 20, 2014 at 12:11 PM, Simon Perreault < > simon.perreault@viagenie.ca> wrote: > >> Le 2014-02-20 14:53, Justin Uberti a =C3=A9crit : >> > So how should we proceed with this work? Should this be done as part o= f >> > a 6156-bis, or is this WG planning to come up with a 5766-bis that >> > subsumes 6156? >> >> Up to the WG to decide, IMHO. >> >> What's your opinion? >> >> Simon >> -- >> DTN made easy, lean, and smart --> http://postellation.viagenie.ca >> NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >> STUN/TURN server --> http://numb.viagenie.ca >> > > --001a1133d54eb2f5b704f2dd0ed1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The downside of doing 6156-bis is that we now have two doc= uments to produce. The upside is that the changes can be much more modest, = rather than trying to stuff all of 6156 into 5766-bis.

If it turns out that the changes to 5766-bis are small, I would advocate do= ing a separate 6156-bis document. If we end up doing more major surgery, I = think we should probably take the opportunity to produce a combined documen= t.


On Thu,= Feb 20, 2014 at 12:55 PM, Oleg Moskalenko <mom040267@gmail.com><= /span> wrote:
Of course that= 9;s up to WG.

My personal opinion is that because IPv6 is very= deeply integrated into the core TURN functionality (by RFC 6156), then may= be the new RFC5766-bis has to include IPv6 additions with all new updates.= So I'd include it into 5766-bis.

Oleg=


On Thu, Feb 20, 2014 at 12:1= 1 PM, Simon Perreault <simon.perreault@viagenie.ca> wrote:
Le 2014-02-20 14:53, Justin Uberti a =C3=A9c= rit :
> So how should we proceed with this work? Should this be done as p= art of
> a 6156-bis, or is this WG planning to come up with a 5766-bis that
> subsumes 6156?

Up to the WG to decide, IMHO.

What's your opinion?

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://numb.viagenie.ca=


--001a1133d54eb2f5b704f2dd0ed1-- From nobody Thu Feb 20 13:21:35 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA0B1A0306 for ; Thu, 20 Feb 2014 13:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 O6b9MCsMZHpV for ; Thu, 20 Feb 2014 13:21:32 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 431C51A02FB for ; Thu, 20 Feb 2014 13:21:32 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 480E2403C2; Thu, 20 Feb 2014 16:21:28 -0500 (EST) Message-ID: <530671D7.5090200@viagenie.ca> Date: Thu, 20 Feb 2014 16:21:27 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Justin Uberti , Oleg Moskalenko References: <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> <5306617E.2050306@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Hh6uT6Lt-xUPeyKRdww8MT-QF-c Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 21:21:34 -0000 Le 2014-02-20 16:18, Justin Uberti a écrit : > The downside of doing 6156-bis is that we now have two documents to > produce. The upside is that the changes can be much more modest, rather > than trying to stuff all of 6156 into 5766-bis. > > If it turns out that the changes to 5766-bis are small, I would advocate > doing a separate 6156-bis document. If we end up doing more major > surgery, I think we should probably take the opportunity to produce a > combined document. IMHO, it doesn't make sense to write an IPv4-only RFC in 2014. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Feb 20 13:29:35 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AAD1A0313 for ; Thu, 20 Feb 2014 13:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 jNV5IhQBpgs9 for ; Thu, 20 Feb 2014 13:29:32 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 223951A02E6 for ; Thu, 20 Feb 2014 13:29:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1136; q=dns/txt; s=iport; t=1392931768; x=1394141368; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gmr40qsRr5WMoIfDRw8ogy9c9FZTLxTDulrALQrwdvw=; b=R1sqXb8BgVglNCExES47dpQEJ7EN60UM9mlfS9NyRcnr45JjbGhlrZcV wZnk4Zj/q8y0ge/dbrTJ1aOqWGfsPkcNV4LtpqVSVY3OLIQwjJQM6YbkN fDoCyBMfxwvo5Jpz8JolDrpshW3OM1i+08xkCeVrWRUeEPjhmwXylLsWh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJ9yBlOtJXG9/2dsb2JhbABZgwY4V8APgREWdIIlAQEBAwEBAQEkRwsFCwIBCEYnCyUCBA4Fh30IDc0+F44xMweDJIEUBIkQjyCBMpBygy2CKg X-IronPort-AV: E=Sophos;i="4.97,514,1389744000"; d="scan'208";a="22000112" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-1.cisco.com with ESMTP; 20 Feb 2014 21:29:28 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1KLTSdp032572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Feb 2014 21:29:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 20 Feb 2014 15:29:28 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Simon Perreault Thread-Topic: [tram] IPv4 and IPv6 allocations Thread-Index: AQHPLn4Lo8GKxGe4F0avj/XqwscgO5q/ClAAgAAAtoCAAAI7AA== Date: Thu, 20 Feb 2014 21:29:28 +0000 Message-ID: <313B03D5-D8D2-406F-9A51-300FC60B2705@cisco.com> References: <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> <5306617E.2050306@viagenie.ca> <530671D7.5090200@viagenie.ca> In-Reply-To: <530671D7.5090200@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.52] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3923CEDF50BC604E92BD4996DAC5B8F7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/oyv-Y4Tgw3F_EaNa_yRYMvj9eFk Cc: Oleg Moskalenko , "tram@ietf.org" , "Pal Martinsen \(palmarti\)" , Justin Uberti Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 21:29:34 -0000 On Feb 20, 2014, at 4:21 PM, Simon Perreault = wrote: > Le 2014-02-20 16:18, Justin Uberti a =E9crit : >> The downside of doing 6156-bis is that we now have two documents to >> produce. The upside is that the changes can be much more modest, rather >> than trying to stuff all of 6156 into 5766-bis. >>=20 >> If it turns out that the changes to 5766-bis are small, I would advocate >> doing a separate 6156-bis document. If we end up doing more major >> surgery, I think we should probably take the opportunity to produce a >> combined document. >=20 > >=20 > IMHO, it doesn't make sense to write an IPv4-only RFC in 2014. >=20 > Gonzalo >=20 > Simon > --=20 > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram From nobody Thu Feb 20 13:32:24 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62851A0150 for ; Thu, 20 Feb 2014 13:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 0XfcBUW9sV_o for ; Thu, 20 Feb 2014 13:32:21 -0800 (PST) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 83E571A02DD for ; Thu, 20 Feb 2014 13:32:21 -0800 (PST) Received: by mail-pd0-f174.google.com with SMTP id z10so2339509pdj.5 for ; Thu, 20 Feb 2014 13:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t7flPxmfZL8V/yYkP5AlwY5o4hdC4M4EGL8c0YPprRM=; b=h4G4p7WygpNg3ThAQDvC6Bqr1uTuyHNiCktq5WCT9DK8pvuxMrk1K6VH/TsbwjBWFP vEpJkeSNx5nNtex9RlqPlCTwjG6R6DOjQu//nKyXdWBm501stJ8wG4TWlrC/b5zCja06 T4eNwQ8hy8gjp+dVMdUKtNrm7gP76pE1Ork+GRHaE6wKmHSB/m6TkrTWxMa7qS3mhZue ED+p9yMiiKATW6PS5NTVTpujT/lzX3AbKNBU6Pvoz4hPadsZmWiYGKOyQGEq2qrunF5F 00LOoUTptZsy9zZFz1kcRq8A4lS5qlGUa1dAEWYBVE2rixXOe9CpmcceSvso+wAn+RVN BB0w== MIME-Version: 1.0 X-Received: by 10.68.212.161 with SMTP id nl1mr4691553pbc.142.1392931937973; Thu, 20 Feb 2014 13:32:17 -0800 (PST) Received: by 10.68.147.131 with HTTP; Thu, 20 Feb 2014 13:32:17 -0800 (PST) In-Reply-To: <530671D7.5090200@viagenie.ca> References: <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> <5306617E.2050306@viagenie.ca> <530671D7.5090200@viagenie.ca> Date: Thu, 20 Feb 2014 13:32:17 -0800 Message-ID: From: Oleg Moskalenko To: Simon Perreault Content-Type: multipart/alternative; boundary=e89a8ff1c89c5bfb5f04f2dd3d76 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/-YNG3epaX7EAqWd8fQlUpUR4W1M Cc: "Pal Martinsen \(palmarti\)" , "tram@ietf.org" , Justin Uberti Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 21:32:23 -0000 --e89a8ff1c89c5bfb5f04f2dd3d76 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 20, 2014 at 1:21 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > > > IMHO, it doesn't make sense to write an IPv4-only RFC in 2014. > > I agree with that. --e89a8ff1c89c5bfb5f04f2dd3d76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 20, 2014 at 1:21 PM, Simon Perreault = <simon.= perreault@viagenie.ca> wrote:


IMHO, it doesn't make sense to write an IPv4-only RFC in 2014.


I agree with that.
=A0
<= br>
--e89a8ff1c89c5bfb5f04f2dd3d76-- From nobody Thu Feb 20 14:24:15 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6FF1A0324 for ; Thu, 20 Feb 2014 14:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 FOE1AzO2rIXp for ; Thu, 20 Feb 2014 14:24:11 -0800 (PST) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E99021A031E for ; Thu, 20 Feb 2014 14:24:10 -0800 (PST) Received: by mail-vc0-f181.google.com with SMTP id ie18so2471712vcb.26 for ; Thu, 20 Feb 2014 14:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ejeGXcT0D3uVZ7AqZUHkcaIZloQaLTCLM+mojD/L/B0=; b=mCo27KBoNONQnBuPThp80QhFbVHkjr2rjYt/jZiggiUG02pD1x78dqJnERMLP+FeLs tjBqKt5ZuDbAsCdGcBv1MkLhTjQ3eCjyppEGCjaWc+3rzYJjlFaAE1Nhm9NtYU0wzoce 3RitIBA+OJUth23rO+LsfBTZUxtwjNWLs4ACxPXmvQ3trwEjBRlcnkPU1i3pkBmyWfnQ rKVouQhnmfcCS8VdnO4SKtjSTlLnoIrimI7WyepYPanQNUdmE7hs0GlMrqr5Yv9UR12W +tk1XZszcYHhqFwmvtvn8E1M4fCSmylw3KVqt125Adx+8IzMD0ASViBQqxI/P1ehNCjl XIsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ejeGXcT0D3uVZ7AqZUHkcaIZloQaLTCLM+mojD/L/B0=; b=ayY7b4vh9UgzcOIMkhth0/jf698lStxg71O87iHamg+YtukiNn+6NjDB7tHuvTElyR EsspqFoqIZX40P0QpngYpM1n4KtCC6tvEnd3iAwuqoHJwqkhsU+Z0pMiLunQ66nxs/8e 2ooo+k1Ifp8yx8EbIIeY/YJYsRLK9J99YgkqGvvGsQLvJ1SXghvyub4Pqyjw4hH4k6RZ qEnR7zQ/S6z/6l943Hm9h3ZqjykD3UGoeVZI8ccf08rm3+0XkN12Lsib60jzd9RFQZYN em7uqPuEGmW0s98Pf9zoXL9CUJyDQFEvzhyAQ/Y6jPjYt0Y8QxeYSYbVwnB674bdNg3W BNLg== X-Gm-Message-State: ALoCoQkKeo1KR+c7Gn/uEaYW1lUJ21jMXMOLugnURf3YwDJMHsigemnwp6qpmjg710Ou8cXGVv+3Gp26KKtbFWpmZA/lPEwZ4i1fABhR+9NOlxQbjSXduVeaN+hzjZWVgp+AhBxvBo6kGLBOMtDvN7wYHu98jp6eoKuo3uXYxn8kdNSbHGhqKn1wGM0bkxYdM+5WWVDiu+ZY X-Received: by 10.52.156.232 with SMTP id wh8mr2103647vdb.23.1392935047035; Thu, 20 Feb 2014 14:24:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Thu, 20 Feb 2014 14:23:45 -0800 (PST) In-Reply-To: References: <74E1C6E2-E63E-4AB0-B085-30350A6B467C@gmail.com> <530513CF.7000502@viagenie.ca> <311FB4A0-7671-4EA2-A0B5-10F035AFEFA0@gmail.com> <5B62580E-890C-4034-B3CA-6530798F9E31@cisco.com> <5306617E.2050306@viagenie.ca> <530671D7.5090200@viagenie.ca> From: Justin Uberti Date: Thu, 20 Feb 2014 14:23:45 -0800 Message-ID: To: Oleg Moskalenko Content-Type: multipart/alternative; boundary=089e01633aa8acaa5504f2ddf6b7 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/RMl6K6l-dUcnFOr-imiHNRBC7Ac Cc: Simon Perreault , "Pal Martinsen \(palmarti\)" , "tram@ietf.org" Subject: Re: [tram] IPv4 and IPv6 allocations X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 22:24:12 -0000 --089e01633aa8acaa5504f2ddf6b7 Content-Type: text/plain; charset=UTF-8 OK. Onto the 5766-bis list it goes... On Thu, Feb 20, 2014 at 1:32 PM, Oleg Moskalenko wrote: > > > > On Thu, Feb 20, 2014 at 1:21 PM, Simon Perreault < > simon.perreault@viagenie.ca> wrote: > >> >> >> IMHO, it doesn't make sense to write an IPv4-only RFC in 2014. >> >> > I agree with that. > > > --089e01633aa8acaa5504f2ddf6b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK. Onto the 5766-bis list it goes...


On Thu, Feb 20, 2014 at 1:32= PM, Oleg Moskalenko <mom040267@gmail.com> wrote:



On Thu, Feb 20, 2014= at 1:21 PM, Simon Perreault <simon.perreault@viagenie.ca>= ; wrote:


IMHO, it doesn't make sense to write an IPv4-only RFC in 2014.


I agree with that.
=C2=A0


--089e01633aa8acaa5504f2ddf6b7-- From nobody Fri Feb 21 01:37:19 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64961A04FF for ; Fri, 21 Feb 2014 01:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 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, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 mvCY6lvImGY4 for ; Fri, 21 Feb 2014 01:37:14 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 877C31A0049 for ; Fri, 21 Feb 2014 01:37:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12739; q=dns/txt; s=iport; t=1392975431; x=1394185031; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FzJeO4ti349zCd+kW2C3qJW9CvQ8F42vrN2GZVDEUGo=; b=StI2ep7gQQVA0fKpl4i94XE4SqEVuvBqE7oZr158Thjh+jiQiYFXMbu2 1+qyMx98BPEGFCmMmzSMuJ7/IfPzS+F1nIPZe7rC0zb+kR7RmAD6QPGU+ AMHdgIjtwc31QrJoMP+TVuWynZokYySioViXcyC+06kaOHRVHsUs46FB5 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4GANQdB1OtJV2Y/2dsb2JhbABWA4JCRDtXt1+IWIEQFnSCJQEBAQQBAQFkBwsQAgEIEQQBASgHIQYLFAkIAgQOBYdxAxENxHMNh1wXjE+CBQwEBgERgxOBFASJEI03gW2BMosuhUeDLYIq X-IronPort-AV: E=Sophos; i="4.97,517,1389744000"; d="scan'208,217"; a="22129269" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 21 Feb 2014 09:37:10 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1L9bA9e026830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 09:37:10 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 03:37:10 -0600 From: "Pal Martinsen (palmarti)" To: "tram@ietf.org" Thread-Topic: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: AQHPLuh9NKjjBBbIvkuPAKYD51v6LQ== Date: Fri, 21 Feb 2014 09:37:09 +0000 Message-ID: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.70] Content-Type: multipart/alternative; boundary="_000_B7FA26296D484569BB6256395C3EE4BCciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Oyljy8JUGect8ofolFo0GxsRUeM Cc: Karl Stahl , Oleg Moskalenko , Alan Johnston , "Yoakum, John H \(John\)" Subject: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 09:37:18 -0000 --_000_B7FA26296D484569BB6256395C3EE4BCciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I agree the full QoS discussion should _not_ happen in TRAM. If you are int= erested in helping out in that area I suggest you looking into the AEON mai= ling list at: https://www.ietf.org/mailman/listinfo/aeon . They are current= ly working on a problem-statement draft and a use-case draft, any input to = those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-u= se-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-= 00). That said, STUN have a few nice characteristics that makes it a perfect can= didate for transporting some of the QoS information. IMHO that would be ex= tending the STUN spec and should be within the TRAM charter. The main goal= of draft-martinsen-tram-discuss was to show how already existing QoS mecha= nisms could be transported with STUN to provide more value, and to start th= e discussion if TRAM is the appropriate place to have those on the wire for= mat discussions. .-. P=E5l-Erik On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) > wrote: +1 I fully agree with the comments that QOS should be a low priority for the i= nitial focus of the TRAM efforts. There are other groups doing QOS work an= d frankly I engage in WebRTC multimedia interactions daily over the Interne= t, enterprise VPNs, and various combinations and seldom suffer egregious qu= ality issues. I am more concerned about carriers doing things to regulate = or degrade WebRTC flows than a failure of existing Internet mechanisms to e= nable them. Significant focus on QOS before we better enable TURN to be easily used in = a browser environment taking advantage or normal web characteristics (as op= posed to historic telephony constructs) would seem to be highly distracting= at this point. Cheers, John AVAYA 1.919.425.8446 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.t= xt On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston > wrote: Personally, I am not sure how much QoS is actually in scope for TRAM. Have = you been following RMCAT where congestion avoidance for RTP is being develo= ped? I see some overlap in your goals and the goals of that work. - I'd concentrate on the TURN application-level functionality, for now, and I= 'd leave QoS for the future discussions. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_B7FA26296D484569BB6256395C3EE4BCciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I agree the full QoS discussion should _not_ happen in TRAM. If you ar= e interested in helping out in that area I suggest you looking into the AEO= N mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case d= raft, any input to those would be very helpful. (http://tools.ietf.org/html/draft= -eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel= -aeon-problem-statement-00).

That said, STUN have a few nice characteristics that makes it a perfec= t candidate for transporting some of the QoS information.  IMHO that w= ould be extending the STUN spec and should be within the TRAM charter. &nbs= p;The main goal of draft-martinsen-tram-discuss was to show how already existing QoS mechanisms could be transported with = STUN to provide more value, and to start the discussion if TRAM is the appr= opriate place to have those on the wire format discussions.

.-.
P=E5l-Erik






On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <yoakum@avaya.com> wrote:

+1
I fully agree with the comments that QOS should be a low p= riority for the initial focus of the TRAM efforts.  There are other gr= oups doing QOS work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs= , and various combinations and seldom suffer egregious quality issues. = ; I am more concerned about carriers doing things to regulate or degrade We= bRTC flows than a failure of existing Internet mechanisms to enable them.
 
Significant focus on QOS before we better enable TURN to b= e easily used in a browser environment taking advantage or normal web chara= cteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point.
 
 
Cheers,
John
AVAYA
1.919.425.8446=
 
From:<= /span> tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moska= lenko
Sent: Thursday, Fe= bruary 20, 2014 12:43 PM
To: Alan Johnston<= br> Cc: Karl Stahl; tram@ietf.org
Subject: Re: [tram= ] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
 
 

 

On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:
 
 
 
Personally, I am not sure how much QoS is actually in scope for TRAM. Have = you been following RMCAT where congestion avoidance for RTP is being develo= ped?  I see some overlap in your goals and the goals of that work.
-<= /span>
 
 

I'd concentrate on the TURN application-level functionality, for now, and I= 'd leave QoS for the future discussions.

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

--_000_B7FA26296D484569BB6256395C3EE4BCciscocom_-- From nobody Fri Feb 21 09:19:45 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAE71A02D0; Fri, 21 Feb 2014 09:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 fuwC5I7HZTnr; Fri, 21 Feb 2014 09:19:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA13E1A04C6; Fri, 21 Feb 2014 09:19:40 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140221171940.2127.98041.idtracker@ietfa.amsl.com> Date: Fri, 21 Feb 2014 09:19:40 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/J-lstSloT1VfKZkFYHS6HT1E2WA Cc: tram WG Subject: [tram] WG Action: Formed TURN Revised and Modernized (tram) X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:19:44 -0000 A new IETF working group has been formed in the Transport Area. For additional information please contact the Area Directors or the WG Chairs. TURN Revised and Modernized (tram) ------------------------------------------------ Current Status: Proposed WG Chairs: Gonzalo Camarillo Simon Perreault Assigned Area Director: Spencer Dawkins Mailing list Address: tram@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tram Archive: http://www.ietf.org/mail-archive/web/tram/current/maillist.html Charter: Traversal Using Relays around NAT (TURN) was published as RFC 5766 in April 2010. Until recently the protocol had seen rather limited deployment. This is largely because its primary use case is as one of the NAT traversal methods of the Interactive Connectivity Establishment (ICE) framework (RFC 5245), and ICE itself was slow to achieve widespread adoption, as other mechanisms were already being used by the VoIP industry. This situation has changed drastically as ICE, and consequently TURN, are mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web. Together with the arrival of WebRTC, there is a renewed interest in TURN and ICE, as evidenced by recent work updating the ICE framework (still in progress), and standardizing the URIs used to access a STUN (RFC 7064) or TURN (RFC 7065) server. The goal of the TRAM Working Group is to consolidate the various initiatives to update TURN and STUN to make them more suitable for the WebRTC environment. The work will include the addition of DTLS as an additional transport, authentication mechanisms, and extensions to TURN and STUN. The Working Group will closely coordinate with the appropriate Working Groups, including RTCWEB, MMUSIC, and HTTPBIS. In developing upgrades to TURN, the group will consider the passive monitoring risks introduced by the centralization of call traffic through a TURN server. When such risks arise, they will recommend appropriate mitigations. For example, a mechanism for directing traffic to a TURN server other than one configured by the application could be used to direct calls through a TURN server configured to do monitoring. When such a mechanism is used, it is important that the endpoints to the call apply end-to-end encryption and authentication to ensure that they are protected from the TURN server. Milestones: Jul 2014 - Send draft adding DTLS as a transport for STUN/TURN to IESG Jul 2014 - Send analysis of problems with current TURN authentication to IESG Sep 2014 - Send new proposed standard TURN server discovery mechanism for enterprises and ISPs to IESG Nov 2014 - Send new proposed standard TURN authentication mechanism(s) to IESG Feb 2015 - Send STUN-bis draft to IESG Feb 2015 - Send TURN-bis draft to IESG From nobody Fri Feb 21 09:59:02 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA441A025E for ; Fri, 21 Feb 2014 09:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 JFrZpM-4M6x0 for ; Fri, 21 Feb 2014 09:58:56 -0800 (PST) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 25C581A0225 for ; Fri, 21 Feb 2014 09:58:55 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id f8so1107840wiw.3 for ; Fri, 21 Feb 2014 09:58:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=duLiTQp+t8+Kn+ObNw5YCLQN4Nm5IUTXbKVaAeTcbGQ=; b=d1vO20/39f7tB1BfG5tLh/N21I2skorzModPVFoT0jd8+LeiHfbeR8yFF/+8Eit5CU GUUxNjgheFWhJHkXRdg5cJ5dtFp5+gTNANT/YvgY3g2AlutjNDscdPYeTPRdS69mw0FN 7W7F9XmIqcKm6HBz6haJWLokHB4A9ml8I93Z9Jxc9PVt9Yin7YjArPB2iBySMeP/qY2e 6ppSyyWyDNtsNdLe46u8M64Yr2Uo9chr5njZSYh3BO54hT7B2UtYpEafs5CTzimEAujw Kc5tMZbenNnhFY95EPIGsYFK001ztPDQMN1AJTPBL4EAJQVPgSFDeOvHIRoN9cmfwFYG bRPA== MIME-Version: 1.0 X-Received: by 10.194.185.165 with SMTP id fd5mr8007481wjc.95.1393005531748; Fri, 21 Feb 2014 09:58:51 -0800 (PST) Received: by 10.217.152.10 with HTTP; Fri, 21 Feb 2014 09:58:51 -0800 (PST) In-Reply-To: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> Date: Fri, 21 Feb 2014 11:58:51 -0600 Message-ID: From: Alan Johnston To: "Pal Martinsen (palmarti)" Content-Type: multipart/alternative; boundary=047d7bdc7e2ae3e00904f2ee5f20 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/sVM7qLstyrb043d2B_7vRQ5fbv0 Cc: Karl Stahl , Oleg Moskalenko , "tram@ietf.org" , "Yoakum, John H \(John\)" Subject: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 17:58:59 -0000 --047d7bdc7e2ae3e00904f2ee5f20 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I guess the way I would expect this to progress is for QoS discussions to happen in another working group. Once that other working group came to consensus on an approach, and if that approach required STUN or TURN extensions, then we would discuss mechanisms and possible milestones in TRAM. - Alan - On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) < palmarti@cisco.com> wrote: > Hi, > > I agree the full QoS discussion should _not_ happen in TRAM. If you are > interested in helping out in that area I suggest you looking into the AEO= N > mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are > currently working on a problem-statement draft and a use-case draft, any > input to those would be very helpful. ( > http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, > http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). > > That said, STUN have a few nice characteristics that makes it a perfect > candidate for transporting some of the QoS information. IMHO that would = be > extending the STUN spec and should be within the TRAM charter. The main > goal of draft-martinsen-tram-discuss was to show how already existing QoS > mechanisms could be transported with STUN to provide more value, and to > start the discussion if TRAM is the appropriate place to have those on th= e > wire format discussions. > > .-. > P=E5l-Erik > > > > > > > On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) > wrote: > > +1 > I fully agree with the comments that QOS should be a low priority for > the initial focus of the TRAM efforts. There are other groups doing QOS > work and frankly I engage in WebRTC multimedia interactions daily over th= e > Internet, enterprise VPNs, and various combinations and seldom suffer > egregious quality issues. I am more concerned about carriers doing thing= s > to regulate or degrade WebRTC flows than a failure of existing Internet > mechanisms to enable them. > > Significant focus on QOS before we better enable TURN to be easily used > in a browser environment taking advantage or normal web characteristics (= as > opposed to historic telephony constructs) would seem to be highly > distracting at this point. > > > Cheers, > *John* > > AVAYA > 1.919.425.8446 > > *From:* tram [mailto:tram-bounces@ietf.org ] *On > Behalf Of *Oleg Moskalenko > *Sent:* Thursday, February 20, 2014 12:43 PM > *To:* Alan Johnston > *Cc:* Karl Stahl; tram@ietf.org > *Subject:* Re: [tram] Fwd: I-D Action: > draft-thomson-tram-turn-bandwidth-00.txt > > > > > On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston > wrote: > > > > Personally, I am not sure how much QoS is actually in scope for TRAM. > Have you been following RMCAT where congestion avoidance for RTP is being > developed? I see some overlap in your goals and the goals of that work. > - > > > > I'd concentrate on the TURN application-level functionality, for now, and > I'd leave QoS for the future discussions. > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > > > --047d7bdc7e2ae3e00904f2ee5f20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I guess the way I would expect this to progress is for QoS= discussions to happen in another working group. =A0Once that other working= group came to consensus on an approach, and if that approach required STUN= or TURN extensions, then we would discuss mechanisms and possible mileston= es in TRAM.

- Alan -


On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) = <palmarti@cisco.com> wrote:
Hi,

I agree the full QoS discussion should _not_ happen in TRAM. If you ar= e interested in helping out in that area I suggest you looking into the AEO= N mailing list at:=A0https://www.ietf.org/mailman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case d= raft, any input to those would be very helpful. (http://tools.i= etf.org/html/draft-eckel-aeon-use-cases-01,=A0http:= //tools.ietf.org/html/draft-eckel-aeon-problem-statement-00).

That said, STUN have a few nice characteristics that makes it a perfec= t candidate for transporting some of the QoS information. =A0IMHO that woul= d be extending the STUN spec and should be within the TRAM charter. =A0The = main goal of=A0draft-martinsen-tram-discuss was to show how already existing QoS mechanisms could be transported with = STUN to provide more value, and to start the discussion if TRAM is the appr= opriate place to have those on the wire format discussions.

.-.
P=E5l-Erik






On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <yoakum@avaya.com> wrote:
+1
I fully agree with the comments that QOS should be a low priority f= or the initial focus of the TRAM efforts.=A0 There are other groups doing Q= OS work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs= , and various combinations and seldom suffer egregious quality issues.=A0 I= am more concerned about carriers doing things to regulate or degrade WebRT= C flows than a failure of existing Internet mechanisms to enable them.
=A0
Significant focus on QOS before we better enable TURN to be easily = used in a browser environment taking advantage or normal web characteristic= s (as opposed to historic telephony constructs) would seem to be highly distracting at this point.
=A0
=A0
Chee= rs,
J= ohn
=A0
AVAYA<= /span>
1.919.425.8446
=A0
From:=A0= tram [mai= lto:tram-bounces@ietf.org]=A0On Behalf Of=A0Oleg Moskalenko
Sent:=A0Thursday, February 20, 2014 12:43 PM
To:=A0Alan Johnston
Cc:=A0Karl Stahl; tram@ietf.org
Subject:=A0Re: [tram] Fwd: I-D Action: draft-thomson-tr= am-turn-bandwidth-00.txt
=A0
=A0

=A0

On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:
=A0
=A0
=A0
Personally, I am not sure how much QoS is actually in scope for TRAM. Have = you been following RMCAT where congestion avoidance for RTP is being develo= ped? =A0I see some overlap in your goals and the goals of that work.=
-
=A0
=A0

I'd concentrate on the TURN application-level functionality, for now, a= nd I'd leave QoS for the future discussions.

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram


--047d7bdc7e2ae3e00904f2ee5f20-- From nobody Fri Feb 21 10:33:14 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8C81A051F for ; Fri, 21 Feb 2014 10:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham 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 7WRoMDRlBN6O for ; Fri, 21 Feb 2014 10:33:10 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6EADF1A01ED for ; Fri, 21 Feb 2014 10:33:10 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 35A6140398 for ; Fri, 21 Feb 2014 13:33:06 -0500 (EST) Message-ID: <53079BE1.6010706@viagenie.ca> Date: Fri, 21 Feb 2014 13:33:05 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <5391AB6A-72FD-4DF0-B258-CA38AEB2E722@vidyo.com> <2504152D-287E-44DD-8184-8E68EDB08792@vidyo.com> <392B546F-C992-499D-AF5B-512C56CF35D5@cisco.com> <53050CC8.5090409@viagenie.ca> In-Reply-To: <53050CC8.5090409@viagenie.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/NQGPzyJaq2WB9B29emzR2E-i_uM Subject: Re: [tram] Sharing nonces across allocations - allowed? X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 18:33:13 -0000 Le 2014-02-19 14:58, Simon Perreault a écrit : > Le 2014-02-19 14:56, Gonzalo Salgueiro (gsalguei) a écrit : >> We really should start an issues list (on a wiki or something) > > As soon as we become a real WG (tomorrow?), we will have the IETF tools > at our disposal for that! Done! http://trac.tools.ietf.org/wg/tram/trac/report/1 Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Mon Feb 24 14:10:15 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D56001A02ED; Mon, 24 Feb 2014 14:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 79hHDeNkKP9a; Mon, 24 Feb 2014 14:10:08 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id A3E481A028B; Mon, 24 Feb 2014 14:09:26 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402242309203001; Mon, 24 Feb 2014 23:09:20 +0100 From: "Karl Stahl" To: , "'Magnus Westerlund'" , References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> In-Reply-To: <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> Date: Mon, 24 Feb 2014 23:09:17 +0100 Message-ID: <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04DE_01CF31B5.71AA9500" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7EFbkmQFwvQDChQl+1C3afCRd/RgE7zuMwGiI2FdA= Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/_F1NsB_xprlCsaUpvPSED4oIwSo Cc: 'Harald Alvestrand' , 'Colin Perkins' Subject: [tram] [rtcweb] Payload Types assignments X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 22:10:14 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04DE_01CF31B5.71AA9500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I suggest to the RTCWEB WG that the below from the September and October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC 5285, to = allow: =20 (1) WebRTC applications to directly convey QoS related real-time traffic info to the network at points where RTP flow is directed to by TRAM = Milstone 3, to be used by *any network element implementing any suitable QoS = methods for the particular network* for=20 (2) *all* WebRTC browsers *and* clients, under *all* OSs, and *all* = current and future IP network, to achieve best QoE=20 (3) *without* having to force WebRTC into application specific networks (such as IMS) instead of using the Internet (including OTT). =20 The only further activity required, is to call for ISPs=92 to review = whether the traffic information transferred by RFC 5285 is sufficient for = current and future needs in their network as suggested in below repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Then this could be assigned numbers to have an RFC in place. =20 With TRAM milestone 3 also place,=20 market forces will drive ISPs and browser makers to implement just this, without even having it MUST-established. =20 =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. =20 Please see further emails soon following this one, for details and = history. =20 /Karl =20 =20 Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Karl Stahl Skickat: den 22 oktober 2013 16:37 Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus Westerlund' Kopia: 'Colin Perkins' =C4mne: [rtcweb] [avtext] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 Harald, I mostly agree with the quality requirements of different = real-time traffic that the WebRTC browser/application may use. But rather than = asking the application, let's convey the bandwidth and priority requirements to = the network. Just like with the Payload type (that is hard to squeeze that information into) it must be visible to the network (and not changed by = the network, like diffserv bits are). Such marking must also be available = for incoming traffic, which is especially important in RSVP type of = networks, that has to reserve bandwidth for it. =20 =20 There is actually a good way to show these needs to the network (without using the PT, or diffserv bits, which aren=92t sufficient anyway).=20 =20 Let's use the RTP header extension field that also is visible outside = the encrypted payload. A week ago came http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that outlines the usage of the extension field for classification of traffic! This document does not yet outline what to put in there and how to = encode it though. =20 Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 = discusses other webrtc usages of the RTP header extension in 5.2 (there can be = many header extensions according to RFC 5285) and in 9 there is "WebRTC Use = of RTP: Future Extensions". =20 So, it looks obvious to use the RTP header extension to show the characteristics and bandwidth requirements to the network. It should not introduce any backward incompatibilities either. =20 Such marking is done in every RTP packet so it can be set individually = for each stream and could even be changed during a session (e.g. when = limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies how RTP extension header usage can be negotiated in SDP. I think this could be easily done by the WebRTC browser for "all current and future needs" if properly specified now. =20 I suggest that two parameters (e.g. two bytes each) are encoded into the = RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each quality e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Please note the totally different requirements a diffserv and an RSVP network have to know, so let=92s put all into these bytes. (E.g. a = diffserv network don't need the bandwidth usage, but RSVP reservation networks = (e.g. cable and 3G/4G OTT) do. There one should initially reserve the maximum bandwidth indicated, but can later re-reserve.) =20 /Karl =20 PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94;=20 However that seems to apply to the TURN server allocation request and = would therefore: --- Apply to the whole UDP flow, and could not be set for each stream individually (with different requirements), and --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) However the quality attributes conveyed and their encoding may be considered. =20 This is 2.2.2.19 MS-Service Quality Attribute from=20 http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20 =20 MS-Service Quality Attribute The MS-Service Quality attribute is used to convey information about the data stream that the protocol client is intending to transfer over an allocated port. The protocol client SHOULD<21> include this attribute as part of an Allocate request message. A TURN server SHOULD use the information in this attribute to make decisions about resource = allocation, bandwidth prioritization, and data delivery methods. If the attribute is = not present in the Allocate request message, the TURN server SHOULD assume = that the data stream is audio with best effort delivery. The format of this attribute is as follows...=20 ... The following stream types are supported in this extension. All other = stream types are reserved for future use. =A7 "0x0001": Audio =A7 "0x0002": Video =A7 "0x0003": Supplemental Video =A7 "0x0004": Data Service Quality (2 bytes): The service quality level required by the protocol client for the stream. The following service quality levels are supported in this extension. = All other service quality levels are reserved for future use. =A7 "0x0000": Best effort delivery. =A7 "0x0001": Reliable delivery. =20 =20 -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Harald Alvestrand Skickat: den 8 oktober 2013 13:01 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC = of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 On 10/08/2013 09:17 AM, Karl Stahl wrote: > Hej Magnus, >=20 >> Also, are you really interested in knowing that it is VP9 vs H.264,=20 >> isn't > the questions this is video of this priority that is important? >> I think you need to more carefully consider what are the goals you=20 >> try to > achieve them. >=20 > Actually, my concern is to get an idea of the maximum bandwidth that=20 > could be required for a WebRTC (ICE) setup media flow. Both voice and=20 > video should be prioritized over data (their individual priority is of = > less importance as long as there is sufficient bandwidth for both). =20 You don't know that without knowing what the application is for. In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. =20 >=20 > With diffserv you don=92t need to know the bandwidth requirement, but=20 > with RSVP reservation (like in cable and mobile networks) you need to=20 > know how much to reserve. Voice is like 100's kbit/s, video VP8 or=20 > H.264 is like 3,5 mbps. =20 Again, without knowing the application, you don't know that. The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is completely different from that of a talking head, which is again completely = different from a high-movement scene. =20 >=20 > To add to the complication of codec variants, the video codecs in=20 > question for WebRTC have variable bandwidth, and when there is a poor=20 > connection we see Chrome reducing the video window size to reduce the bandwidth used... >=20 > I think the payload type field at best can reflect a maximum bandwidth = > to initially reserve bandwidth for, and thereafter make new=20 > reservations if the bandwidth changes during the call. So could we=20 > change RTP to show maximum bandwidth instead of payload type in that=20 > field outside the encrypted payload :) ... Or maybe that is not a = joke? =20 I think these ruminations only lead to one conclusion: =20 You can't tell what the needed bandwidth is up front without asking the application. You can't tell what the right priority ranking is without asking the application. =20 If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb ------=_NextPart_000_04DE_01CF31B5.71AA9500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I = suggest to the RTCWEB WG that the below from the September and October = discussions on the relevant [rtcweb] [avtext] = [mmusic] = lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = is introduced into draft-ietf-rtcweb-rtp-usage = fo= r usage of RFC 5285, to allow:

 

(1= ) WebRTC applications to directly convey QoS related real-time traffic = info to the network at points where RTP flow is directed to by TRAM = Milstone 3, to be used by *any network element implementing any = suitable QoS methods for the particular network* for =

(2= ) *all* WebRTC browsers *and* clients, under *all* = OSs, and *all* current and future IP network, to achieve best QoE =

(3= ) *without* ha= ving to force WebRTC into application specific networks (such as IMS) = instead of using the Internet (including OTT).

 

Th= e only further activity required, is to call for ISPs’ to review = whether the traffic information transferred by RFC 5285 is sufficient = for current and future needs in their network as suggested in below = repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip><= o:p>

…two = parameters (e.g. two bytes each) are encoded into the RTP header = extension:

 

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic scale.

 

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type = e.g:

Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. = video streaming), Minimum Delay, Reliable Delivery, Prioritize X, = Variation Y, that could be combined as required to describe the = stream.

 

And with = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

</snip>=

 

Th= en this could be assigned numbers to have an RFC in = place.

 

Wi= th TRAM milestone 3 also place,

ma= rket forces will drive ISPs and browser makers to implement just this, = without even having it MUST-established.

 

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

 

Pl= ease see further emails soon following this one, for details and = history.

 

/K= arl

 

 

Fr=E5n: = rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Karl Stahl
Skickat: den 22 oktober 2013 = 16:37
Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus = Westerlund'
Kopia: 'Colin Perkins'
=C4mne: [rtcweb] = [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

Harald, I mostly agree with the quality requirements of = different real-time traffic that the WebRTC browser/application may use. = But rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it.  

 

There is actually a good way to = show these needs to the network (without using the PT, or diffserv bits, = which aren’t sufficient anyway).

 

Let's use the RTP header = extension field that also is visible outside the encrypted payload. A = week ago came h= ttp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 =  that outlines the usage of the extension field for classification = of traffic! This document does not yet outline what to put in there and = how to encode it though.

 

Today's http:/= /tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other = webrtc usages of the RTP header extension in 5.2 (there can be many = header extensions according to RFC 5285) and in 9 there is "WebRTC = Use of RTP: Future Extensions".

 

So, it looks obvious to use the = RTP header extension to show the characteristics and bandwidth = requirements to the network. It should not introduce any backward = incompatibilities either.

 

Such marking is done in every = RTP packet so it can be set individually for each stream and could even = be changed during a session (e.g. when limiting the bandwidth based on = RTCP feedback). RFC 5286 also specifies how RTP extension header usage = can be negotiated in SDP. I think this could be easily done by the = WebRTC browser for "all current and future needs" if properly = specified now.

 

I suggest that two parameters (e.g. two bytes each) are = encoded into the RTP header extension:

 

A) The maximum bandwidth = requirement: Two bytes could contain everything from some bps for = real-time text to Gbps for future 3D supersize telepresence… on a = logarithmic scale.

 

B) The quality characteristics for the stream, with the = highest bit set to 1, we could allocate a bit each quality = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, = Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable = Delivery, Prioritize X, Variation Y, that could be combined as required = to describe the stream.

 

And with highest bit set to 0, = there could instead be a number for special usage that does not fit the = general description of the individual bits.

 

Please note the totally = different requirements a diffserv and an RSVP network have to know, so = let’s put all into these bytes. (E.g. a diffserv network don't = need the bandwidth usage, but RSVP reservation networks (e.g. cable and = 3G/4G OTT) do. There one should initially reserve the maximum bandwidth = indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft seems = to have done work in this field, defining a proprietary attribute = “MS Service Quality”;

However that = seems to apply to the TURN server allocation request and would = therefore:

--- Apply to = the whole UDP flow, and could not be set for each stream individually = (with different requirements), and

--- Does not = handle the bandwidth requirement for incoming real-time traffic = (required to reserve in RSVP type of networks)

However the = quality attributes conveyed and their encoding may  be = considered.

 

This is 2.2.2.19 MS-Service Quality Attribute from =

http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).asp= x 

 

MS-Service = Quality Attribute

The MS-Service = Quality attribute is used to convey information about the data stream = that the protocol client is intending to transfer over an allocated = port. The protocol client SHOULD<21> include this attribute as = part of an Allocate request message. A TURN server SHOULD use the = information in this attribute to make = decisions about resource allocation, bandwidth prioritization, and data = delivery methods. If the attribute is not present in the Allocate = request message, the TURN server SHOULD assume that the data stream is = audio with best effort delivery. The format of this attribute is as = follows...

...<= span lang=3DEN-US style=3D'color:black'>

The following = stream types are supported in this extension. All other stream types are = reserved for future use.

=A7 = "0x0001&quo= t;: Audio

=A7 = "0x0002&quo= t;: Video

=A7 = "0x0003&quo= t;: Supplemental Video

=A7 = "0x0004&quo= t;: Data

Service Quality = (2 bytes): The service quality level required by the protocol client for = the stream.

The following = service quality levels are supported in this extension. All other = service quality levels are reserved for future use.

=A7 = "0x0000&quo= t;: Best effort delivery.

=A7 = "0x0001&quo= t;: Reliable delivery.

 

 

-----Ursprungligt meddelande-----

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Harald Alvestrand

Skickat: den 8 oktober 2013 13:01

Till: rtcweb@ietf.org

=C4mne: Re: [rtcweb] Payload = Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, Karl = Stahl wrote:

> Hej Magnus,

> 

>> Also, are you really = interested in knowing that it is VP9 vs H.264,

>> = isn't

> the questions this is video of this priority that is = important?

>> I think you need to more carefully consider what = are the goals you

>> try to

> achieve = them.

> 

> Actually, my concern is to = get an idea of the maximum bandwidth that

> could be required for a = WebRTC (ICE) setup media flow. Both voice and

> video should be prioritized = over data (their individual priority is of

> less importance as long as = there is sufficient bandwidth for both).

 

You don't know that without = knowing what the application is for.

In, for instance, a shooter game = with voice backchannels, the movement and event information (data) is = MORE time sensitive than the voice data.

 

> 

> With diffserv you = don’t need to know the bandwidth requirement, but =

> = with RSVP reservation (like in cable and mobile networks) you need to =

> = know how much to reserve. Voice is like 100's kbit/s, video VP8 or =

> = H.264 is like 3,5 mbps.

 

Again, without knowing the = application, you don't know that.

The application could decide to = use QCIF or HD, and the bandwidth variation of screencast (semi-static = with sudden, large changes) is completely different from that of a = talking head, which is again completely different from a high-movement = scene.

 

> 

> To add to the complication = of codec variants, the video codecs in

> question for WebRTC have = variable bandwidth, and when there is a poor

> connection we see Chrome = reducing the video window size to reduce the bandwidth = used...

> 

> I think the payload type = field at best can reflect a maximum bandwidth

> to initially reserve = bandwidth for, and thereafter make new

> reservations if the = bandwidth changes during the call. So could we

> change RTP to show maximum = bandwidth instead of payload type in that

> field outside the encrypted = payload :) ... Or maybe that is not a joke?

 

I think these ruminations only = lead to one conclusion:

 

You can't tell what the needed = bandwidth is up front without asking the = application.

You can't tell what the right priority ranking is without = asking the application.

 

If you need to know the = bandwidth or the priority up front, the application has to tell you. = Anything else is pure heuristics.

 

_______________________________________________

rtcweb mailing = list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb

------=_NextPart_000_04DE_01CF31B5.71AA9500-- From nobody Mon Feb 24 14:22:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932611A02FB; Mon, 24 Feb 2014 14:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 2TdJ8oIFPPuN; Mon, 24 Feb 2014 14:22:26 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 80E061A02F3; Mon, 24 Feb 2014 14:22:25 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402242322233838; Mon, 24 Feb 2014 23:22:23 +0100 From: "Karl Stahl" To: "'Pal Martinsen \(palmarti\)'" , , References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: Date: Mon, 24 Feb 2014 23:22:20 +0100 Message-ID: <04ee01cf31ae$e296d500$a7c47f00$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04EF_01CF31B7.445B3D00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPLuh9NKjjBBbIvkuPAKYD51v6LZrD+kgA Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/nbyGtqEqxH11R6_gfD7dHcvqOv4 Cc: 'Oleg Moskalenko' , 'Alan Johnston' , "'Yoakum, John H \(John\)'" Subject: Re: [tram] [rtcweb] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 22:22:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04EF_01CF31B7.445B3D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi P=E5l, =20 You did not comment nor answer, in response to any of: http://www.ietf.org/mail-archive/web/tram/current/msg00275.html=20 http://www.ietf.org/mail-archive/web/tram/current/msg00273.html=20 whether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the application/browser to transfer relevant real-time traffic information (types and bandwidth) into every RTP package by using the already IETF standardized RTP extension header RCF 5285, which could be used by any current or future Internet (including OTT) network where WebRTC = real-time traffic may flow. It seems to have been standardized already 2008 to = allow such usage. =20 QoS related step C) draft-martinsen-tram-discuss can then be taken out = of TRAM, and step D) (that was never intended to be handled by TRAM anyway) will be handled elsewhere. =20 I have repeated my suggestion to RTCWEB WG from the October discussions = on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage suggesting usage of RFC 5285, where traffic information in RTP packets simply would be filled by any browser under any OS. =20 Without step B), TRAM =93Enforcing the real-time traffic through the offered/discovered TURN servers=94, the real-time traffic may happen = through the IP default gateways often congested by data traffic and QoS = insensitive streaming video and file sharing. Without specific QoS methods at those points, the network raw bandwidth capacity may have to be 10-folded to achieve sufficient QoE when WebRTC usage becomes popular. Methods like DISCUSS addresses such things occurring when STUN instead TURN is used = (by allowing flows into such congestion points), but only provides direct traffic info for outgoing (not incoming) real-time traffic and locally, therefore are not even applicable to reservation type of networks like = Cable Networks and Mobile OTT.=20 =20 That would leave certain network types to investing in raw bandwidth increase, instead of simply borrowing the bandwidth (from much larger = data traffic and QoS insensitive streaming video and file sharing at no = adverse effect) and making that borrowed no-cost bandwidth very valuable for the carriers when delivering to their customers. I know a few of you Cisco guys are among the ones that have been = fighting against the general =93it is all about bandwidth=94 and =93it will go = away with time=94-attitude within IETF work, e.g. see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, but = the pointers given in the current QoS discussion within TRAM:=20 =20 (i) will *not allow* ISP=92s to use already available and currently = deployable quality IP pipes for real-time traffic to also be used for WebRTC = generated real-time traffic. =20 (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. All networks will *also be inhibited* from the = very common and used method of simply providing an extra IP pipe (often = provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) Newer, fiber only type of networks, can still borrow bandwidth at no = extra cost, *by proprietary usage* of RFC 5285 by browsers.=20 =20 (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may has to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes = intermittently are filled, whatever bandwidth is available). =20 Further explainations about QoS methods and their implementation were = given a few days ago in:=20 http://www.ietf.org/mail-archive/web/tram/current/msg00274.html=20 =20 (i), (ii) and (iii) will *seriously delay* usage of telepresence capable = and quality demanding WebRTC (bandwidth being around 30 times higher over = best effort Internet, than telephony over quality managed networks) and will *vastly increase cost* for ISPs to offer WebRTC with good QoE. =20 Below you are giving pointers saying =93They are currently working on a problem-statement draft and a use-case draft, any input to those would = be very helpful.=94 Those are unnecessary, risking leading to (i), (ii) and = (iii) above. =20 So are pointers such as: =93RMCAT where congestion avoidance for RTP is = being developed=94. TRAMs Milestone 3 is for the purpose of directing = real-time traffic where congestion control isn=92t already in place. Using RFC = 5285 available since 2008, to fill traffic information in RTP packets (step = D)) is probably a necessity for most future =93congestion control=94 = discussed. =20 This chicken-and-egg circular also applies to RTCWEB direction of QoS = issues to:=20 http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos=20 focusing on DSCP-mapping without even mentioning RFC 5285 available = since 2008, to fill traffic information in RTP packets where it is a = necessity and will allow:=20 (1) applications to directly convey QoS related real-time traffic info = to the network at points where RTP flow is directed to by TRAM Milstone 3, = to be used by *any network element implementing any suitable QoS methods = for the particular network* for=20 (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks=20 (3) *without* having to be forced into application specific networks = (PSTN, IMS) instead of using the Internet (including OTT). =20 The only activity required, is to call for ISPs=92 review whether the = traffic information transferred by RFC 5285 is sufficient for current and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Then this could be assigned numbers to have the RFC in place. With TRAM milestone 3 also place,=20 market forces will drive ISPs and browser makers to implement just that, without even having it MUST-established. =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. =20 Please see further emails soon following this one, for details and = history. =20 /Karl =20 Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Pal Martinsen = (palmarti) Skickat: den 21 februari 2014 10:37 Till: tram@ietf.org Kopia: Karl Stahl; Oleg Moskalenko; Alan Johnston; Yoakum, John H (John) =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 Hi, =20 I agree the full QoS discussion should _not_ happen in TRAM. If you are interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case draft, any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). =20 That said, STUN have a few nice characteristics that makes it a perfect candidate for transporting some of the QoS information. IMHO that would = be extending the STUN spec and should be within the TRAM charter. The main goal of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and to start the discussion if TRAM is the appropriate place to have those on = the wire format discussions. =20 .-. P=E5l-Erik =20 =20 =20 =20 =20 =20 On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) = wrote: +1 I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts. There are other groups doing QOS = work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs, and various combinations and seldom suffer egregious quality issues. I am more concerned about carriers doing = things to regulate or degrade WebRTC flows than a failure of existing Internet mechanisms to enable them. =20 Significant focus on QOS before we better enable TURN to be easily used = in a browser environment taking advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point. =20 =20 Cheers, John =20 AVAYA 1.919.425.8446 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 =20 =20 On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston < alan.b.johnston@gmail.com> wrote: =20 =20 =20 Personally, I am not sure how much QoS is actually in scope for TRAM. = Have you been following RMCAT where congestion avoidance for RTP is being developed? I see some overlap in your goals and the goals of that work. - =20 =20 I'd concentrate on the TURN application-level functionality, for now, = and I'd leave QoS for the future discussions. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 ------=_NextPart_000_04EF_01CF31B7.445B3D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= P=E5l,

 

Yo= u did not comment nor answer, in response to any = of:

= http://www.ietf.org/mail-archive/web/tram/current/msg00275.html =

= http://www.ietf.org/mail-archive/web/tram/current/msg00273.html =

wh= ether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the = application/browser to transfer relevant real-time traffic information = (types and bandwidth) into every RTP package by using the already IETF = standardized RTP extension header RCF 5285, which could be used by any = current or future Internet (including OTT) network where WebRTC = real-time traffic may flow. It seems to have been standardized already = 2008 to allow such usage.

 

Qo= S related step C) draft-martinsen-tram-discuss = ca= n then be taken out of TRAM, and step D) (that was never intended to be = handled by TRAM anyway) will be handled = elsewhere.

 

I = have repeated my suggestion to RTCWEB WG from the October discussions on = the relevant [rtcweb] [avtext] = [mmusic] = lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage sug= gesting usage of RFC 5285, where traffic information in RTP packets = simply would be filled by any browser under any OS.

 

Wi= thout step B), = TRAM = “En= forcing the real-time traffic through the offered/discovered TURN = servers”, the real-time traffic may happen through the IP default = gateways often congested by data traffic and QoS insensitive streaming = video and file sharing. Without specific QoS methods at those points, = the network raw bandwidth capacity may have to be 10-folded to achieve = sufficient QoE when WebRTC usage becomes popular. Methods like DISCUSS = addresses such things occurring when STUN instead TURN is used (by = allowing flows into such congestion points), but only provides direct = traffic info for outgoing (not incoming) real-time traffic and locally, = therefore are not even applicable to reservation type of networks like = Cable Networks and Mobile OTT.

 

Th= at would leave certain network types to investing in raw bandwidth = increase, instead of simply borrowing the bandwidth (from much larger = data traffic and QoS insensitive streaming video and file sharing at no = adverse effect) and making that borrowed no-cost bandwidth very valuable = for the carriers when delivering to their = customers.

=

I = know a few of you Cisco guys are among the ones that have been fighting = against the general “it is all about bandwidth” and = “it will go away with time”-attitude within IETF work, e.g. = see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, = but the pointers given in the current QoS discussion within TRAM: =

 

(i= ) will *not allow* ISP’s to use already available and = currently deployable quality IP pipes for real-time traffic to also be = used for WebRTC generated real-time traffic.

 

(i= i) will *not allow* some network types (e.g. Cable Networks and = Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive = streaming video and file sharing. All networks will *also be = inhibited* from the very common and used method of simply providing = an extra IP pipe (often provided over the same wire but level-2 = separated) dedicated for real-time usage

(<= b>*by resisting TRAM implementation of step = B*)

Ne= wer, fiber only type of networks, can still borrow bandwidth at no extra = cost, *by proprietary usage* of RFC 5285 by browsers. =

 

(i= ii) will leave most ISPs to *only use* raw bandwidth capacity = increase that may has to be 10-folded to reach sufficient QoE when = WebRTC usage becomes popular (if at all possible, since unmanaged IP = pipes intermittently are filled, whatever bandwidth is = available).

 

Fu= rther explainations about QoS methods and their implementation were = given a few days ago in:

= http://www.ietf.org/mail-archive/web/tram/current/msg00274.html =

 

(i= ), (ii) and (iii) will *seriously delay* usage of telepresence = capable and quality demanding WebRTC (bandwidth being around 30 times = higher over best effort Internet, than telephony over quality managed = networks) and will *vastly increase cost* for ISPs to offer = WebRTC with good QoE.

 

Be= low you are giving pointers saying “They = are currently working on a problem-statement draft and a use-case draft, = any input to those would be very helpful.&#= 8221; Those are unnecessary, risking leading to (i), (ii) and (iii) = above.

 

So= are pointers such as: “RMCAT where = congestion avoidance for RTP is being developed&#= 8221;. TRAMs Milestone 3 is for the purpose of directing real-time = traffic where congestion control isn’t already in place. Using = RF= C 5285 available since 2008, to fill traffic information in RTP packets = (step D)) is probably a necessity for most future “congestion = control” discussed.

 

Th= is chicken-and-egg circular also applies to RTCWEB direction of QoS = issues to:

= http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos =

fo= cusing on DSCP-mapping without even mentioning RFC 5285 available since = 2008, to fill traffic information in RTP packets where it =A0is a = necessity and will allow:

(1= ) applications to directly convey QoS related real-time traffic info to = the network at points where RTP flow is directed to by TRAM Milstone 3, = to be used by *any network element implementing any suitable QoS = methods for the particular network* for

(2= ) *all* WebRTC browsers *and* dedicated clients (not using = WebRTC), under *all* OSs, and *all* current and future IP = networks

(3= ) *without* ha= ving to be forced into application specific networks (PSTN, IMS) instead = of using the Internet (including OTT).

 

Th= e only activity required, is to call for ISPs’ review whether the = traffic information transferred by RFC 5285 is sufficient for current = and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip><= o:p>

…two = parameters (e.g. two bytes each) are encoded into the RTP header = extension:

 

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic scale.

 

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type = e.g:

Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. = video streaming), Minimum Delay, Reliable Delivery, Prioritize X, = Variation Y, that could be combined as required to describe the = stream.

 

And with = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

</snip>=

 

Th= en this could be assigned numbers to have the RFC in = place.

Wi= th TRAM milestone 3 also place,

ma= rket forces will drive ISPs and browser makers to implement just that, = without even having it MUST-established.

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

 

Pl= ease see further emails soon following this one, for details and = history.

 

/K= arl

 

Fr=E5n: tram = [mailto:tram-bounces@ietf.org] F=F6r Pal Martinsen = (palmarti)
Skickat: den 21 februari 2014 10:37
Till: = tram@ietf.org
Kopia: Karl Stahl; Oleg Moskalenko; Alan = Johnston; Yoakum, John H (John)
=C4mne: Re: [tram] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

Hi,

 

I = agree the full QoS discussion should _not_ happen in TRAM. If you are = interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/= mailman/listinfo/aeon . They are currently working on a = problem-statement draft and a use-case draft, any input to those would = be very helpful. (http://= tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00).

 

That said, STUN have a few nice characteristics that = makes it a perfect candidate for transporting some of the QoS = information.  IMHO that would be extending the STUN spec and should = be within the TRAM charter.  The main goal = of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and = to start the discussion if TRAM is the appropriate place to have those = on the wire format discussions.

 

.-.

P=E5l-Erik

 

 

 

 

 

 

On = 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <yoakum@avaya.com> = wrote:



+1

I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts.  There are other groups = doing QOS work and frankly I engage in WebRTC multimedia interactions = daily over the Internet, enterprise VPNs, and various combinations and = seldom suffer egregious quality issues.  I am more concerned about = carriers doing things to regulate or degrade WebRTC flows than a failure = of existing Internet mechanisms to enable them.

 

Significant focus on QOS before we better enable TURN to be easily = used in a browser environment taking advantage or normal web = characteristics (as opposed to historic telephony constructs) would seem = to be highly distracting at this point.

 

 

Ch= eers,

Jo= hn

&nb= sp;

AVAY= A
1.9= 19.425.8446

 

From:=  tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg = Moskalenko
Sent: Thursday, February 20, 2014 = 12:43 PM
To: Alan = Johnston
Cc: Karl Stahl; tram@ietf.org
Subject: Re: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

 

 

On Thu, Feb 20, 2014 at 6:26 AM, = Alan Johnston <alan.b.johnston@gmail.com> = wrote:

 

 

 

Personally, I am not sure how much = QoS is actually in scope for TRAM. Have you been following RMCAT where = congestion avoidance for RTP is being developed?  I see some = overlap in your goals and the goals of that = work.

-

 

 

I'd = concentrate on the TURN application-level functionality, for now, and = I'd leave QoS for the future = discussions.


__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/= mailman/listinfo/tram

 

------=_NextPart_000_04EF_01CF31B7.445B3D00-- From nobody Mon Feb 24 15:03:17 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FFA1A030A; Mon, 24 Feb 2014 15:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 rp0hYZAXodU5; Mon, 24 Feb 2014 15:03:04 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 602201A01CB; Mon, 24 Feb 2014 15:03:03 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402250002595903; Tue, 25 Feb 2014 00:02:59 +0100 From: "Karl Stahl" To: "'Cullen Jennings \(fluffy\)'" , "'Magnus Westerlund'" , "'Simon Perreault'" , "'Ted Hardie'" , "'Gonzalo Camarillo'" , , References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: Date: Tue, 25 Feb 2014 00:02:57 +0100 Message-ID: <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0500_01CF31BC.F07B9F80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPLuh9NKjjBBbIvkuPAKYD51v6LZq/zpPA Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ZunKtgHTh_fL5crt4zdxx2lCEeY Cc: 'Spencer Dawkins' Subject: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 23:03:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0500_01CF31BC.F07B9F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To the TRAM WG and RTCWEB WG and ADs: =20 It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed = and encouraged to route quality demanding WebRTC media into their IP pipes = that are capable of transporting real-time traffic without quality issues, = using TURN servers.=20 =20 The subject from the TRAM mailing initiation spells out: *Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs* The TRAM WG must assure that TURN servers offered by ISPs/NSPs can be = used for the above purpose. (The objective of the TRAM WG milestone 3 is *not only* to resolve restrictive enterprise NAT/firewall traversal problem using TURN = servers.) I request that this is explicitly clarified in the TRAM charter. =20 The QoS discussions that has appeared in this TRAM WG, resulting from=20 draft-martinsen-tram-discuss-00.txt and=20 draft-thomson-tram-turn-bandwidth-00.txt=20 has been confusing (to say the least), risking that the general QoS = attitude within IETF work =93it is all about bandwidth=94 and =93it will go away = with time=94:=20 (i) will *not allow* ISP=92s to use already available and currently = deployable quality IP pipes for real-time traffic to also be used for WebRTC = generated real-time traffic. (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. That all networks *will be inhibited* from the = very common and used method of simply providing an extra IP pipe (often = provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) *while* newer, fiber only type of networks, still can borrow bandwidth = at no extra cost, *by proprietary usage* of RFC 5285 by browsers.=20 (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may have to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes = intermittently are filled, whatever bandwidth is available). =20 Further explanations about QoS methods and their implementation were = given a few days ago in:=20 http://www.ietf.org/mail-archive/web/tram/current/msg00274.html=20 =20 (i), (ii) and (iii) risk *seriously delaying* usage of telepresence = capable and quality demanding WebRTC (bandwidth being around 30 times higher = over best effort Internet, than telephony over quality managed networks) and = will *vastly increase cost* for ISPs to offer WebRTC with good QoE. =20 I am therefore advising that draft-martinsen-tram-discuss-00.txt and draft-thomson-tram-turn-bandwidth-00.txt=20 are withdrawn from TRAM. draft-martinsen-tram-discuss-00.txt can be reintroduced after clarification in the draft, that it is not about QoS = as clarified by http://www.ietf.org/mail-archive/web/tram/current/msg00276.html. =20 There are further details about this in the email http://www.ietf.org/mail-archive/web/tram/current/msg00303.html also = copied below. =20 It is therein explained that my repeated suggestion to RTCWEB WG http://www.ietf.org/mail-archive/web/rtcweb/current/msg11542.html from = the October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to introduce the QoS related usage of RFC 5285 into = draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 objectives of TRAM, immediately = would allow: (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP = variants) to quickly allow us to finally enjoy the high quality and connectivity (NAT/firewall traversal) of real-time communication services now = possible, for =20 (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks=20 (3) *without* having to be forced into application specific networks = (PSTN, IMS) instead of the Internet (including OTT). =20 The only activity required, is to call for ISPs=92 review whether the = traffic information transferred by RFC 5285 is sufficient for the needs of their networks. =20 WebRTC *can be* used for existing application specific IP networks (such = as IMS) for services existing on these networks, but with the introduction = of the TRAM objectives above and the proposed traffic information in every = RTP packet http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = as made possible by RFC 5285 available since 2008:=20 (a) the same as well as other real-time services using IETF RTP traffic, *can also (often much better) be* implemented over the Internet = (including OTT) (b) also considering needs of QoS, media routing, control, quality measurements, SLA implementation, usage, accounting, billing and = SP-peering, that so far has been attributed application specific networks, but in practice and in reality have shown difficulties to implement (e.g. = SP=92s peering of beyond POTS services, resulting in that the 50 year old, = pre-AM radio quality telephony service, still is the only truly global communication service (and today often is used to initiate other better proprietary communication services). =20 Application specific networks such as the IMS network have their own = methods of handling QoS, that not in anyway will be made less efficient by the methods proposed here. Application specific networks *can use and will = also benefit* from the flow control and traffic requirement marking of RTP streams proposed here. =20 WebRTC *will be* used over the Internet (including OTT) and *will = probably also be* used over the application specific IMS network for the services existing there through a gateway function from the Internet.=20 =20 With RFC 5285 QoS usage and with TRAM milestone 3 in place (which I = suggest the WGs to expedite),=20 market forces will drive ISPs and browser makers to implement just that, without even having it MUST-established. =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. =20 The TRAM WG and RTCWEB WG chairs and ADs are advised to review whether = IETF standard work in these WGs by contributors having an interest in more = than one of current or emerging: ISPs, carrier equipment vendors or web = browser makers, may discriminate any with an interest only in one of these. The = same should apply to non-activity by WG contributors to remedy such discrimination opened by allowed proprietary usage of RFCs such as RFC = 5285. =20 One input for such review are responses directed to me in the September = =96 October discussion on the RTCWEB list and on the TRAM list from my entry there February 8 http://www.ietf.org/mail-archive/web/tram/current/msg00132.html. =20 Please see just sent emails: http://www.ietf.org/mail-archive/web/rtcweb/current/msg11542.html=20 http://www.ietf.org/mail-archive/web/tram/current/msg00303.html=20 and further emails soon following this one, for details and history. =20 /Karl =20 =20 Charter charter-ietf-tram-01 https://datatracker.ietf.org/doc/charter-ietf-tram/=20 =20 =20 Fr=E5n: Karl Stahl [mailto:karl.stahl@intertex.se]=20 Skickat: den 24 februari 2014 23:22 Till: 'Pal Martinsen (palmarti)'; 'tram@ietf.org'; 'rtcweb@ietf.org' Kopia: 'Oleg Moskalenko'; 'Alan Johnston'; 'Yoakum, John H (John)' =C4mne: SV: [tram] [rtcweb] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 Hi P=E5l, =20 You did not comment nor answer, in response to any of: http://www.ietf.org/mail-archive/web/tram/current/msg00275.html=20 http://www.ietf.org/mail-archive/web/tram/current/msg00273.html=20 whether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the application/browser to transfer relevant real-time traffic information (types and bandwidth) into every RTP package by using the already IETF standardized RTP extension header RCF 5285, which could be used by any current or future Internet (including OTT) network where WebRTC = real-time traffic may flow. It seems to have been standardized already 2008 to = allow such usage. =20 QoS related step C) draft-martinsen-tram-discuss can then be taken out = of TRAM, and step D) (that was never intended to be handled by TRAM anyway) will be handled elsewhere. =20 I have repeated my suggestion to RTCWEB WG from the October discussions = on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage suggesting usage of RFC 5285, where traffic information in RTP packets simply would be filled by any browser under any OS. =20 Without step B), TRAM =93Enforcing the real-time traffic through the offered/discovered TURN servers=94, the real-time traffic may happen = through the IP default gateways often congested by data traffic and QoS = insensitive streaming video and file sharing. Without specific QoS methods at those points, the network raw bandwidth capacity may have to be 10-folded to achieve sufficient QoE when WebRTC usage becomes popular. Methods like DISCUSS addresses such things occurring when STUN instead TURN is used = (by allowing flows into such congestion points), but only provides direct traffic info for outgoing (not incoming) real-time traffic and locally, therefore are not even applicable to reservation type of networks like = Cable Networks and Mobile OTT.=20 =20 That would leave certain network types to investing in raw bandwidth increase, instead of simply borrowing the bandwidth (from much larger = data traffic and QoS insensitive streaming video and file sharing at no = adverse effect) and making that borrowed no-cost bandwidth very valuable for the carriers when delivering to their customers. =20 I know a few of you Cisco guys are among the ones that have been = fighting against the general =93it is all about bandwidth=94 and =93it will go = away with time=94-attitude within IETF work, e.g. see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, but = the pointers given in the current QoS discussion within TRAM:=20 =20 (i) will *not allow* ISP=92s to use already available and currently = deployable quality IP pipes for real-time traffic to also be used for WebRTC = generated real-time traffic. =20 (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. All networks will *also be inhibited* from the = very common and used method of simply providing an extra IP pipe (often = provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) Newer, fiber only type of networks, can still borrow bandwidth at no = extra cost, *by proprietary usage* of RFC 5285 by browsers.=20 =20 (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may has to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes = intermittently are filled, whatever bandwidth is available). =20 Further explanations about QoS methods and their implementation were = given a few days ago in:=20 http://www.ietf.org/mail-archive/web/tram/current/msg00274.html=20 =20 (i), (ii) and (iii) will *seriously delay* usage of telepresence capable = and quality demanding WebRTC (bandwidth being around 30 times higher over = best effort Internet, than telephony over quality managed networks) and will *vastly increase cost* for ISPs to offer WebRTC with good QoE. =20 Below you are giving pointers saying =93They are currently working on a problem-statement draft and a use-case draft, any input to those would = be very helpful.=94 Those are unnecessary, risking leading to (i), (ii) and = (iii) above. =20 So are pointers such as: =93RMCAT where congestion avoidance for RTP is = being developed=94. TRAMs Milestone 3 is for the purpose of directing = real-time traffic where congestion control isn=92t already in place. Using RFC = 5285 available since 2008, to fill traffic information in RTP packets (step = D)) is probably a necessity for most future =93congestion control=94 = discussed. =20 This chicken-and-egg circular also applies to RTCWEB direction of QoS = issues to:=20 http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos=20 focusing on DSCP-mapping without even mentioning RFC 5285 available = since 2008, to fill traffic information in RTP packets where it is a = necessity and will allow:=20 (1) applications to directly convey QoS related real-time traffic info = to the network at points where RTP flow is directed to by TRAM Milstone 3, = to be used by *any network element implementing any suitable QoS methods = for the particular network* for=20 (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks=20 (3) *without* having to be forced into application specific networks = (PSTN, IMS) instead of using the Internet (including OTT). =20 The only activity required, is to call for ISPs=92 review whether the = traffic information transferred by RFC 5285 is sufficient for current and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Then this could be assigned numbers to have the RFC in place. With TRAM milestone 3 also place,=20 market forces will drive ISPs and browser makers to implement just that, without even having it MUST-established. =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. =20 Please see further emails soon following this one, for details and = history. =20 /Karl =20 Fr=E5n: Pal Martinsen (palmarti) [mailto:palmarti@cisco.com]=20 Skickat: den 21 februari 2014 10:37 Till: tram@ietf.org Kopia: Oleg Moskalenko; Alan Johnston; Karl Stahl; Yoakum, John H (John) =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 Hi, =20 I agree the full QoS discussion should _not_ happen in TRAM. If you are interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case draft, any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). =20 That said, STUN have a few nice characteristics that makes it a perfect candidate for transporting some of the QoS information. IMHO that would = be extending the STUN spec and should be within the TRAM charter. The main goal of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and to start the discussion if TRAM is the appropriate place to have those on = the wire format discussions. =20 .-. P=E5l-Erik =20 =20 On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) < yoakum@avaya.com> wrote: +1 I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts. There are other groups doing QOS = work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs, and various combinations and seldom suffer egregious quality issues. I am more concerned about carriers doing = things to regulate or degrade WebRTC flows than a failure of existing Internet mechanisms to enable them. =20 Significant focus on QOS before we better enable TURN to be easily used = in a browser environment taking advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point. =20 =20 Cheers, John =20 AVAYA 1.919.425.8446 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 =20 =20 On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston < alan.b.johnston@gmail.com> wrote: =20 =20 =20 Personally, I am not sure how much QoS is actually in scope for TRAM. = Have you been following RMCAT where congestion avoidance for RTP is being developed? I see some overlap in your goals and the goals of that work. - =20 =20 I'd concentrate on the TURN application-level functionality, for now, = and I'd leave QoS for the future discussions. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 ------=_NextPart_000_0500_01CF31BC.F07B9F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

To= the TRAM WG and RTCWEB WG and ADs:

 

It= must be a clear objective of the TRAM WG that ISPs/NSPs are allowed and = encouraged to route quality demanding WebRTC media into their IP pipes = that are capable of transporting real-time traffic without quality = issues, using TURN servers.

 

Th= e subject from the TRAM mailing initiation spells = out:

*<= b>Milestone 3: TURN server auto-discovery mechanism for enterprise and = ISPs*

Th= e TRAM WG must assure that TURN servers offered by ISPs/NSPs can be used = for the above purpose.

(T= he objective of the TRAM WG milestone 3 is *not only* to resolve = restrictive enterprise NAT/firewall traversal problem using TURN = servers.)

=

I = request that this is explicitly clarified in the TRAM = charter.

 

Th= e QoS discussions that has appeared in this TRAM WG, resulting from =

draft-martinsen-tram-discuss-00.txt

an= d

draft-thomson-tram-turn-bandwidth-00.txt =

ha= s been confusing (to say the least), risking that the = general QoS attitude within IETF work “it is all about = bandwidth” and “it will go away with time”: =

(i= ) will *not allow* ISP’s to use already available and = currently deployable quality IP pipes for real-time traffic to also be = used for WebRTC generated real-time traffic.

(i= i) will *not allow* some network types (e.g. Cable Networks and = Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive = streaming video and file sharing. That all networks *will be = inhibited* from the very common and used method of simply providing = an extra IP pipe (often provided over the same wire but level-2 = separated) dedicated for real-time usage

(<= b>*by resisting TRAM implementation of step = B*)

*<= b>while* newer, fiber only type of networks, still can borrow = bandwidth at no extra cost, *by proprietary usage* of RFC 5285 by = browsers.

(i= ii) will leave most ISPs to *only use* raw bandwidth capacity = increase that may have to be 10-folded to reach sufficient QoE when = WebRTC usage becomes popular (if at all possible, since unmanaged IP = pipes intermittently are filled, whatever bandwidth is = available).

 

Fu= rther explanations about QoS methods and their implementation were given = a few days ago in:

= http://www.ietf.org/mail-archive/web/tram/current/msg00274.html =

 

(i= ), (ii) and (iii) risk *seriously delaying* usage of telepresence = capable and quality demanding WebRTC (bandwidth being around 30 times = higher over best effort Internet, than telephony over quality managed = networks) and will *vastly increase cost* for ISPs to offer = WebRTC with good QoE.

 

I = am therefore advising that draft-martinsen-tram-discuss-00.txt an= d draft-thomson-tram-turn-bandwidth-00.txt =

ar= e withdrawn from TRAM. draft-martinsen-tram-discuss-00.txt ca= n be reintroduced after clarification in the draft, that it is not about = QoS as clarified by = http://www.ietf.org/mail-archive/web/tram/current/msg00276.html.=

 

Th= ere are further details about this in the email = http://www.ietf.org/mail-archive/web/tram/current/msg00303.html also = copied below.

 

It= is therein explained that my repeated suggestion to RTCWEB WG http://www.ietf.org/mail-archive/web/rtcweb/current/msg11542.html = from the October discussions on the relevant [rtcweb] [avtext] [mmusic] = lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = to introduce the QoS related usage of RFC 5285 into draft-ietf-rtcweb-rtp-usage in= combinations with the Milestone 3 objectives of TRAM, immediately would = allow:

(1= ) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE = (in addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP = variants) to quickly allow us to finally enjoy the high quality and = connectivity (NAT/firewall traversal) of real-time communication = services now possible, for =A0

(2= ) *all* WebRTC browsers *and* dedicated clients (not using = WebRTC), under *all* OSs, and *all* current and future IP = networks

(3= ) *without* ha= ving to be forced into application specific networks (PSTN, IMS) instead = of the Internet (including OTT).

 

Th= e only activity required, is to call for ISPs’ review whether the = traffic information transferred by RFC 5285 is sufficient for the needs = of their networks.

 

We= bRTC *can be* used for existing application specific IP networks = (such as IMS) for services existing on these networks, but with the = introduction of the TRAM objectives above and the proposed traffic = information in every RTP packet http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = as made possible by RFC 5285 available since 2008: =

(a= ) the same as well as other real-time services using IETF RTP traffic, = *can also (often much better) be* implemented over the Internet = (including OTT)

(b= ) also considering needs of QoS, media routing, control, quality = measurements, SLA implementation, usage, accounting, billing and = SP-peering, =A0=A0

th= at so far has been attributed application specific networks, but in = practice and in reality have shown difficulties to implement (e.g. = SP’s peering of beyond POTS services, resulting in that the 50 = year old, pre-AM radio quality telephony service, still is the only = truly global communication service (and today often is used to initiate = other better proprietary communication = services).

 

Ap= plication specific networks such as the IMS network have their own = methods of handling QoS, that not in anyway will be made less efficient = by the methods proposed here. Application specific networks *can use = and will also benefit* from the flow control and traffic requirement = marking of RTP streams proposed here.

 

We= bRTC *will be* used over the Internet (including OTT) and = *will probably also be* used over the application specific IMS = network for the services existing there through a gateway function from = the Internet.

 

Wi= th RFC 5285 QoS usage and with TRAM milestone 3 in place (which I = suggest the WGs to expedite),

ma= rket forces will drive ISPs and browser makers to implement just that, = without even having it MUST-established.

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

 

Th= e TRAM WG and RTCWEB WG chairs and ADs are advised to review whether = IETF standard work in these WGs by contributors having an interest in = more than one of current or emerging: ISPs, carrier equipment vendors or = web browser makers, may discriminate any with an interest only in one of = these. The same should apply to non-activity by WG contributors to = remedy such discrimination opened by allowed proprietary usage of RFCs = such as RFC 5285.

 

On= e input for such review are responses directed to me in the September = – October discussion on the RTCWEB list and on the TRAM list from = my entry there February 8 = http://www.ietf.org/mail-archive/web/tram/current/msg00132.html.=

 

Pl= ease see just sent emails:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11542.html =

= http://www.ietf.org/mail-archive/web/tram/current/msg00303.html =

an= d further emails soon following this one, for details and = history.

 

/K= arl =A0

 

Charter = charter-ietf-tram-01 https://datatracker.ietf.org/doc/charter-ietf-tram/

 

 

Fr=E5n: Karl Stahl = [mailto:karl.stahl@intertex.se]
Skickat: den 24 februari 2014 = 23:22
Till: 'Pal Martinsen (palmarti)'; 'tram@ietf.org'; = 'rtcweb@ietf.org'
Kopia: 'Oleg Moskalenko'; 'Alan Johnston'; = 'Yoakum, John H (John)'
=C4mne: SV: [tram] [rtcweb] I-D = Action: draft-thomson-tram-turn-bandwidth-00.txt

 

Hi= P=E5l,

 

Yo= u did not comment nor answer, in response to any = of:

= http://www.ietf.org/mail-archive/web/tram/current/msg00275.html =

= http://www.ietf.org/mail-archive/web/tram/current/msg00273.html =

wh= ether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the = application/browser to transfer relevant real-time traffic information = (types and bandwidth) into every RTP package by using the already IETF = standardized RTP extension header RCF 5285, which could be used by any = current or future Internet (including OTT) network where WebRTC = real-time traffic may flow. It seems to have been standardized already = 2008 to allow such usage.

 

Qo= S related step C) draft-martinsen-tram-discuss = ca= n then be taken out of TRAM, and step D) (that was never intended to be = handled by TRAM anyway) will be handled = elsewhere.

 

I = have repeated my suggestion to RTCWEB WG from the October discussions on = the relevant [rtcweb] [avtext] = [mmusic] = lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage sug= gesting usage of RFC 5285, where traffic information in RTP packets = simply would be filled by any browser under any OS.

 

Wi= thout step B), TRAM “Enforcing the real-time traffic through the = offered/discovered TURN servers”, the real-time traffic may happen = through the IP default gateways often congested by data traffic and QoS = insensitive streaming video and file sharing. Without specific QoS = methods at those points, the network raw bandwidth capacity may have to = be 10-folded to achieve sufficient QoE when WebRTC usage becomes = popular. Methods like DISCUSS addresses such things occurring when STUN = instead TURN is used (by allowing flows into such congestion points), = but only provides direct traffic info for outgoing (not incoming) = real-time traffic and locally, therefore are not even applicable to = reservation type of networks like Cable Networks and Mobile OTT. =

 

Th= at would leave certain network types to investing in raw bandwidth = increase, instead of simply borrowing the bandwidth (from much larger = data traffic and QoS insensitive streaming video and file sharing at no = adverse effect) and making that borrowed no-cost bandwidth very valuable = for the carriers when delivering to their = customers.

 

I = know a few of you Cisco guys are among the ones that have been fighting = against the general “it is all about bandwidth” and = “it will go away with time”-attitude within IETF work, e.g. = see http://www.ietf.org/mail-archive/web/rtcweb/current/msg09031.html, = but the pointers given in the current QoS discussion within TRAM: =

 

(i= ) will *not allow* ISP’s to use already available and = currently deployable quality IP pipes for real-time traffic to also be = used for WebRTC generated real-time traffic.

 

(i= i) will *not allow* some network types (e.g. Cable Networks and = Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive = streaming video and file sharing. All networks will *also be = inhibited* from the very common and used method of simply providing = an extra IP pipe (often provided over the same wire but level-2 = separated) dedicated for real-time usage

(<= b>*by resisting TRAM implementation of step = B*)

Ne= wer, fiber only type of networks, can still borrow bandwidth at no extra = cost, *by proprietary usage* of RFC 5285 by browsers. =

 

(i= ii) will leave most ISPs to *only use* raw bandwidth capacity = increase that may has to be 10-folded to reach sufficient QoE when = WebRTC usage becomes popular (if at all possible, since unmanaged IP = pipes intermittently are filled, whatever bandwidth is = available).

 

Fu= rther explanations about QoS methods and their implementation were given = a few days ago in:

= http://www.ietf.org/mail-archive/web/tram/current/msg00274.html =

 

(i= ), (ii) and (iii) will *seriously delay* usage of telepresence = capable and quality demanding WebRTC (bandwidth being around 30 times = higher over best effort Internet, than telephony over quality managed = networks) and will *vastly increase cost* for ISPs to offer = WebRTC with good QoE.

 

Be= low you are giving pointers saying “They = are currently working on a problem-statement draft and a use-case draft, = any input to those would be very helpful.&#= 8221; Those are unnecessary, risking leading to (i), (ii) and (iii) = above.

 

So= are pointers such as: “RMCAT where = congestion avoidance for RTP is being developed&#= 8221;. TRAMs Milestone 3 is for the purpose of directing real-time = traffic where congestion control isn’t already in place. Using RFC = 5285 available since 2008, to fill traffic information in RTP packets = (step D)) is probably a necessity for most future “congestion = control” discussed.

 

Th= is chicken-and-egg circular also applies to RTCWEB direction of QoS = issues to:

= http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos =

fo= cusing on DSCP-mapping without even mentioning RFC 5285 available since = 2008, to fill traffic information in RTP packets where it  is a = necessity and will allow:

(1= ) applications to directly convey QoS related real-time traffic info to = the network at points where RTP flow is directed to by TRAM Milstone 3, = to be used by *any network element implementing any suitable QoS = methods for the particular network* for

(2= ) *all* WebRTC browsers *and* dedicated clients (not using = WebRTC), under *all* OSs, and *all* current and future IP = networks

(3= ) *without* ha= ving to be forced into application specific networks (PSTN, IMS) instead = of using the Internet (including OTT).

 

Th= e only activity required, is to call for ISPs’ review whether the = traffic information transferred by RFC 5285 is sufficient for current = and future needs in their network as suggested in http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip><= o:p>

…two = parameters (e.g. two bytes each) are encoded into the RTP header = extension:

 

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic scale.

 

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type = e.g:

Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. = video streaming), Minimum Delay, Reliable Delivery, Prioritize X, = Variation Y, that could be combined as required to describe the = stream.

 

And with = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

</snip>=

 

Th= en this could be assigned numbers to have the RFC in = place.

Wi= th TRAM milestone 3 also place,

ma= rket forces will drive ISPs and browser makers to implement just that, = without even having it MUST-established.

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

 

Pl= ease see further emails soon following this one, for details and = history.

 

/K= arl

 

Fr=E5n: Pal = Martinsen (palmarti) [mailto:palmarti@cisco.com]
Skickat: den = 21 februari 2014 10:37
Till: tram@ietf.org
Kopia: = Oleg Moskalenko; Alan Johnston; Karl Stahl; Yoakum, John H = (John)
=C4mne: Re: [tram] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

Hi,

 

I = agree the full QoS discussion should _not_ happen in TRAM. If you are = interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/= mailman/listinfo/aeon . They are currently working on a = problem-statement draft and a use-case draft, any input to those would = be very helpful. (http://= tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00).

 

That said, STUN have a few nice characteristics that = makes it a perfect candidate for transporting some of the QoS = information.  IMHO that would be extending the STUN spec and should = be within the TRAM charter.  The main goal = of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and = to start the discussion if TRAM is the appropriate place to have those = on the wire format discussions.

 

.-.

P=E5l-Erik

 

 

On 20 Feb 2014, at 19:55 pm, = Yoakum, John H (John) <yoakum@avaya.com> = wrote:



+1

I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts.  There are other groups = doing QOS work and frankly I engage in WebRTC multimedia interactions = daily over the Internet, enterprise VPNs, and various combinations and = seldom suffer egregious quality issues.  I am more concerned about = carriers doing things to regulate or degrade WebRTC flows than a failure = of existing Internet mechanisms to enable them.

 

Significant focus on QOS before we better enable TURN to be easily = used in a browser environment taking advantage or normal web = characteristics (as opposed to historic telephony constructs) would seem = to be highly distracting at this point.

 

 

Ch= eers,

Jo= hn

&nb= sp;

AVAY= A
1.9= 19.425.8446

 

From:=  tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg = Moskalenko
Sent: Thursday, February 20, 2014 = 12:43 PM
To: Alan = Johnston
Cc: Karl Stahl; tram@ietf.org
Subject: Re: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

 

 

On Thu, Feb 20, 2014 at 6:26 AM, = Alan Johnston <alan.b.johnston@gmail.com> = wrote:

 

 

 

Personally, I am not sure how much = QoS is actually in scope for TRAM. Have you been following RMCAT where = congestion avoidance for RTP is being developed?  I see some = overlap in your goals and the goals of that = work.

-

 

 

I'd = concentrate on the TURN application-level functionality, for now, and = I'd leave QoS for the future = discussions.


__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/= mailman/listinfo/tram

 

------=_NextPart_000_0500_01CF31BC.F07B9F80-- From nobody Mon Feb 24 17:46:16 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099B01A0238; Mon, 24 Feb 2014 17:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 C6YVjW9KhBcJ; Mon, 24 Feb 2014 17:46:05 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 43E461A02F2; Mon, 24 Feb 2014 17:46:03 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402250245576737; Tue, 25 Feb 2014 02:45:57 +0100 From: "Karl Stahl" To: "'Colin Perkins'" References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> In-Reply-To: <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> Date: Tue, 25 Feb 2014 02:45:52 +0100 Message-ID: <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_052F_01CF31D3.B4D608A0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8xsw6MT6VAbRocR6mnZ5R57HbLIwAEbGug Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/nfEsqPvHtayVHCX5Yp_0lA6jf1s Cc: 'Magnus Westerlund' , rtcweb@ietf.org, tram@ietf.org, 'Harald Alvestrand' Subject: Re: [tram] [rtcweb] Payload Types assignments X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 01:46:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_052F_01CF31D3.B4D608A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Colin, =20 If the below were the case, it would be =93DPI guesswork=94 that I also = advice against. RTP doesn=92t even have unique protocol header within UDP =96 = it can even be confused with other UDP payload.=20 =20 However, if the RTP is captured in a TURN-flow, as in TRAM Milestone 3, = the network point that this flow is directed to and can apply QoS methods relevant to the network (which is not diffserve in Mobile OTT and Cable Networks) has not a too difficult tasks. Linking each RTP-flow by its ID = and sequence number, and picking exactly the right traffic type and = bandwidth parameters is doable (see inline below, we at Ingate do it already)! =20 Also DiffServ DSCP-bits are seldom maintained crossing network = boundaries, thus carrying no relevant information at the receiving end, while the = RTP extension header remains unchanged end-to-end. In DSCP-bits, there is no bandwidth requirement information when entering networks requiring reservation. That is always (and dynamically set) available in the RTP extension header for each packet. =20 And, I am sure you are aware of the difficulties of getting DSCP-bits through OS sockets, which is even worse with multiple streams over the = same UDP-port =20 Further, defining the QoS RTP extension header as in RFC5285, does not = in anyway conflict with other RTP extension headers or DSCP transfer or settings. =20 /Karl =20 Fr=E5n: Colin Perkins [mailto:csp@csperkins.org]=20 Skickat: den 24 februari 2014 23:52 Till: Karl Stahl Kopia: rtcweb@ietf.org; Magnus Westerlund; tram@ietf.org; Harald = Alvestrand =C4mne: Re: [rtcweb] [tram] Payload Types assignments =20 Karl, =20 I strongly disagree with this suggestion. An RTP header extension, = located at an unknown and variable offset into a packet that does not have a well-defined magic number in the header,=20 This is how to find the traffic info: The payload of the classifier header extension element can be encoded using either the one-byte or two-byte header defined in [rfc5285 ] and shown below in Figure 1 and 2 below. =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=3D1 | Namespace | Value | 0 (pad) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 Figure 1: Classifier Using the One-Byte Header =20 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID | len=3D2 | Namespace | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =20 =20 Figure 2: Classifier Using the Two-Byte Header =20 indicated using a dynamically assigned identifier that is conveyed in an out-of-band=20 --- It is the TURN flow!!! Requested by the ICE protocol for the = specific media to come! and encrypted signalling channel,=20 --- Only the payload is encrypted in SRTP =96 leaving id, seq no and = header ext to be used as intended! --- Thus being the appropriate place=85 is not an appropriate place to put QoS information that has to be = processed on a per-packet basis.=20 If you want DiffServ, you know where to find it. --- True, but if it cannot be used=85 Colin =20 =20 On 24 Feb 2014, at 22:09, Karl Stahl wrote: I suggest to the RTCWEB WG that the below from the September and October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC 5285, to = allow: =20 (1) WebRTC applications to directly convey QoS related real-time traffic info to the network at points where RTP flow is directed to by TRAM = Milstone 3, to be used by *any network element implementing any suitable QoS = methods for the particular network* for=20 (2) *all* WebRTC browsers *and* clients, under *all* OSs, and *all* = current and future IP network, to achieve best QoE=20 (3) *without* having to force WebRTC into application specific networks (such as IMS) instead of using the Internet (including OTT). =20 The only further activity required, is to call for ISPs=92 to review = whether the traffic information transferred by RFC 5285 is sufficient for = current and future needs in their network as suggested in below repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Then this could be assigned numbers to have an RFC in place. =20 With TRAM milestone 3 also place,=20 market forces will drive ISPs and browser makers to implement just this, without even having it MUST-established. =20 =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. =20 Please see further emails soon following this one, for details and = history. =20 /Karl =20 =20 Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Karl Stahl Skickat: den 22 oktober 2013 16:37 Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus Westerlund' Kopia: 'Colin Perkins' =C4mne: [rtcweb] [avtext] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 Harald, I mostly agree with the quality requirements of different = real-time traffic that the WebRTC browser/application may use. But rather than = asking the application, let's convey the bandwidth and priority requirements to = the network. Just like with the Payload type (that is hard to squeeze that information into) it must be visible to the network (and not changed by = the network, like diffserv bits are). Such marking must also be available = for incoming traffic, which is especially important in RSVP type of = networks, that has to reserve bandwidth for it. =20 =20 There is actually a good way to show these needs to the network (without using the PT, or diffserv bits, which aren=92t sufficient anyway).=20 =20 Let's use the RTP header extension field that also is visible outside = the encrypted payload. A week ago came http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that outlines the usage of the extension field for classification of traffic! This document does not yet outline what to put in there and how to = encode it though. =20 Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 = discusses other webrtc usages of the RTP header extension in 5.2 (there can be = many header extensions according to RFC 5285) and in 9 there is "WebRTC Use = of RTP: Future Extensions". =20 So, it looks obvious to use the RTP header extension to show the characteristics and bandwidth requirements to the network. It should not introduce any backward incompatibilities either. =20 Such marking is done in every RTP packet so it can be set individually = for each stream and could even be changed during a session (e.g. when = limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies how RTP extension header usage can be negotiated in SDP. I think this could be easily done by the WebRTC browser for "all current and future needs" if properly specified now. =20 I suggest that two parameters (e.g. two bytes each) are encoded into the = RTP header extension: =20 A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence=85 on a logarithmic scale. =20 B) The quality characteristics for the stream, with the highest bit set = to 1, we could allocate a bit each quality e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to = describe the stream. =20 And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the individual bits. =20 Please note the totally different requirements a diffserv and an RSVP network have to know, so let=92s put all into these bytes. (E.g. a = diffserv network don't need the bandwidth usage, but RSVP reservation networks = (e.g. cable and 3G/4G OTT) do. There one should initially reserve the maximum bandwidth indicated, but can later re-reserve.) =20 /Karl =20 PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94;=20 However that seems to apply to the TURN server allocation request and = would therefore: --- Apply to the whole UDP flow, and could not be set for each stream individually (with different requirements), and --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) However the quality attributes conveyed and their encoding may be considered. =20 This is 2.2.2.19 MS-Service Quality Attribute from=20 http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20 =20 MS-Service Quality Attribute The MS-Service Quality attribute is used to convey information about the data stream that the protocol client is intending to transfer over an allocated port. The protocol client SHOULD<21> include this attribute as part of an Allocate request message. A TURN server SHOULD use the information in this attribute to make decisions about resource = allocation, bandwidth prioritization, and data delivery methods. If the attribute is = not present in the Allocate request message, the TURN server SHOULD assume = that the data stream is audio with best effort delivery. The format of this attribute is as follows...=20 ... The following stream types are supported in this extension. All other = stream types are reserved for future use. =A7 "0x0001": Audio =A7 "0x0002": Video =A7 "0x0003": Supplemental Video =A7 "0x0004": Data Service Quality (2 bytes): The service quality level required by the protocol client for the stream. The following service quality levels are supported in this extension. = All other service quality levels are reserved for future use. =A7 "0x0000": Best effort delivery. =A7 "0x0001": Reliable delivery. =20 =20 -----Ursprungligt meddelande----- Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Harald Alvestrand Skickat: den 8 oktober 2013 13:01 Till: rtcweb@ietf.org =C4mne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC = of draft-ietf-rtcweb-use-cases-and-requirements-11 =20 On 10/08/2013 09:17 AM, Karl Stahl wrote: > Hej Magnus, >=20 >> Also, are you really interested in knowing that it is VP9 vs H.264,=20 >> isn't > the questions this is video of this priority that is important? >> I think you need to more carefully consider what are the goals you=20 >> try to > achieve them. >=20 > Actually, my concern is to get an idea of the maximum bandwidth that=20 > could be required for a WebRTC (ICE) setup media flow. Both voice and=20 > video should be prioritized over data (their individual priority is of = > less importance as long as there is sufficient bandwidth for both). =20 You don't know that without knowing what the application is for. In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. =20 >=20 > With diffserv you don=92t need to know the bandwidth requirement, but=20 > with RSVP reservation (like in cable and mobile networks) you need to=20 > know how much to reserve. Voice is like 100's kbit/s, video VP8 or=20 > H.264 is like 3,5 mbps. =20 Again, without knowing the application, you don't know that. The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is completely different from that of a talking head, which is again completely = different from a high-movement scene. =20 >=20 > To add to the complication of codec variants, the video codecs in=20 > question for WebRTC have variable bandwidth, and when there is a poor=20 > connection we see Chrome reducing the video window size to reduce the bandwidth used... >=20 > I think the payload type field at best can reflect a maximum bandwidth = > to initially reserve bandwidth for, and thereafter make new=20 > reservations if the bandwidth changes during the call. So could we=20 > change RTP to show maximum bandwidth instead of payload type in that=20 > field outside the encrypted payload :) ... Or maybe that is not a = joke? =20 I think these ruminations only lead to one conclusion: =20 You can't tell what the needed bandwidth is up front without asking the application. You can't tell what the right priority ranking is without asking the application. =20 If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. =20 _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb =20 =20 --=20 Colin Perkins http://csperkins.org/ =20 =20 =20 ------=_NextPart_000_052F_01CF31D3.B4D608A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Co= lin,

 

If= the below were the case, it would be “DPI guesswork” that I = also advice against. RTP doesn’t even have unique protocol header = within UDP – it can even be confused with other UDP payload. =

 

Ho= wever, if the RTP is captured in a TURN-flow, as in TRAM Milestone 3, = the network point that this flow is directed to and can apply QoS = methods relevant to the network (which is not diffserve in Mobile OTT = and Cable Networks) has not a too difficult tasks. Linking each RTP-flow = by its ID and sequence number, and picking exactly the right traffic = type and bandwidth parameters is doable (see inline below, we at Ingate = do it already)!

 

Al= so DiffServ DSCP-bits are seldom maintained crossing network boundaries, = thus carrying no relevant information at the receiving end, while the = RTP extension header remains unchanged end-to-end. In DSCP-bits, there = is no bandwidth requirement information when entering networks requiring = reservation. That is always (and dynamically set) available in the RTP = extension header for each packet.

 

An= d, I am sure you are aware of the difficulties of getting DSCP-bits = through OS sockets, which is even worse with multiple streams over the = same UDP-port

 

Fu= rther, defining the QoS RTP extension header as in RFC5285, does not in = anyway conflict with other RTP extension headers or DSCP transfer or = settings.

 

/K= arl

 

Fr=E5n: Colin = Perkins [mailto:csp@csperkins.org]
Skickat: den 24 februari = 2014 23:52
Till: Karl Stahl
Kopia: rtcweb@ietf.org; = Magnus Westerlund; tram@ietf.org; Harald Alvestrand
=C4mne: = Re: [rtcweb] [tram] Payload Types = assignments

 

Karl,

 

I = strongly disagree with this suggestion. An RTP header extension, located = at an unknown and variable offset into a packet that does not have a = well-defined magic number in the header,

Th= is is how to find the traffic info:

=A0=A0 The payload = of the classifier header extension element can be = encoded

=A0=A0 using either = the one-byte or two-byte header defined in [rfc5285] = and

=A0=A0 shown below = in Figure 1 and 2 below.

 

=A0=A0=A0=A0=A0 = 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 1=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 3

=A0=A0=A0=A0=A0 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

=A0=A0=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0 |=A0 = ID=A0=A0 | len=3D1 |=A0=A0 Namespace=A0=A0 |=A0=A0=A0 = Value=A0=A0=A0=A0=A0 |=A0=A0=A0 0 (pad)=A0=A0=A0 = |

=A0=A0=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 1: Classifier Using = the One-Byte Header

 

=A0=A0=A0=A0=A0 = 0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A01=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 = 2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 3

=A0=A0=A0=A0=A0 0 1 = 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1

=A0=A0=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0 ID=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 len=3D2=A0=A0=A0=A0=A0 = |=A0=A0 Namespace=A0=A0 |=A0=A0=A0 Value=A0=A0=A0=A0=A0 = |

=A0=A0=A0=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Figure 2: Classifier Using = the Two-Byte Header

 

indicated using a dynamically assigned identifier that is = conveyed in an out-of-band

--= - It is the TURN flow!!! Requested by the ICE protocol for the specific = media to come!

and encrypted signalling channel,

--= - Only the payload is encrypted in SRTP – leaving id, seq no and = header ext to be used as intended!

--= - Thus being the appropriate place…

is not an appropriate place to put = QoS information that has to be processed on a per-packet basis.

If you want DiffServ, you know = where to find it.

--- True, but = if it cannot be used…

Colin

 

 

On = 24 Feb 2014, at 22:09, Karl Stahl <karl.stahl@intertex.se> = wrote:

I = suggest to the RTCWEB WG that the below from the September and October = discussions on the relevant [rtcweb] [avtext] = [mmusic] = lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = is introduced into draft-ietf-rtcweb-rtp-usage = fo= r usage of RFC 5285, to allow:

&n= bsp;

(1= ) WebRTC applications to directly convey QoS related real-time traffic = info to the network at points where RTP flow is directed to by TRAM = Milstone 3, to be used by *any network element implementing any = suitable QoS methods for the particular network* for =

(2= ) *all* WebRTC browsers *and* clients, under *all* = OSs, and *all* current and future IP network, to achieve best QoE =

(3= ) *without* ha= ving to force WebRTC into application specific networks (such as IMS) = instead of using the Internet (including OTT).

&n= bsp;

Th= e only further activity required, is to call for ISPs’ to review = whether the traffic information transferred by RFC 5285 is sufficient = for current and future needs in their network as suggested in below = repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip><= /span>

…two = parameters (e.g. two bytes each) are encoded into the RTP header = extension:

 =

A) The = maximum bandwidth requirement: Two bytes could contain everything from = some bps for real-time text to Gbps for future 3D supersize = telepresence… on a logarithmic scale.

 =

B) The = quality characteristics for the stream, with the highest bit set to 1, = we could allocate a bit each for quality type = e.g:

Best Effort, = Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. = video streaming), Minimum Delay, Reliable Delivery, Prioritize X, = Variation Y, that could be combined as required to describe the = stream.

 =

And with = highest bit set to 0, there could instead be a number for special usage = that does not fit the general description of the individual = bits.

</snip>=

&n= bsp;

Th= en this could be assigned numbers to have an RFC in = place.

&n= bsp;

Wi= th TRAM milestone 3 also place,

ma= rket forces will drive ISPs and browser makers to implement just this, = without even having it MUST-established.

&n= bsp;

&#= 8220;Who does not want a “WebRTC-Ready” Internet = access?” and

&#= 8220;Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?” and vice = versa.

&n= bsp;

Pl= ease see further emails soon following this one, for details and = history.

&n= bsp;

/K= arl

&n= bsp;

&n= bsp;

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Karl Stahl
Skickat: den 22 oktober 2013 = 16:37
Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus = Westerlund'
Kopia: 'Colin Perkins'
=C4mne: [rtcweb] = [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

Harald, I mostly agree with the quality requirements of = different real-time traffic that the WebRTC browser/application may use. = But rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it.  

 

There is actually a good way to = show these needs to the network (without using the PT, or diffserv bits, = which aren’t sufficient anyway).

 

Let's use the RTP header = extension field that also is visible outside the encrypted payload. A = week ago came h= ttp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 =  that outlines the usage of the extension field for classification = of traffic! This document does not yet outline what to put in there and = how to encode it though.

 

Today's http:/= /tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other = webrtc usages of the RTP header extension in 5.2 (there can be many = header extensions according to RFC 5285) and in 9 there is "WebRTC = Use of RTP: Future Extensions".

 

So, it looks obvious to use the = RTP header extension to show the characteristics and bandwidth = requirements to the network. It should not introduce any backward = incompatibilities either.

 

Such marking is done in every = RTP packet so it can be set individually for each stream and could even = be changed during a session (e.g. when limiting the bandwidth based on = RTCP feedback). RFC 5286 also specifies how RTP extension header usage = can be negotiated in SDP. I think this could be easily done by the = WebRTC browser for "all current and future needs" if properly = specified now.

 

I suggest that two parameters (e.g. two bytes each) are = encoded into the RTP header extension:

 

A) The maximum bandwidth = requirement: Two bytes could contain everything from some bps for = real-time text to Gbps for future 3D supersize telepresence… on a = logarithmic scale.

 

B) The quality characteristics for the stream, with the = highest bit set to 1, we could allocate a bit each quality = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, = Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable = Delivery, Prioritize X, Variation Y, that could be combined as required = to describe the stream.

 

And with highest bit set to 0, = there could instead be a number for special usage that does not fit the = general description of the individual bits.

 

Please note the totally = different requirements a diffserv and an RSVP network have to know, so = let’s put all into these bytes. (E.g. a diffserv network don't = need the bandwidth usage, but RSVP reservation networks (e.g. cable and = 3G/4G OTT) do. There one should initially reserve the maximum bandwidth = indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft seems to have = done work in this field, defining a proprietary attribute “MS = Service Quality”;

However that seems to apply = to the TURN server allocation request and would = therefore:

--- Apply to = the whole UDP flow, and could not be set for each stream individually = (with different requirements), and

--- Does not handle the = bandwidth requirement for incoming real-time traffic (required to = reserve in RSVP type of networks)

However the quality = attributes conveyed and their encoding may  be = considered.

 

=

This is 2.2.2.19 MS-Service = Quality Attribute from

http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).asp= x 

 

MS-Service Quality = Attribute

The MS-Service = Quality attribute is used to convey information about the data stream = that the protocol client is intending to transfer over an allocated = port. The protocol client SHOULD<21> include this attribute as = part of an Allocate request message. A TURN server SHOULD use the = information in this attribute to make = decisions about resource allocation, bandwidth prioritization, and data = delivery methods. If the attribute is not present in the Allocate = request message, the TURN server SHOULD assume that the data stream is = audio with best effort delivery. The format of this attribute is as = follows...

...

The following stream types = are supported in this extension. All other stream types are reserved for = future use.

=A7 "0x0001": = Audio

=A7 "0x0002": = Video

=A7 "0x0003": = Supplemental Video

=A7 = "0x0004": = Data

Service = Quality (2 bytes): The service quality level required by the protocol = client for the stream.

The following service = quality levels are supported in this extension. All other service = quality levels are reserved for future use.

=A7 = "0x0000": Best = effort delivery.

=A7 = "0x0001": = Reliable delivery.

 

 

-----Ursprungligt meddelande-----

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r Harald Alvestrand

Skickat: den 8 oktober 2013 13:01

Till: rtcweb@ietf.org

=C4mne: Re: [rtcweb] Payload = Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, Karl = Stahl wrote:

> Hej Magnus,

> 

>> Also, are you really = interested in knowing that it is VP9 vs H.264,

>> = isn't

> the questions this is video of this priority that is = important?

>> I think you need to more carefully consider what = are the goals you

>> try to

> achieve = them.

> 

> Actually, my concern is to = get an idea of the maximum bandwidth that

> could be required for a = WebRTC (ICE) setup media flow. Both voice and

> video should be prioritized = over data (their individual priority is of

> less importance as long as = there is sufficient bandwidth for both).

 

You don't know that without = knowing what the application is for.

In, for instance, a shooter game = with voice backchannels, the movement and event information (data) is = MORE time sensitive than the voice data.

 

> 

> With diffserv you = don’t need to know the bandwidth requirement, but =

> = with RSVP reservation (like in cable and mobile networks) you need to =

> = know how much to reserve. Voice is like 100's kbit/s, video VP8 or =

> = H.264 is like 3,5 mbps.

 

Again, without knowing the = application, you don't know that.

The application could decide to = use QCIF or HD, and the bandwidth variation of screencast (semi-static = with sudden, large changes) is completely different from that of a = talking head, which is again completely different from a high-movement = scene.

 

> 

> To add to the complication = of codec variants, the video codecs in

> question for WebRTC have = variable bandwidth, and when there is a poor

> connection we see Chrome = reducing the video window size to reduce the bandwidth = used...

> 

> I think the payload type = field at best can reflect a maximum bandwidth

> to initially reserve = bandwidth for, and thereafter make new

> reservations if the = bandwidth changes during the call. So could we

> change RTP to show maximum = bandwidth instead of payload type in that

> field outside the encrypted = payload :) ... Or maybe that is not a joke?

 

I think these ruminations only = lead to one conclusion:

 

You can't tell what the needed = bandwidth is up front without asking the = application.

You can't tell what the right priority ranking is without = asking the application.

 

If you need to know the = bandwidth or the priority up front, the application has to tell you. = Anything else is pure heuristics.

 

_______________________________________________<= /o:p>

rtcweb mailing = list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb=

 

 

-- 

Colin Perkins

 

 

 

------=_NextPart_000_052F_01CF31D3.B4D608A0-- From nobody Tue Feb 25 00:39:49 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200EA1A0384; Tue, 25 Feb 2014 00:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.151 X-Spam-Level: X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 10tJQJVH8LUO; Tue, 25 Feb 2014 00:39:44 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C61F81A0329; Tue, 25 Feb 2014 00:39:43 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-29-530c56ce195b Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 17.6E.10875.EC65C035; Tue, 25 Feb 2014 09:39:42 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.2.347.0; Tue, 25 Feb 2014 09:39:41 +0100 Message-ID: <530C56CD.3010003@ericsson.com> Date: Tue, 25 Feb 2014 09:39:41 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Karl Stahl References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> In-Reply-To: <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvje65MJ5gg+P7ZSze9axls1j7r53d 4sPaC2wOzB5Llvxk8vi0dT5LAFMUl01Kak5mWWqRvl0CV8bDK1wFTwQrLvYfZ25g3MzXxcjJ ISFgIrHh9BIWCFtM4sK99WxdjFwcQgKHGCWenDnBDOEsB3L+b2IDqeIV0JY4f2ApO4jNIqAq 8eTUJEYQm03AQuLmj0awGlGBYImdB34zQtQLSpyc+QRsg4iAusS086fAapgF1CQmfbwPNkdY wEri0af1LBDLnrJKfJ8+lRkkwSngIPH0/wqgIg6g88QlehqDIHr1JKZcbWGEsOUlmrfOBisX ArqtoamDdQKj0Cwkq2chaZmFpGUBI/MqRvbcxMyc9HLDTYzAoD245bfuDsZT50QOMUpzsCiJ 83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdH4tZyf+qyPsgf1D3Mq1HUprJ5pFF69 5JPq5EnHuoXONc2dVn3kz/QLqv9ldL8c4WoN4SheVq5oX+/XunR1c1NUmX7p8+xXizfNmi1i VWVmILKHcbqbFvv7vYfNu1KZTrGVCD4ovmLyuECt6ODbhwJliuumCq91cIjXKZu/5dXqZTtf H/bS2K7EUpyRaKjFXFScCAAmPveOKAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/OcMJy3B__-a4zyieisjMFXc_Sq0 Cc: rtcweb@ietf.org, tram@ietf.org Subject: Re: [tram] [rtcweb] Payload Types assignments X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 08:39:46 -0000 Karl, (As individual) I also wish for more usable QoS mechanisms. However, I don't see that being achieved by your proposal. In addition I agree with Colin about the issues with putting the information in the RTP header extension. I would also note that this would be very RTP specific, and not at all help with the data channels multiple streams and their priorities. There might be data channel information that is more crucial than any of the RTP media stream packets. You are pushing for a small piece in the middle. A piece that will not help with the more general issue of QoS. How does the application and the multiple ISPs that carries the traffic reach an agreement on what properties that can be provided, that the application in this instance have the right to request those properties and that any cost is correctly associated with the user or the user's agent in regards to carrying the associated cost. When it comes to setting DSCP from user land in the OS, that is restricted due to the security implications. If those implications where resolved, then OS could open up those interfaces. There are many interlinked reasons why things look like they do today. I don't believe in tugging on a single random thread in ball of yarn and hope that it comes out without any knots and ties on it. Show me the framework for the QoS functions you have in mind that at least has less issues than the currently deployed and take care of at least some of the bigger issues. If that requires information in the RTP streams for some reasons, then let us talk about how to best encoded it. But, we need that framework first, the architecture that makes this a better solution than the current Diffserv architecture or any other QoS architecture. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- 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 Feb 25 04:48:15 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6A21A036B; Tue, 25 Feb 2014 04:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.347 X-Spam-Level: X-Spam-Status: No, score=-7.347 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1Bg25urGegp4; Tue, 25 Feb 2014 04:48:10 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 88A951A0644; Tue, 25 Feb 2014 04:48:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=59466; q=dns/txt; s=iport; t=1393332489; x=1394542089; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6MaWeVYEzJZU58qV9Wlpm2A6POSpXkA2UwOH37G5ztg=; b=dSeYD78HMfqm+66GuwnReEOIHMAp1yNfnRrqjTs1VDsH6Ke0KyXXQVma Xx8sjWoyv+6Y8u3KxoHQFyp61u7higPLiakBMzclZXi8tNNq8SXD1eJt2 KgXUnvb3PpWqQlqQftF/ErPFs3S+lhgBM+XXcaa64senIHyUyElyuesIw w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsGAKKPDFOtJV2Y/2dsb2JhbABWA4JCRDtXq0CNOIgJT4EYFnSCJQEBAQQBAQEXA0oHCxACAQgRBAEBIQEGByEGCxQJCAIECgQFCRKHVgMRDb9IDYZxF4xPgUQBAS0SDAQGAQYLgxOBFASWR4FtgTKLLoVHgy2BcTk X-IronPort-AV: E=Sophos; i="4.97,540,1389744000"; d="scan'208,217"; a="22998448" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 25 Feb 2014 12:48:07 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1PCm6An000445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 12:48:07 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.236]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 06:48:06 -0600 From: "Pal Martinsen (palmarti)" To: Karl Stahl Thread-Topic: [tram] [rtcweb] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: AQHPMa7rPKSdbWG+c0KNNHF0bIvNNJrGUOCA Date: Tue, 25 Feb 2014 12:48:06 +0000 Message-ID: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ee01cf31ae$e296d500$a7c47f00$@stahl@intertex.se> In-Reply-To: <04ee01cf31ae$e296d500$a7c47f00$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.100.226] Content-Type: multipart/alternative; boundary="_000_B788D545BDC047A7BE1B76E2A5F60509ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/1lH12S2leiQZK63sg_ttK17QfqY Cc: Oleg Moskalenko , Alan Johnston , "rtcweb@ietf.org" , "tram@ietf.org" , "Yoakum, John H \(John\)" Subject: Re: [tram] [rtcweb] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 12:48:14 -0000 --_000_B788D545BDC047A7BE1B76E2A5F60509ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 24 Feb 2014, at 23:22 pm, Karl Stahl > wrote: Hi P=E5l, You did not comment nor answer, in response to any of: http://www.ietf.org/mail-archive/web/tram/current/msg00275.html http://www.ietf.org/mail-archive/web/tram/current/msg00273.html Sorry about that. I did not notice any clear items to answer or comment on. whether step D) can obsolete step C) (DISCUSS/MALICE) by allowing the appli= cation/browser to transfer relevant real-time traffic information (types an= d bandwidth) into every RTP package by using the already IETF standardized = RTP extension header RCF 5285, which could be used by any current or future= Internet (including OTT) network where WebRTC real-time traffic may flow. = It seems to have been standardized already 2008 to allow such usage. draft-martinsen-tram-discuss is intended to solve internal application stre= am prioritisation pr flow, i.e. it is more important for me to get the vide= o stream across than my application stream at this moment in time. Its inte= ntion is to describe the 5-topple the STUN message was sent on. Moving to a pr packet prioritisation is interesting as it can solve the bun= dle problem, and mark the relative importance of specific video frames (I-F= rames for example). Since its pr packet the network element might not keep = stream state so it might be easier that way. But the information needs to b= e in a fixed offset for quick network element processing. And we want to de= scribe other streams than just RTP. That makes RTP header extensions unsuit= able. QoS related step C) draft-martinsen-tram-discuss can then be taken out of T= RAM, and step D) (that was never intended to be handled by TRAM anyway) wil= l be handled elsewhere. I was hoping to argue that the draft is only new signalling of old concepts= (DSCP and ECN). In the end it is the WG that decides if there is enough in= terest. I have repeated my suggestion to RTCWEB WG from the October discussions on = the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-arch= ive/web/rtcweb/current/msg09129.html to introduce the QoS related step D) i= nto draft-ietf-rtcweb-rtp-usage suggesting usage of RFC 5285, where traffic= information in RTP packets simply would be filled by any browser under any= OS. Without step B), TRAM =93Enforcing the real-time traffic through the offere= d/discovered TURN servers=94, the real-time traffic may happen through the = IP default gateways often congested by data traffic and QoS insensitive str= eaming video and file sharing. Without specific QoS methods at those points= , the network raw bandwidth capacity may have to be 10-folded to achieve su= fficient QoE when WebRTC usage becomes popular. Methods like DISCUSS addres= ses such things occurring when STUN instead TURN is used (by allowing flows= into such congestion points), but only provides direct traffic info for ou= tgoing (not incoming) real-time traffic and locally, therefore are not even= applicable to reservation type of networks like Cable Networks and Mobile = OTT. If both clients supports draft-martinsen-tram-discuss you would get an bi-d= irectional end to end description of the flow that works through NAT. The information in the STUN packet can be used to remark DSCP bits to whate= ver values that is of best use for the network the packet is flowing though= . I dont see how TURN gives that ability. Once the channel is bound you only = have a channel number in front of the UDP payload. And TURN is designed to = carry alls sort of traffic. For this to work there must be some sort of onl= y webRTC traffic is allowed through this TURN server. (And Ill bet bitorren= t or others find a way to mimic webRTC to set up only a data channel..) That would leave certain network types to investing in raw bandwidth increa= se, instead of simply borrowing the bandwidth (from much larger data traffi= c and QoS insensitive streaming video and file sharing at no adverse effect= ) and making that borrowed no-cost bandwidth very valuable for the carriers= when delivering to their customers. I know a few of you Cisco guys are among the ones that have been fighting a= gainst the general =93it is all about bandwidth=94 and =93it will go away w= ith time=94-attitude within IETF work, e.g. see http://www.ietf.org/mail-ar= chive/web/rtcweb/current/msg09031.html, but the pointers given in the curre= nt QoS discussion within TRAM: (i) will *not allow* ISP=92s to use already available and currently deploya= ble quality IP pipes for real-time traffic to also be used for WebRTC gener= ated real-time traffic. (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OT= T) to borrow bandwidth from data traffic and QoS insensitive streaming vide= o and file sharing. All networks will *also be inhibited* from the very com= mon and used method of simply providing an extra IP pipe (often provided ov= er the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) Newer, fiber only type of networks, can still borrow bandwidth at no extra = cost, *by proprietary usage* of RFC 5285 by browsers. (iii) will leave most ISPs to *only use* raw bandwidth capacity increase th= at may has to be 10-folded to reach sufficient QoE when WebRTC usage become= s popular (if at all possible, since unmanaged IP pipes intermittently are = filled, whatever bandwidth is available). Further explainations about QoS methods and their implementation were given= a few days ago in: http://www.ietf.org/mail-archive/web/tram/current/msg00274.html (i), (ii) and (iii) will *seriously delay* usage of telepresence capable an= d quality demanding WebRTC (bandwidth being around 30 times higher over bes= t effort Internet, than telephony over quality managed networks) and will *= vastly increase cost* for ISPs to offer WebRTC with good QoE. Below you are giving pointers saying =93They are currently working on a pro= blem-statement draft and a use-case draft, any input to those would be very= helpful.=94 Those are unnecessary, risking leading to (i), (ii) and (iii) = above. We find them quite useful. It allows us to engage with potential users and = see if there are real problems to solve. If the customer/users do not see a= problem there is little incentive for us to invest in creating a solution = that nobody wants. That said, it is always the danger of crating a to compl= icated solution that solves to many problems. So are pointers such as: =93RMCAT where congestion avoidance for RTP is bei= ng developed=94. TRAMs Milestone 3 is for the purpose of directing real-tim= e traffic where congestion control isn=92t already in place. UsingRFC 5285 = available since 2008, to fill traffic information in RTP packets (step D)) = is probably a necessity for most future =93congestion control=94 discussed. There are some good example of RTP header extension usage. For example draf= t-avtext-berger-framemarking. But that information may very well be encrypt= ed and unavailable to the network element. .-. P=E5l-Erik This chicken-and-egg circular also applies to RTCWEB direction of QoS issue= s to: http://datatracker.ietf.org/doc/draft-dhesikan-tsvwg-rtcweb-qos focusing on DSCP-mapping without even mentioning RFC 5285 available since 2= 008, to fill traffic information in RTP packets where it is a necessity an= d will allow: (1) applications to directly convey QoS related real-time traffic info to t= he network at points where RTP flow is directed to by TRAM Milstone 3, to b= e used by *any network element implementing any suitable QoS methods for th= e particular network* for (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), under= *all* OSs, and *all* current and future IP networks (3) *without* having to be forced into application specific networks (PSTN,= IMS) instead of using the Internet (including OTT). The only activity required, is to call for ISPs=92 review whether the traff= ic information transferred by RFC 5285 is sufficient for current and future= needs in their network as suggested in http://www.ietf.org/mail-archive/we= b/rtcweb/current/msg09129.html =85two parameters (e.g. two bytes each) are encoded into the RTP header ext= ension: A) The maximum bandwidth requirement: Two bytes could contain everything fr= om some bps for real-time text to Gbps for future 3D supersize telepresence= =85 on a logarithmic scale. B) The quality characteristics for the stream, with the highest bit set to = 1, we could allocate a bit each for quality type e.g: Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensit= ive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X,= Variation Y, that could be combined as required to describe the stream. And with highest bit set to 0, there could instead be a number for special = usage that does not fit the general description of the individual bits. Then this could be assigned numbers to have the RFC in place. With TRAM milestone 3 also place, market forces will drive ISPs and browser makers to implement just that, wi= thout even having it MUST-established. =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari comes w= ith much better QoE?=94 and vice versa. l Please see further emails soon following this one, for details and history. /Karl Fr=E5n: tram [mailto:tram-bounces@ietf.org] F=F6r Pal Martinsen (palmarti) Skickat: den 21 februari 2014 10:37 Till: tram@ietf.org Kopia: Karl Stahl; Oleg Moskalenko; Alan Johnston; Yoakum, John H (John) =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Hi, I agree the full QoS discussion should _not_ happen in TRAM. If you are int= erested in helping out in that area I suggest you looking into the AEON mai= ling list at: https://www.ietf.org/mailman/listinfo/aeon . They are current= ly working on a problem-statement draft and a use-case draft, any input to = those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-u= se-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-= 00). That said, STUN have a few nice characteristics that makes it a perfect can= didate for transporting some of the QoS information. IMHO that would be ex= tending the STUN spec and should be within the TRAM charter. The main goal= of draft-martinsen-tram-discuss was to show how already existing QoS mecha= nisms could be transported with STUN to provide more value, and to start th= e discussion if TRAM is the appropriate place to have those on the wire for= mat discussions. .-. P=E5l-Erik On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) > wrote: +1 I fully agree with the comments that QOS should be a low priority for the i= nitial focus of the TRAM efforts. There are other groups doing QOS work an= d frankly I engage in WebRTC multimedia interactions daily over the Interne= t, enterprise VPNs, and various combinations and seldom suffer egregious qu= ality issues. I am more concerned about carriers doing things to regulate = or degrade WebRTC flows than a failure of existing Internet mechanisms to e= nable them. Significant focus on QOS before we better enable TURN to be easily used in = a browser environment taking advantage or normal web characteristics (as op= posed to historic telephony constructs) would seem to be highly distracting= at this point. Cheers, John AVAYA 1.919.425.8446 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.t= xt On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston > wrote: Personally, I am not sure how much QoS is actually in scope for TRAM. Have = you been following RMCAT where congestion avoidance for RTP is being develo= ped? I see some overlap in your goals and the goals of that work. - I'd concentrate on the TURN application-level functionality, for now, and I= 'd leave QoS for the future discussions. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram --_000_B788D545BDC047A7BE1B76E2A5F60509ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 24 Feb 2014, at 23:22 pm, Karl Stahl <karl.stahl@intertex.se> wrote:


Sorry about that. I did not notice any clear items to answer or commen= t on. 

whether step D) can obsolete step C) (DISCUSS/MALICE) by = allowing the application/browser to transfer relevant real-time traffic inf= ormation (types and bandwidth) into every RTP package by using the already IETF standardized RTP extension hea= der RCF 5285, which could be used by any current or future Internet (includ= ing OTT) network where WebRTC real-time traffic may flow. It seems to have = been standardized already 2008 to allow such usage.
 
draft-martinsen-tram-discuss is intended to solve internal application= stream prioritisation pr flow, i.e. it is more important for me to get the= video stream across than my application stream at this moment in time. Its= intention is to describe the 5-topple the STUN message was sent on. 

Moving to a pr packet prioritisation is interesting as it can solve th= e bundle problem, and mark the relative importance of specific video frames= (I-Frames for example). Since its pr packet the network element might not = keep stream state so it might be easier that way. But the information needs to be in a fixed offset for qui= ck network element processing. And we want to describe other streams than j= ust RTP. That makes RTP header extensions unsuitable. 

QoS related step C)=  draft-martinsen-tram-discuss can then be taken out of TRAM, and step D) (that was never intended to be hand= led by TRAM anyway) will be handled elsewhere.

I was hoping to argue that the draft is only new signalling of old con= cepts (DSCP and ECN). In the end it is the WG that decides if there is enou= gh interest. 

 
I have repeated my suggestion to RTCWEB WG from the Octob= er discussions on the relevant <= /span>[rtcweb] [avtext] [mmusic]&nb= sp;lists http://www.ietf.org/mail-a= rchive/web/rtcweb/current/msg09129.html to introduce the QoS related step D) into draft-ietf-rtcweb-rtp-usage suggesting usage of RFC 5285, where traffic information in RTP packets simply would be filled by a= ny browser under any OS.
 
Without step B), TRAM =93Enforci= ng the real-time traffic through the offered/discovered TURN servers=94, the = real-time traffic may happen through the IP default gateways often congeste= d by data traffic and QoS insensitive streaming video and file sharing. Wit= hout specific QoS methods at those points, the network raw bandwidth capacity may have to be 10-folded to ach= ieve sufficient QoE when WebRTC usage becomes popular. Methods like DISCUSS= addresses such things occurring when STUN instead TURN is used (by allowin= g flows into such congestion points), but only provides direct traffic info for outgoing (not incoming) real-tim= e traffic and locally, therefore are not even applicable to reservation typ= e of networks like Cable Networks and Mobile OTT.

If both clients supports draft-martinsen-tram-discuss you would get an= bi-directional end to end description of the flow that works through NAT.<= /div>
The information in the STUN packet can be used to remark DSCP bits to = whatever values that is of best use for the network the packet is flowing t= hough.

I dont see how TURN gives that ability. Once the channel is bound you = only have a channel number in front of the UDP payload. And TURN is designe= d to carry alls sort of traffic. For this to work there must be some sort o= f only webRTC traffic is allowed through this TURN server. (And Ill bet bitorrent or others find a way to m= imic webRTC to set up only a data channel..)

 
That would leave certain network types to investing in ra= w bandwidth increase, instead of simply borrowing the bandwidth (from much = larger data traffic and QoS insensitive streaming video and file sharing at no adverse effect) and making that bor= rowed no-cost bandwidth very valuable for the carriers when delivering to t= heir customers.
I know a few of you Cisco guys are among the ones that ha= ve been fighting against the general =93it is all about bandwidth=94 and = =93it will go away with time=94-attitude within IETF work, e.g. see http://www.ietf.org/mai= l-archive/web/rtcweb/current/msg09031.html, but the pointers given in the current QoS discussion within TRAM:
 
(i) will *not allow* ISP=92s to use already availa= ble and currently deployable quality IP pipes for real-time traffic to also= be used for WebRTC generated real-time traffic.
 
(ii) will *not allow* some network types (e.g. Cab= le Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS i= nsensitive streaming video and file sharing. All networks will *also be inhibited* from the very common= and used method of simply providing an extra IP pipe (often provided over = the same wire but level-2 separated) dedicated for real-time usage
(*by resisting TRAM implementation of step B*)
Newer, fiber only type of networks, can still borrow band= width at no extra cost, *by proprietary usage* of RFC 5285 by browse= rs.
 
(iii) will leave most ISPs to *only use* raw bandw= idth capacity increase that may has to be 10-folded to reach sufficient QoE= when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes intermittently are filled, whate= ver bandwidth is available).
 
Further explainations about QoS methods and their impleme= ntation were given a few days ago in:
 
(i), (ii) and (iii) will *seriously delay* usage o= f telepresence capable and quality demanding WebRTC (bandwidth being around= 30 times higher over best effort Internet, than telephony over quality managed networks) and will *vastly increase= cost* for ISPs to offer WebRTC with good QoE.
 
Below you are giving pointers saying =93They are currently working on a problem-statement draft and a us= e-case draft, any input to those would be very helpful.=94 Those are unnecessary, risking l= eading to (i), (ii) and (iii) above.
 
We find them quite useful. It allows us to engage with potential users= and see if there are real problems to solve. If the customer/users do not = see a problem there is little incentive for us to invest in creating a solu= tion that nobody wants. That said, it is always the danger of crating a to complicated solution that solves t= o many problems.  

So are pointers such as: =93R= MCAT where congestion avoidance for RTP is being developed=94. TRAMs Milestone 3 is for the purpose of directing real-time traffic where = congestion control isn=92t already in place. Using= RFC 5285 available since 2008, to fill traffic information in RTP packets (step D)) is probably a necessity for m= ost future =93congestion control=94 discussed.
 
There are some good example of RTP header extension usage. For example=  draft-avtext-berger-framemarking. But that information may very well = be encrypted and unavailable to the network element.


.-.
P=E5l-Erik







This chicken-and-egg circular also applies to RTCWEB dire= ction of QoS issues to:
focusing on DSCP-mapping without even mentioning RFC 5285= available since 2008, to fill traffic information in RTP packets where it =  is a necessity and will allow:
(1) applications to directly convey QoS related real-time= traffic info to the network at points where RTP flow is directed to by TRA= M Milstone 3, to be used by *any network element implementing any suitable QoS methods for the particular n= etwork* for
(2) *all* WebRTC browsers *and* dedicated c= lients (not using WebRTC), under *all* OSs, and *all* current= and future IP networks
(3) *without*&nb= sp;having to be forced into application specific networks (PSTN, IMS) instead of using = the Internet (including OTT).
 
The only activity required, is to call for ISPs=92 review= whether the traffic information transferred by RFC 5285 is sufficient for = current and future needs in their network as suggested in http://www.ietf.org/mail-a= rchive/web/rtcweb/current/msg09129.html
<snip>
=85two parameters (e.g. two bytes each) are encoded into the RTP heade= r extension:
 
A) The maximum bandwidth requirement: Two bytes could contain everythi= ng from some bps for real-time text to Gbps for future 3D supersize telepre= sence=85 on a logarithmic scale.
 
B) The quality characteristics for the stream, with the highest bit se= t to 1, we could allocate a bit each for quality type e.g:
Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Ins= ensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioriti= ze X, Variation Y, that could be combined as required to describe the stream.
 
And with highest bit set to 0, there could instead be a number for spe= cial usage that does not fit the general description of the individual bits= .
</snip>
 
Then this could be assigned numbers to have the RFC in pl= ace.
With TRAM milestone 3 also place,
market forces will drive ISPs and browser makers to imple= ment just that, without even having it MUST-established.<= /div>
=93Who does not want a =93WebRTC-Ready=94 Internet access= ?=94 and
=93Who wants to use Chrome, if Firefox, Internet Explorer= or Safari comes with much better QoE?=94 and vice versa.=
 l
Please see further emails soon following this one, for de= tails and history.
 
/Karl
 
Fr=E5n= : tram [mailto:tram-bounces@ietf.org]=  F=F6r Pal Martinsen (palmarti)
Skickat: den 21 fe= bruari 2014 10:37
Till: tram@ietf.org
Kopia: Karl Stahl;= Oleg Moskalenko; Alan Johnston; Yoakum, John H (John)
=C4mne: Re: [tram]= I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
 
Hi,
 
I agree the full QoS discussion should _not_ happen in TRAM. If you are int= erested in helping out in that area I suggest you looking into the AEON mai= ling list at: https://www.ietf.org/ma= ilman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case dra= ft, any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01= , http://to= ols.ietf.org/html/draft-eckel-aeon-problem-statement-00).
 
That said, STUN have a few nice characteristics that makes it a perfect can= didate for transporting some of the QoS information.  IMHO that would = be extending the STUN spec and should be within the TRAM charter.  The= main goal of draft-martinsen-tram-discuss was to show how already existing QoS mechanisms could be transported with = STUN to provide more value, and to start the discussion if TRAM is the appr= opriate place to have those on the wire format discussions.
 
.-.
P=E5l-Erik
 
 
 
 
 
 
On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <yoakum= @avaya.com> wrote:


+1
I fully agree with the comments that QOS sh= ould be a low priority for the initial focus of the TRAM efforts.  The= re are other groups doing QOS work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterp= rise VPNs, and various combinations and seldom suffer egregious quality iss= ues.  I am more concerned about carriers doing things to regulate or d= egrade WebRTC flows than a failure of existing Internet mechanisms to enable them.
 
Significant focus on QOS before we better e= nable TURN to be easily used in a browser environment taking advantage or n= ormal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at t= his point.
 
 
Cheers,
John=
 
AVAYA
1.919.425.8446
 
From:&nbs= p;tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko
Sent: Thursday, Fe= bruary 20, 2014 12:43 PM
To: Alan Johnston<= br> Cc: Karl Stahl; tram@ietf.org
Subject: Re: [tram= ] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt
 
 

 

 
 
 
Personally, I am not sure how much QoS is actually in = scope for TRAM. Have you been following RMCAT where congestion avoidance fo= r RTP is being developed?  I see some overlap in your goals and the go= als of that work.
-
 
 

I'd concentrate on the TURN application-level function= ality, for now, and I'd leave QoS for the future discussions.


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

--_000_B788D545BDC047A7BE1B76E2A5F60509ciscocom_-- From nobody Tue Feb 25 06:31:12 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157791A0223; Mon, 24 Feb 2014 14:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001] autolearn=ham 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 a_js_i8kzZ_5; Mon, 24 Feb 2014 14:52:15 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 732C51A01B7; Mon, 24 Feb 2014 14:52:14 -0800 (PST) Received: from [81.187.2.149] (port=34990 helo=[192.168.0.15]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WI4Na-0006F3-Us; Mon, 24 Feb 2014 22:52:10 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_88B6A6AA-91D0-4A95-AD5B-F4C66DD48D6D" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Colin Perkins In-Reply-To: <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> Date: Mon, 24 Feb 2014 22:52:04 +0000 Message-Id: <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> To: Karl Stahl X-Mailer: Apple Mail (2.1827) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/tram/gVZZ26X51lEyJLvIcP_x5dtITr0 X-Mailman-Approved-At: Tue, 25 Feb 2014 06:31:11 -0800 Cc: Magnus Westerlund , rtcweb@ietf.org, tram@ietf.org, Harald Alvestrand Subject: Re: [tram] [rtcweb] Payload Types assignments X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 22:52:20 -0000 --Apple-Mail=_88B6A6AA-91D0-4A95-AD5B-F4C66DD48D6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Karl, I strongly disagree with this suggestion. An RTP header extension, = located at an unknown and variable offset into a packet that does not = have a well-defined magic number in the header, indicated using a = dynamically assigned identifier that is conveyed in an out-of-band and = encrypted signalling channel, is not an appropriate place to put QoS = information that has to be processed on a per-packet basis. If you want = DiffServ, you know where to find it. Colin On 24 Feb 2014, at 22:09, Karl Stahl wrote: > I suggest to the RTCWEB WG that the below from the September and = October discussions on the relevant [rtcweb] [avtext] [mmusic] lists = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is = introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC 5285, to = allow: > =20 > (1) WebRTC applications to directly convey QoS related real-time = traffic info to the network at points where RTP flow is directed to by = TRAM Milstone 3, to be used by *any network element implementing any = suitable QoS methods for the particular network* for > (2) *all* WebRTC browsers *and* clients, under *all* OSs, and *all* = current and future IP network, to achieve best QoE > (3) *without* having to force WebRTC into application specific = networks (such as IMS) instead of using the Internet (including OTT). > =20 > The only further activity required, is to call for ISPs=92 to review = whether the traffic information transferred by RFC 5285 is sufficient = for current and future needs in their network as suggested in below = repeated = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html > > =85two parameters (e.g. two bytes each) are encoded into the RTP = header extension: > =20 > A) The maximum bandwidth requirement: Two bytes could contain = everything from some bps for real-time text to Gbps for future 3D = supersize telepresence=85 on a logarithmic scale. > =20 > B) The quality characteristics for the stream, with the highest bit = set to 1, we could allocate a bit each for quality type e.g: > Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay = Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = Prioritize X, Variation Y, that could be combined as required to = describe the stream. > =20 > And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the = individual bits. > > =20 > Then this could be assigned numbers to have an RFC in place. > =20 > With TRAM milestone 3 also place, > market forces will drive ISPs and browser makers to implement just = this, without even having it MUST-established. > =20 > =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and > =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. > =20 > Please see further emails soon following this one, for details and = history. > =20 > /Karl > =20 > =20 > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Karl Stahl > Skickat: den 22 oktober 2013 16:37 > Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus Westerlund' > Kopia: 'Colin Perkins' > =C4mne: [rtcweb] [avtext] Payload Types assignments was Re: SV: = [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 > =20 > Harald, I mostly agree with the quality requirements of different = real-time traffic that the WebRTC browser/application may use. But = rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it. =20 > =20 > There is actually a good way to show these needs to the network = (without using the PT, or diffserv bits, which aren=92t sufficient = anyway). > =20 > Let's use the RTP header extension field that also is visible outside = the encrypted payload. A week ago came = http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that = outlines the usage of the extension field for classification of traffic! = This document does not yet outline what to put in there and how to = encode it though. > =20 > Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 = discusses other webrtc usages of the RTP header extension in 5.2 (there = can be many header extensions according to RFC 5285) and in 9 there is = "WebRTC Use of RTP: Future Extensions". > =20 > So, it looks obvious to use the RTP header extension to show the = characteristics and bandwidth requirements to the network. It should not = introduce any backward incompatibilities either. > =20 > Such marking is done in every RTP packet so it can be set individually = for each stream and could even be changed during a session (e.g. when = limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies = how RTP extension header usage can be negotiated in SDP. I think this = could be easily done by the WebRTC browser for "all current and future = needs" if properly specified now. > =20 > I suggest that two parameters (e.g. two bytes each) are encoded into = the RTP header extension: > =20 > A) The maximum bandwidth requirement: Two bytes could contain = everything from some bps for real-time text to Gbps for future 3D = supersize telepresence=85 on a logarithmic scale. > =20 > B) The quality characteristics for the stream, with the highest bit = set to 1, we could allocate a bit each quality e.g: > Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay = Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = Prioritize X, Variation Y, that could be combined as required to = describe the stream. > =20 > And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the = individual bits. > =20 > Please note the totally different requirements a diffserv and an RSVP = network have to know, so let=92s put all into these bytes. (E.g. a = diffserv network don't need the bandwidth usage, but RSVP reservation = networks (e.g. cable and 3G/4G OTT) do. There one should initially = reserve the maximum bandwidth indicated, but can later re-reserve.) > =20 > /Karl > =20 > PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94; > However that seems to apply to the TURN server allocation request and = would therefore: > --- Apply to the whole UDP flow, and could not be set for each stream = individually (with different requirements), and > --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) > However the quality attributes conveyed and their encoding may be = considered. > =20 > This is 2.2.2.19 MS-Service Quality Attribute from > http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20= > =20 > MS-Service Quality Attribute > The MS-Service Quality attribute is used to convey information about = the data stream that the protocol client is intending to transfer over = an allocated port. The protocol client SHOULD<21> include this attribute = as part of an Allocate request message. A TURN server SHOULD use the = information in this attribute to make decisions about resource = allocation, bandwidth prioritization, and data delivery methods. If the = attribute is not present in the Allocate request message, the TURN = server SHOULD assume that the data stream is audio with best effort = delivery. The format of this attribute is as follows... > ... > The following stream types are supported in this extension. All other = stream types are reserved for future use. > =A7 "0x0001": Audio > =A7 "0x0002": Video > =A7 "0x0003": Supplemental Video > =A7 "0x0004": Data > Service Quality (2 bytes): The service quality level required by the = protocol client for the stream. > The following service quality levels are supported in this extension. = All other service quality levels are reserved for future use. > =A7 "0x0000": Best effort delivery. > =A7 "0x0001": Reliable delivery. > =20 > =20 > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Harald Alvestrand > Skickat: den 8 oktober 2013 13:01 > Till: rtcweb@ietf.org > =C4mne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 > =20 > On 10/08/2013 09:17 AM, Karl Stahl wrote: > > Hej Magnus, > >=20 > >> Also, are you really interested in knowing that it is VP9 vs H.264, > >> isn't > > the questions this is video of this priority that is important? > >> I think you need to more carefully consider what are the goals you > >> try to > > achieve them. > >=20 > > Actually, my concern is to get an idea of the maximum bandwidth that > > could be required for a WebRTC (ICE) setup media flow. Both voice = and > > video should be prioritized over data (their individual priority is = of > > less importance as long as there is sufficient bandwidth for both). > =20 > You don't know that without knowing what the application is for. > In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. > =20 > >=20 > > With diffserv you don=92t need to know the bandwidth requirement, = but > > with RSVP reservation (like in cable and mobile networks) you need = to > > know how much to reserve. Voice is like 100's kbit/s, video VP8 or > > H.264 is like 3,5 mbps. > =20 > Again, without knowing the application, you don't know that. > The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is = completely different from that of a talking head, which is again = completely different from a high-movement scene. > =20 > >=20 > > To add to the complication of codec variants, the video codecs in > > question for WebRTC have variable bandwidth, and when there is a = poor > > connection we see Chrome reducing the video window size to reduce = the bandwidth used... > >=20 > > I think the payload type field at best can reflect a maximum = bandwidth > > to initially reserve bandwidth for, and thereafter make new > > reservations if the bandwidth changes during the call. So could we > > change RTP to show maximum bandwidth instead of payload type in that > > field outside the encrypted payload :) ... Or maybe that is not a = joke? > =20 > I think these ruminations only lead to one conclusion: > =20 > You can't tell what the needed bandwidth is up front without asking = the application. > You can't tell what the right priority ranking is without asking the = application. > =20 > If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_88B6A6AA-91D0-4A95-AD5B-F4C66DD48D6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Karl,

I strongly disagree with = this suggestion. An RTP header extension, located at an unknown and = variable offset into a packet that does not have a well-defined magic = number in the header, indicated using a dynamically assigned identifier = that is conveyed in an out-of-band and encrypted signalling channel, is = not an appropriate place to put QoS information that has to be processed = on a per-packet basis. If you want DiffServ, you know where to find = it.

Colin


= On 24 Feb 2014, at 22:09, Karl Stahl <karl.stahl@intertex.se> = wrote:

I suggest to the RTCWEB WG that the below from the = September and October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = is introduced into draft-ietf-rtcweb-rtp-usage= for usage of RFC 5285, to = allow:

 

(1) WebRTC applications to directly convey QoS related = real-time traffic info to the network at points where RTP flow is = directed to by TRAM Milstone 3, to be used by *any network element = implementing any suitable QoS methods for the particular network* = for

(2) *all* WebRTC browsers *and* clients, = under *all* OSs, and *all* current and future IP network, = to achieve best QoE

(3) *without* having to force WebRTC into application specific = networks (such as IMS) instead of using the Internet (including = OTT).

 

The only further activity required, is to call for = ISPs=92 to review whether the traffic information transferred by RFC = 5285 is sufficient for current and future needs in their network as = suggested in below repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip>

=85two parameters (e.g. two bytes each) are encoded into the RTP = header extension:

 

A) The maximum bandwidth requirement: Two bytes could contain = everything from some bps for real-time text to Gbps for future 3D = supersize telepresence=85 on a logarithmic = scale.

 

B) The quality characteristics for the stream, with the highest = bit set to 1, we could allocate a bit each for quality type = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay = Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = Prioritize X, Variation Y, that could be combined as required to = describe the stream.

 

And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the = individual bits.

</snip>

 

Then this could be assigned numbers to have an RFC in = place.

 

With TRAM milestone 3 also place, =

market forces will drive ISPs and browser makers to = implement just this, without even having it = MUST-established.

 

=93Who does not want a =93WebRTC-Ready=94 Internet = access?=94 and

=93Who wants to use Chrome, if Firefox, Internet = Explorer or Safari comes with much better QoE?=94 and vice = versa.

 

Please see further emails soon following this one, for = details and history.

 

/Karl

 

 

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org= ] F=F6r Karl Stahl
Skickat: den 22 oktober 2013 = 16:37
Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus = Westerlund'
Kopia: 'Colin Perkins'
=C4mne: [rtcweb] = [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

Harald, I mostly agree with = the quality requirements of different real-time traffic that the WebRTC = browser/application may use. But rather than asking the application, = let's convey the bandwidth and priority requirements to the network. = Just like with the Payload type (that is hard to squeeze that = information into) it must be visible to the network (and not changed by = the network, like diffserv bits are). Such marking must also be = available for incoming traffic, which is especially important in RSVP = type of networks, that has to reserve bandwidth for it. =  

 

There is actually a good way to show these needs to the = network (without using the PT, or diffserv bits, which aren=92t = sufficient anyway).

 

Let's use the RTP header extension field that also is = visible outside the encrypted payload. A week ago came ht= tp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 =  that outlines the usage of the extension field for classification = of traffic! This document does not yet outline what to put in there and = how to encode it though.

 

Today's http://= tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other = webrtc usages of the RTP header extension in 5.2 (there can be many = header extensions according to RFC 5285) and in 9 there is "WebRTC Use = of RTP: Future Extensions".

 

So, it looks obvious to use = the RTP header extension to show the characteristics and bandwidth = requirements to the network. It should not introduce any backward = incompatibilities either.

 

Such marking is done in = every RTP packet so it can be set individually for each stream and could = even be changed during a session (e.g. when limiting the bandwidth based = on RTCP feedback). RFC 5286 also specifies how RTP extension header = usage can be negotiated in SDP. I think this could be easily done by the = WebRTC browser for "all current and future needs" if properly specified = now.

 

I suggest that two parameters (e.g. two bytes each) are = encoded into the RTP header extension:

 

A) The maximum bandwidth = requirement: Two bytes could contain everything from some bps for = real-time text to Gbps for future 3D supersize telepresence=85 on a = logarithmic scale.

 

B) The quality characteristics for the stream, with the = highest bit set to 1, we could allocate a bit each quality = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, = Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable = Delivery, Prioritize X, Variation Y, that could be combined as required = to describe the stream.

 

And with highest bit set to = 0, there could instead be a number for special usage that does not fit = the general description of the individual bits.

 

Please note the totally = different requirements a diffserv and an RSVP network have to know, so = let=92s put all into these bytes. (E.g. a diffserv network don't need = the bandwidth usage, but RSVP reservation networks (e.g. cable and 3G/4G = OTT) do. There one should initially reserve the maximum bandwidth = indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft seems to have = done work in this field, defining a proprietary attribute =93MS Service = Quality=94;

However that = seems to apply to the TURN server allocation request and would = therefore:

--- Apply to = the whole UDP flow, and could not be set for each stream individually = (with different requirements), and

--- Does not handle the bandwidth requirement for = incoming real-time traffic (required to reserve in RSVP type of = networks)

However the = quality attributes conveyed and their encoding may  be = considered.

 

This is 2.2.2.19 MS-Service Quality Attribute from =

http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx<= /a> 

 

MS-Service = Quality Attribute

The = MS-Service Quality attribute is used to convey information about the = data stream that the protocol client is intending to transfer over an = allocated port. The protocol client SHOULD<21> include this = attribute as part of an Allocate request message. A TURN server SHOULD = use the information in this attribute to make = decisions about resource allocation, bandwidth prioritization, and data = delivery methods. If the attribute is not present in the Allocate = request message, the TURN server SHOULD assume that the data stream is = audio with best effort delivery. The format of this attribute is as = follows...

...

The following = stream types are supported in this extension. All other stream types are = reserved for future use.

=A7 "0x0001": = Audio

=A7 = "0x0002": Video

=A7 "0x0003": Supplemental = Video

=A7 = "0x0004": Data

Service = Quality (2 bytes): The service quality level required by the protocol = client for the stream.

The following = service quality levels are supported in this extension. All other = service quality levels are reserved for future use.

=A7 = "0x0000": Best effort delivery.

=A7 = "0x0001": Reliable delivery.

 

 

-----Ursprungligt = meddelande-----

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org= ] F=F6r Harald Alvestrand

Skickat:= den 8 oktober 2013 13:01

Till: = rtcweb@ietf.org

=C4mne: Re: [rtcweb] Payload = Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, Karl = Stahl wrote:

> Hej Magnus,

> 

>> Also, are you = really interested in knowing that it is VP9 vs H.264, =

>> isn't

> the questions this is = video of this priority that is important?

>> I think you need to = more carefully consider what are the goals you

>> try = to

> achieve them.

> 

> Actually, my concern is = to get an idea of the maximum bandwidth that

> could be required for a = WebRTC (ICE) setup media flow. Both voice and

> video should be = prioritized over data (their individual priority is of =

> = less importance as long as there is sufficient bandwidth for = both).

 

You don't know that without knowing what the application = is for.

In, for instance, a shooter game with voice backchannels, = the movement and event information (data) is MORE time sensitive than = the voice data.

 

> 

> With diffserv you don=92t= need to know the bandwidth requirement, but

> with RSVP reservation = (like in cable and mobile networks) you need to

> know how much to = reserve. Voice is like 100's kbit/s, video VP8 or =

> = H.264 is like 3,5 mbps.

 

Again, without knowing the = application, you don't know that.

The application could decide = to use QCIF or HD, and the bandwidth variation of screencast = (semi-static with sudden, large changes) is completely different from = that of a talking head, which is again completely different from a = high-movement scene.

 

> 

> To add to the = complication of codec variants, the video codecs in =

> = question for WebRTC have variable bandwidth, and when there is a poor =

> = connection we see Chrome reducing the video window size to reduce the = bandwidth used...

> 

> I think the payload = type field at best can reflect a maximum bandwidth =

> = to initially reserve bandwidth for, and thereafter make new =

> = reservations if the bandwidth changes during the call. So could we =

> = change RTP to show maximum bandwidth instead of payload type in that =

> = field outside the encrypted payload :) ... Or maybe that is not a = joke?

 

I think these ruminations only lead to one = conclusion:

 

You can't tell what the needed bandwidth is up front = without asking the application.

You can't tell what the = right priority ranking is without asking the = application.

 

If you need to know the bandwidth or the priority up = front, the application has to tell you. Anything else is pure = heuristics.

 

_______________________________________________<= /span>

rtcweb mailing = list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




-- 
Colin Perkins



= --Apple-Mail=_88B6A6AA-91D0-4A95-AD5B-F4C66DD48D6D-- From nobody Tue Feb 25 06:31:42 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494B61A02D8; Mon, 24 Feb 2014 16:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 2Yac5EBfSkH2; Mon, 24 Feb 2014 16:20:38 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id 71AD11A0334; Mon, 24 Feb 2014 16:20:36 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402250120330129; Tue, 25 Feb 2014 01:20:33 +0100 From: "Karl Stahl" To: "'Alan Johnston'" , , , "'Bernard Aboba'" , "'David Singer'" , "'Harald Alvestrand'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: Date: Tue, 25 Feb 2014 01:20:30 +0100 Message-ID: <050401cf31bf$64ae8ff0$2e0bafd0$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0505_01CF31C7.C672F7F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac8vLpOyXxkwjXJURauBPg8ftk+5EwBhXIDA Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/52TXr8Zo6I6nlNYAwzEkuglm5Dk X-Mailman-Approved-At: Tue, 25 Feb 2014 06:31:39 -0800 Cc: "'Cullen Jennings \(fluffy\)'" , marc.robins@sipforum.org, 'Richard Shockey' , eburger@standardstrack.com, mary.barnes@polycom.com, 'Henning Schulzrinne' Subject: Re: [tram] [rtcweb] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 00:20:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0505_01CF31C7.C672F7F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alan, =20 I have in previous email http://www.ietf.org/mail-archive/web/tram/current/msg00304.html = suggested that both DISCUSS and draft-thomson-tram-turn-bandwidth-00.txt is taken = off the TRAM WG, but I think is shall be reintroduced after you clarify as = you do in=20 http://www.ietf.org/mail-archive/web/tram/current/msg00300.html : Hi Karl, Thanks for your comments and feedback on the draft. You are correct in saying that the BANDWIDTH extension is not about QoS. = It is about fairness between users of a TURN server, and a TURN server = being able to indicate rate limiting policy to users. in the draft. =20 The =93confusion=94 (to say least, see below) surrounding QoS within = IETF has lead me to protest and address the TRAM WG and RTCWEB WG and ADs with = the advise in = http://www.ietf.org/mail-archive/web/tram/current/msg00304.html : =93The TRAM WG and RTCWEB WG chairs and ADs are advised to review = whether IETF standard work in these WGs by contributors having an interest in more = than one of current or emerging: ISPs, carrier equipment vendors or web = browser makers, may discriminate any with an interest only in one of these. The = same should apply to non-activity by WG contributors to remedy such discrimination opened by allowed proprietary usage of RFCs such as RFC 5285.=94=20 =20 This is because the introduction of the QoS related usage of RFC 5285 = into draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 = objectives of TRAM, immediately would allow for: (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP = variants) to quickly allow us to finally enjoy the high quality and connectivity (NAT/firewall traversal) of real-time communication services now = possible, for =20 (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks=20 (3) *without* having to be forced into application specific networks = (PSTN, IMS) instead of the Internet (including OTT). =20 While the =93confusion=94 surrounding the QoS discussion in TRAM and = RTCWEB combined with the general QoS attitude within IETF =93it is all about bandwidth=94 and =93it will go away with time=94 otherwise: (i) will *not allow* ISP=92s to use already available and currently = deployable quality IP pipes for real-time traffic to also be used for WebRTC = generated real-time traffic. (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. That all networks *will be inhibited* from the = very common and used method of simply providing an extra IP pipe (often = provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) *while* newer, fiber only type of networks, still can borrow bandwidth = at no extra cost, *by proprietary usage* of RFC 5285 by browsers.=20 (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may have to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes = intermittently are filled, whatever bandwidth is available). =20 As Good doers, we should not allow this to happen. =20 /Karl =20 =20 Fr=E5n: Alan Johnston [mailto:alan.b.johnston@gmail.com]=20 Skickat: den 21 februari 2014 18:59 Till: Pal Martinsen (palmarti) Kopia: tram@ietf.org; Oleg Moskalenko; Karl Stahl; Yoakum, John H (John) =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 I guess the way I would expect this to progress is for QoS discussions = to happen in another working group. Once that other working group came to consensus on an approach, and if that approach required STUN or TURN extensions, then we would discuss mechanisms and possible milestones in TRAM. =20 - Alan - =20 On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) wrote: Hi, =20 I agree the full QoS discussion should _not_ happen in TRAM. If you are interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are currently working on a problem-statement draft and a use-case draft, any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). =20 That said, STUN have a few nice characteristics that makes it a perfect candidate for transporting some of the QoS information. IMHO that would = be extending the STUN spec and should be within the TRAM charter. The main goal of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and to start the discussion if TRAM is the appropriate place to have those on = the wire format discussions. =20 .-. P=E5l-Erik =20 =20 On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) < yoakum@avaya.com> wrote: +1 I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts. There are other groups doing QOS = work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs, and various combinations and seldom suffer egregious quality issues. I am more concerned about carriers doing = things to regulate or degrade WebRTC flows than a failure of existing Internet mechanisms to enable them. =20 Significant focus on QOS before we better enable TURN to be easily used = in a browser environment taking advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point. =20 =20 Cheers, John =20 AVAYA 1.919.425.8446 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 =20 =20 On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston < alan.b.johnston@gmail.com> wrote: =20 =20 =20 Personally, I am not sure how much QoS is actually in scope for TRAM. = Have you been following RMCAT where congestion avoidance for RTP is being developed? I see some overlap in your goals and the goals of that work. - =20 =20 I'd concentrate on the TURN application-level functionality, for now, = and I'd leave QoS for the future discussions. _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram =20 =20 ------=_NextPart_000_0505_01CF31C7.C672F7F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi= Alan,

 

I = have in previous email = http://www.ietf.org/mail-archive/web/tram/current/msg00304.html = suggested that both DISCUSS and draft-thomson-tram-turn-bandwidth-00.txt = is taken off the TRAM WG, but I think is shall be reintroduced after you = clarify as you do in

= http://www.ietf.org/mail-archive/web/tram/current/msg00300.html = :

Hi Karl, = Thanks for your comments and feedback on the = draft.

You = are correct in saying that the BANDWIDTH extension is not about QoS. =  It is about fairness between users of a TURN server, and a TURN = server being able to indicate rate limiting policy to users. = in= the draft.

 

Th= e “confusion” (to say least, see below) surrounding QoS = within IETF has lead me to protest and address th= e TRAM WG and RTCWEB WG and ADs with the advise in = http://www.ietf.org/mail-archive/web/tram/current/msg00304.html = :

&#= 8220;Th= e TRAM WG and RTCWEB WG chairs and ADs are advised to review whether = IETF standard work in these WGs by contributors having an interest in = more than one of current or emerging: ISPs, carrier equipment vendors or = web browser makers, may discriminate any with an interest only in one of = these. The same should apply to non-activity by WG contributors to = remedy such discrimination opened by allowed proprietary usage of RFCs = such as RFC 5285.&#= 8221;

 

Th= is is because the in= troduction of the QoS related usage of RFC 5285 into draft-ietf-rtcweb-rtp-usage in= combinations with the Milestone 3 objectives of TRAM, immediately would = allow for:

(1= ) = *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in = addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP = variants) to quickly allow us to finally enjoy the high quality and = connectivity (NAT/firewall traversal) of real-time communication = services now possible, for  

(2= ) = *all* WebRTC browsers *and* dedicated clients (not using = WebRTC), under *all* OSs, and *all* current and future IP = networks

(3= ) *without* ha= ving to be forced into application specific networks (PSTN, IMS) instead = of the Internet (including OTT).

 

Wh= ile the “confusion” surrounding the QoS discussion in TRAM = and RTCWEB combined with the ge= neral QoS attitude within IETF “it is all about bandwidth” = and “it will go away with time” ot= herwise:

(i= ) = will *not allow* ISP’s to use already available and = currently deployable quality IP pipes for real-time traffic to also be = used for WebRTC generated real-time traffic.

(i= i) = will *not allow* some network types (e.g. Cable Networks and = Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive = streaming video and file sharing. That all networks *will be = inhibited* from the very common and used method of simply providing = an extra IP pipe (often provided over the same wire but level-2 = separated) dedicated for real-time usage

(<= b>*by resisting TRAM implementation of step = B*)

*<= b>while* newer, fiber only type of networks, still can borrow = bandwidth at no extra cost, *by proprietary usage* of RFC 5285 by = browsers.

(i= ii) = will leave most ISPs to *only use* raw bandwidth capacity = increase that may have to be 10-folded to reach sufficient QoE when = WebRTC usage becomes popular (if at all possible, since unmanaged IP = pipes intermittently are filled, whatever bandwidth is = available).

 

As= Good doers, we should not allow this to happen.

 

/K= arl

 

 

Fr=E5n: Alan = Johnston [mailto:alan.b.johnston@gmail.com]
Skickat: den 21 = februari 2014 18:59
Till: Pal Martinsen = (palmarti)
Kopia: tram@ietf.org; Oleg Moskalenko; Karl Stahl; = Yoakum, John H (John)
=C4mne: Re: [tram] I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

 

I guess = the way I would expect this to progress is for QoS discussions to happen = in another working group.  Once that other working group came to = consensus on an approach, and if that approach required STUN or TURN = extensions, then we would discuss mechanisms and possible milestones in = TRAM.

 

- = Alan -

 

On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen = (palmarti) <palmarti@cisco.com> = wrote:

Hi,

 

I = agree the full QoS discussion should _not_ happen in TRAM. If you are = interested in helping out in that area I suggest you looking into the = AEON mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They = are currently working on a problem-statement draft and a use-case draft, = any input to those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon-use-cases-0= 1, http://tools.ietf.org/html/draft-eckel-aeon-problem-sta= tement-00).

 

That said, STUN have a few nice characteristics that = makes it a perfect candidate for transporting some of the QoS = information.  IMHO that would be extending the STUN spec and should = be within the TRAM charter.  The main goal = of draft-martinsen-tram-discuss was to show how already existing = QoS mechanisms could be transported with STUN to provide more value, and = to start the discussion if TRAM is the appropriate place to have those = on the wire format discussions.

 

.-.

P=E5l-Erik

 

 

On 20 Feb 2014, at 19:55 pm, = Yoakum, John H (John) <yoakum@avaya.com> wrote:



+1

I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts.  There are other groups = doing QOS work and frankly I engage in WebRTC multimedia interactions = daily over the Internet, enterprise VPNs, and various combinations and = seldom suffer egregious quality issues.  I am more concerned about = carriers doing things to regulate or degrade WebRTC flows than a failure = of existing Internet mechanisms to enable them.

 

Significant focus on QOS before we better enable TURN to be easily = used in a browser environment taking advantage or normal web = characteristics (as opposed to historic telephony constructs) would seem = to be highly distracting at this point.

 

 

Ch= eers,

Jo= hn

&nb= sp;

 

From:=  tram = [mailto:tram-bounces@ietf.org] On Behalf = Of Oleg Moskalenko
Sent: Thursday, February 20, = 2014 12:43 PM
To: Alan Johnston
Cc: Karl = Stahl; tram@ietf.org
Subject: Re: [tram] = Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt

 

 

 

On Thu, Feb 20, 2014 at 6:26 AM, = Alan Johnston <alan.b.johnston@gmail.com> = wrote:

 

 

 

Personally, I am not sure how much = QoS is actually in scope for TRAM. Have you been following RMCAT where = congestion avoidance for RTP is being developed?  I see some = overlap in your goals and the goals of that = work.

-

 

 

I'd = concentrate on the TURN application-level functionality, for now, and = I'd leave QoS for the future = discussions.

__________= _____________________________________
tram mailing list
tram@ietf.org
https://www.ietf.org/mailman/listinfo/tram

 

 

------=_NextPart_000_0505_01CF31C7.C672F7F0-- From nobody Tue Feb 25 07:52:17 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E331A00FB for ; Tue, 25 Feb 2014 07:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 lnYfNIU0JLyU for ; Tue, 25 Feb 2014 07:52:13 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 90BCF1A0115 for ; Tue, 25 Feb 2014 07:52:11 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 94359403BE for ; Tue, 25 Feb 2014 10:52:10 -0500 (EST) Message-ID: <530CBC2A.8020809@viagenie.ca> Date: Tue, 25 Feb 2014 10:52:10 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "tram@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/CgUKx4ImwwrjH2b2BRlGqySpd7A Subject: [tram] Remote attendance with Meetecho X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 15:52:15 -0000 FYI, we have received confirmation that remote attendance will be possible using Meetecho. To join the TRAM session: http://www.meetecho.com/ietf89/tram Full agenda of Meetecho sessions: http://ietf89.conf.meetecho.com/ Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Feb 25 07:52:34 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5661A0134; Tue, 25 Feb 2014 07:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 eZLkvqmBOBAB; Tue, 25 Feb 2014 07:52:21 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 45B911A0115; Tue, 25 Feb 2014 07:52:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3359; q=dns/txt; s=iport; t=1393343540; x=1394553140; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ywdrgw4vIZ5CJh+M+UTi9LlzASMdLz8A7wJHnTrF7w0=; b=TngmorOE9jLH/VLo5i9k3oPEhplYHlHbC+31RjmHtAc+ZIeZYAXQz1SZ eI5Oq0e7KowqMR3ZvgU7HjEVcO0ORD3c9q33v0HQ9f39ZFHTjSPay4Owy trKPWVE2gy0fax4hAThtb9EJj2oIcFe1dmEFeU1j7k0n0VxhuNy67rxEu s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAPG7DFOtJV2c/2dsb2JhbABZgwY7V8FRgRgWdIImAQEEAQEBCVsHCxACAQgSLQcnCxQDDgIEAQ0FCRKHag3GaheOEwEBTwIFhDgEiRCPJIEykHWDLYFxOQ X-IronPort-AV: E=Sophos;i="4.97,540,1389744000"; d="scan'208";a="306201743" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 25 Feb 2014 15:52:20 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1PFqKHL021141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 15:52:20 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.8]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 09:52:19 -0600 From: "Charles Eckel (eckelcu)" To: Magnus Westerlund , Karl Stahl Thread-Topic: [tram] [rtcweb] Payload Types assignments Thread-Index: AQHPMgUpm6jL6hsIxEqt4QadBq4rXJrF/YCA Date: Tue, 25 Feb 2014 15:52:19 +0000 Message-ID: References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> <530C56CD.3010003@ericsson.com> In-Reply-To: <530C56CD.3010003@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.71.202] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <243E87F768614F4EB4D58382F038CE64@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/me5Fvl1lilHN5gfAQyN-040i5ic Cc: "rtcweb@ietf.org" , "tram@ietf.org" Subject: Re: [tram] [rtcweb] Payload Types assignments X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 15:52:23 -0000 It may have been mentioned previously, but those interested in this may well want to have a look at the following drafts being discussed on the AEON list (aeon@ietf.org): http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00 http://tools.ietf.org/html/draft-eckel-aeon-use-cases-00 While QoS is not the sole focus of this work, it is one of the important work flows prevalent in networks today that is more challenging in the face of emerging communication applications such as those enabled by WebRTC. One of the goals of the AEON effort is to provide a framework such as the one mentioned by Magnus. Comments on the AEON list are welcome, as is your attendance at the AEON side meeting at IETF 89: http://www.ietf.org/mail-archive/web/aeon/current/msg00018.html Cheers, Charles On 2/25/14, 12:39 AM, "Magnus Westerlund" wrote: >Karl, >(As individual) > >I also wish for more usable QoS mechanisms. However, I don't see that >being achieved by your proposal. In addition I agree with Colin about >the issues with putting the information in the RTP header extension. I >would also note that this would be very RTP specific, and not at all >help with the data channels multiple streams and their priorities. There >might be data channel information that is more crucial than any of the >RTP media stream packets. > >You are pushing for a small piece in the middle. A piece that will not >help with the more general issue of QoS. How does the application and >the multiple ISPs that carries the traffic reach an agreement on what >properties that can be provided, that the application in this instance >have the right to request those properties and that any cost is >correctly associated with the user or the user's agent in regards to >carrying the associated cost. > >When it comes to setting DSCP from user land in the OS, that is >restricted due to the security implications. If those implications where >resolved, then OS could open up those interfaces. There are many >interlinked reasons why things look like they do today. I don't believe >in tugging on a single random thread in ball of yarn and hope that it >comes out without any knots and ties on it. > >Show me the framework for the QoS functions you have in mind that at >least has less issues than the currently deployed and take care of at >least some of the bigger issues. If that requires information in the RTP >streams for some reasons, then let us talk about how to best encoded it. >But, we need that framework first, the architecture that makes this a >better solution than the current Diffserv architecture or any other QoS >architecture. > >Cheers > >Magnus Westerlund > >---------------------------------------------------------------------- >Services, Media and Network features, Ericsson Research EAB/TXM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=E4r=F6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram From nobody Tue Feb 25 09:35:36 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 839FC1A01DD; Tue, 25 Feb 2014 09:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 jUih9hlrF80p; Tue, 25 Feb 2014 09:35:32 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8AB1A0105; Tue, 25 Feb 2014 09:35:29 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wn1so3953516obc.28 for ; Tue, 25 Feb 2014 09:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3JRjT+Vb3HvFABdujYm/4X1/hE0zXBgGceva71Owqus=; b=Qyvj6bXkv9B26Tc3+Y49HpiuSvtVKV79txORdvKQNcfTDAfsmT+arre91e4UGFL2wp agrLLu03DhWm/5luUhyelpF1c3fbttOECmbwEj+InywK/hYGgTmNumoUXf4Texr71Zj9 wbcKOtl4qXCVKRoR/W0HxqKPQCBzsSpCNO6MBbrToHU7XVeax5q1aRk6pvjXEoiwcZGk hJJwnn+L2G5XCI2fYqFkvmEoRPNijmNclVZez245jnGJPCSY0whfOkR6UjlJTt9u5pfS ENefD2C+A+qiCU5GoOLN9kJFFAO2QLPRysiMy2DK69/R2C1BKODJ56v244WPbxAyLv1W T8/A== X-Received: by 10.182.22.33 with SMTP id a1mr2447581obf.60.1393349728401; Tue, 25 Feb 2014 09:35:28 -0800 (PST) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id kn10sm137332740oeb.0.2014.02.25.09.35.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 09:35:27 -0800 (PST) Message-ID: <530CD45E.5010306@gmail.com> Date: Tue, 25 Feb 2014 11:35:26 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: tram@ietf.org References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> In-Reply-To: <5303D18C.5030705@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/tbXBO_t7_pAt2m8aO0gqAvswasc Cc: rai-ads@ietf.org, "rtcweb-chairs@tools.ietf.org" , "tsv-ads@ietf.org" , "tsvwg-chairs@ietf.org" Subject: [tram] A note from your (so far) friendly AD ... X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 17:35:34 -0000 Dear TRAMsters, If I might offer a couple of suggestions to a new working group ... The TSV area diverts QoS discussions to the TSVWG working group, because that's where the QoS DSCP expertise lives. RTCWeb and TSVWG are having a robust and so-far productive discussion about QoS for RTCWeb now (by "robust", I mean "involving chairs and ADs for both working groups"). That discussion is more likely to be productive if RTCWeb QoS topics don't start popping up on other working group mailing lists, like this one. I'll let your working group chairs actually run the working group, but I note as more than an interested observer that the TRAM agenda at https://datatracker.ietf.org/meeting/89/agenda/tram/ is really tight, and I would really be happier if the working group focuses on the currently chartered milestones and demonstrates that you can deliver what you're already signed up to deliver, before adding more milestones. The rest of the IESG would be happier as well. Thanks, and see you in London. Spencer, as your responsible AD On 02/18/2014 03:33 PM, Simon Perreault wrote: > Le 2014-02-18 16:12, Oleg Moskalenko a écrit : >> How to handle the DS and ECN fields is a part of TURN server RFC (see >> the section 12): >> >> http://tools.ietf.org/search/rfc5766#section-12 >> >> And a good TURN server is supposed to implement that. > Well, the RFC just says that the TURN server should copy the DSCP from > one side to the other when doing en/de-capsulation. It doesn't say that > the server should actually do QoS based on the DSCP. My point is that > there's nothing preventing the server from actually doing it. > > Anyway, I was expecting responses along the lines of "DiffServ doesn't > work on the Internet in general." To which I would have replied: "then > couldn't we define a STUN attribute for transporting the DSCP in the > payload?" Instead of inventing a new taxonomy (audio, video, slides, > etc.), why not reuse DSCP? > > Simon From nobody Tue Feb 25 09:36:59 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F5A1A016F for ; Tue, 25 Feb 2014 09:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=unavailable 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 mCnELEdK8OlS for ; Tue, 25 Feb 2014 09:36:56 -0800 (PST) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 78BA81A0111 for ; Tue, 25 Feb 2014 09:36:54 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id jw12so816155veb.12 for ; Tue, 25 Feb 2014 09:36:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JdsDg2LwsipHBuX2i4MLn4myYlWUEWmmJ016BB/s5Og=; b=GPxYjaD0YPEeuUyNNPU5UJa1ROnI84+SWSIHKPqqAa/LCjtShJc1/TI7RFvSErMi/8 PEkRQexC5mgiCb7Y2Grm7+Tuq/PwHYQAPKkgUer99R66MP5j3kgHKuWNFIX0PGmY3pWU l0iE2+ZfWWT8z3/++LqqPW1ODATTkwx3c6YWMdu5LHjNQra8LYZ5GTfKm3McJGqDb4vu ND8N0K0UDs59J42AjneenIraHP6gLEeVi/5EZQUHfq9HA8pBarljR/U9uOOjnB9w0Lxl gtJSoZ4giEeIbfKeeP3m9JC/b8TlM4XXFVznE8QUgtuW5yHKuzEDB8HGCp1xVU+wswqI 5GYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=JdsDg2LwsipHBuX2i4MLn4myYlWUEWmmJ016BB/s5Og=; b=Tzrl9Ay8YK/Mr0aaRyGghfDqxoadlGBj9KPVj7sWUW8+oGrW4cu0UpuxET8uAW2p7P 1Hcu99bW0TYzYq5vE+2NBpdg08u9UBtWSztS48FRacgN0GrUx5X7S1vlPS6uqgOca7Hp ZUNQ3KhnihYIWp8I2qmxHtZuUB6uLm44+AJvnryl/xx9eNfS3J1airHBjyj/x6sh1TTK GLuj8REjYoZKJrLHnE469+NuCOy8q2OHEsG2cLGa44rkZuW5aVTFS4o+lSpE//jc6D5u 7vdGzp1njp29NKjfFnosE+k21uWD/22QcgjOJz2ze/aJ0an20OTm0QchBSUF5DA7xmZz pdGw== X-Gm-Message-State: ALoCoQkQFbnFDugtsg2+EByCxiPvopmO5xbHav/2UheYKbbtc30+U30OQd91/kzasWLDjMiBruSSDXrVBJxSYgxfPUskr0TlhzMuKivsQdoGlZiJlEF5G1HA+oA0RMoUqf1m3VV72EZJtDZdjf5IyJlPE4Ty65TVobtoz7ZXhDS5H6qtUHdbZjquoyN42aR2sdSjZ9rJzHn3 X-Received: by 10.221.66.73 with SMTP id xp9mr1932337vcb.27.1393349813238; Tue, 25 Feb 2014 09:36:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.89.170 with HTTP; Tue, 25 Feb 2014 09:36:28 -0800 (PST) In-Reply-To: <530CD45E.5010306@gmail.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> <530CD45E.5010306@gmail.com> From: Justin Uberti Date: Tue, 25 Feb 2014 09:36:28 -0800 Message-ID: To: Spencer Dawkins Content-Type: multipart/alternative; boundary=001a113642e6aa961104f33e8863 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/xVbLIn-i-hdAarEPmwdCX7yvo6g Cc: "tsvwg-chairs@ietf.org" , rai-ads@ietf.org, "tram@ietf.org" , "tsv-ads@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [tram] A note from your (so far) friendly AD ... X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 17:36:58 -0000 --001a113642e6aa961104f33e8863 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1, let us not try to solve problems we are not chartered to solve On Tue, Feb 25, 2014 at 9:35 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Dear TRAMsters, > > If I might offer a couple of suggestions to a new working group ... > > The TSV area diverts QoS discussions to the TSVWG working group, because > that's where the QoS DSCP expertise lives. > > RTCWeb and TSVWG are having a robust and so-far productive discussion > about QoS for RTCWeb now (by "robust", I mean "involving chairs and ADs f= or > both working groups"). That discussion is more likely to be productive if > RTCWeb QoS topics don't start popping up on other working group mailing > lists, like this one. > > I'll let your working group chairs actually run the working group, but I > note as more than an interested observer that the TRAM agenda at > https://datatracker.ietf.org/meeting/89/agenda/tram/ is really tight, and > I would really be happier if the working group focuses on the currently > chartered milestones and demonstrates that you can deliver what you're > already signed up to deliver, before adding more milestones. The rest of > the IESG would be happier as well. > > Thanks, and see you in London. > > Spencer, as your responsible AD > > On 02/18/2014 03:33 PM, Simon Perreault wrote: > >> Le 2014-02-18 16:12, Oleg Moskalenko a =C3=A9crit : >> >>> How to handle the DS and ECN fields is a part of TURN server RFC (see >>> the section 12): >>> >>> http://tools.ietf.org/search/rfc5766#section-12 >>> >>> And a good TURN server is supposed to implement that. >>> >> Well, the RFC just says that the TURN server should copy the DSCP from >> one side to the other when doing en/de-capsulation. It doesn't say that >> the server should actually do QoS based on the DSCP. My point is that >> there's nothing preventing the server from actually doing it. >> >> Anyway, I was expecting responses along the lines of "DiffServ doesn't >> work on the Internet in general." To which I would have replied: "then >> couldn't we define a STUN attribute for transporting the DSCP in the >> payload?" Instead of inventing a new taxonomy (audio, video, slides, >> etc.), why not reuse DSCP? >> >> Simon >> > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a113642e6aa961104f33e8863 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1, let us not try to solve problems we are not chartered = to solve


On Tue, Feb 25, 2014 at 9:35 AM, Spencer Dawkins <spencerdawk= ins.ietf@gmail.com> wrote:
Dear TRAMsters,

If I might offer a couple of suggestions to a new working group ...

The TSV area diverts QoS discussions to the TSVWG working group, because th= at's where the QoS DSCP expertise lives.

RTCWeb and TSVWG are having a robust and so-far productive discussion about= QoS for RTCWeb now (by "robust", I mean "involving chairs a= nd ADs for both working groups"). That discussion is more likely to be= productive if RTCWeb QoS topics don't start popping up on other workin= g group mailing lists, like this one.

I'll let your working group chairs actually run the working group, but = I note as more than an interested observer that the TRAM agenda at https://datatracker.ietf.org/meeting/89/agenda/tram/ is really = tight, and I would really be happier if the working group focuses on the cu= rrently chartered milestones and demonstrates that you can deliver what you= 're already signed up to deliver, before adding more milestones. The re= st of the IESG would be happier as well.

Thanks, and see you in London.

Spencer, as your responsible AD

On 02/18/2014 03:33 PM, Simon Perreault wrote:
Le 2014-02-18 16:12, Oleg Moskalenko a =C3=A9crit :
How to handle the DS and ECN fields is a part of TURN server RFC (see
the section 12):

http://tools.ietf.org/search/rfc5766#section-12

And a good TURN server is supposed to implement that.
Well, the RFC just says that the TURN server should copy the DSCP from
one side to the other when doing en/de-capsulation. It doesn't say that=
the server should actually do QoS based on the DSCP. My point is that
there's nothing preventing the server from actually doing it.

Anyway, I was expecting responses along the lines of "DiffServ doesn&#= 39;t
work on the Internet in general." To which I would have replied: "= ;then
couldn't we define a STUN attribute for transporting the DSCP in the payload?" Instead of inventing a new taxonomy (audio, video, slides, etc.), why not reuse DSCP?

Simon

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--001a113642e6aa961104f33e8863-- From nobody Tue Feb 25 09:59:56 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30E81A0218; Tue, 25 Feb 2014 09:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 EJmRM-qxvPQf; Tue, 25 Feb 2014 09:59:42 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8852B1A01C8; Tue, 25 Feb 2014 09:59:40 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id p61so714379wes.38 for ; Tue, 25 Feb 2014 09:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bo/snsDTNPNWUq0XloGAAYyA3+dNOIAu2YH8AQJpEUs=; b=0QW/Szwpl5eTwzZnLULXnvHXsqIY+xotpz3ToXPVYNAVWh/b09WfyNHmIuarXsqEBg ntWoJOkz7nIlXtw/bACRYzYKhkVjewnsNel75YUxlruE4oz5DSgkFicMRDpTL2ZyhqpF WKs5iCK3R72GqoIPNES/153dRVDWVjz3kxwYdVu+sNm2OakPY8ftsCQ+4jAt3izplpWA 0fAG+nsRbBBhpd3UU2pbr+uCg9NwKeBS6fJGg1+BXLw/5QfS/82r9w40hnLBZ7uxCtIw qRjBZm6iwOBSSvW7V67vdD6W0kBmvJhoRxavm7TAGhaiHTh+yIF1Uw5PfXWdUY/Crj49 OEsQ== MIME-Version: 1.0 X-Received: by 10.180.149.143 with SMTP id ua15mr4209982wib.36.1393351178956; Tue, 25 Feb 2014 09:59:38 -0800 (PST) Received: by 10.217.96.195 with HTTP; Tue, 25 Feb 2014 09:59:38 -0800 (PST) In-Reply-To: <530CD45E.5010306@gmail.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> <530CD45E.5010306@gmail.com> Date: Tue, 25 Feb 2014 11:59:38 -0600 Message-ID: From: Mary Barnes To: Spencer Dawkins Content-Type: multipart/alternative; boundary=001a11c38e7011b7b304f33edaef Archived-At: http://mailarchive.ietf.org/arch/msg/tram/hJ96C9EkAG5MK34HlrD4H2TKtME Cc: "tsvwg-chairs@ietf.org" , rai-ads@ietf.org, tram@ietf.org, "tsv-ads@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [tram] A note from your (so far) friendly AD ... X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 17:59:48 -0000 --001a11c38e7011b7b304f33edaef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It would also be extremely helpful in cases where it's not entirely clear whether the discussion belongs in TRAM, RTCWEB, etc. to please avoid cross-posting. Please check with the chairs about what list they think is most appropriate and then just send a note to other lists that might care that the discussion is happening on a specific mailing list. It's extremely confusing for those of us on multiple lists that try to sort and follow threads by working groups. On Tue, Feb 25, 2014 at 11:35 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Dear TRAMsters, > > If I might offer a couple of suggestions to a new working group ... > > The TSV area diverts QoS discussions to the TSVWG working group, because > that's where the QoS DSCP expertise lives. > > RTCWeb and TSVWG are having a robust and so-far productive discussion > about QoS for RTCWeb now (by "robust", I mean "involving chairs and ADs f= or > both working groups"). That discussion is more likely to be productive if > RTCWeb QoS topics don't start popping up on other working group mailing > lists, like this one. > > I'll let your working group chairs actually run the working group, but I > note as more than an interested observer that the TRAM agenda at > https://datatracker.ietf.org/meeting/89/agenda/tram/ is really tight, and > I would really be happier if the working group focuses on the currently > chartered milestones and demonstrates that you can deliver what you're > already signed up to deliver, before adding more milestones. The rest of > the IESG would be happier as well. > > Thanks, and see you in London. > > Spencer, as your responsible AD > > On 02/18/2014 03:33 PM, Simon Perreault wrote: > >> Le 2014-02-18 16:12, Oleg Moskalenko a =E9crit : >> >>> How to handle the DS and ECN fields is a part of TURN server RFC (see >>> the section 12): >>> >>> http://tools.ietf.org/search/rfc5766#section-12 >>> >>> And a good TURN server is supposed to implement that. >>> >> Well, the RFC just says that the TURN server should copy the DSCP from >> one side to the other when doing en/de-capsulation. It doesn't say that >> the server should actually do QoS based on the DSCP. My point is that >> there's nothing preventing the server from actually doing it. >> >> Anyway, I was expecting responses along the lines of "DiffServ doesn't >> work on the Internet in general." To which I would have replied: "then >> couldn't we define a STUN attribute for transporting the DSCP in the >> payload?" Instead of inventing a new taxonomy (audio, video, slides, >> etc.), why not reuse DSCP? >> >> Simon >> > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > --001a11c38e7011b7b304f33edaef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It would also be extremely helpful in cases where it's= not entirely clear whether the discussion belongs in TRAM, RTCWEB, etc. to= please avoid cross-posting. =A0Please check with the chairs about what lis= t they think is most appropriate and then just send a note to other lists t= hat might care that the discussion is happening on a specific mailing list.= =A0It's extremely confusing for those of us on multiple lists that try= to sort and follow threads by working groups.=A0


On Tue, Feb 2= 5, 2014 at 11:35 AM, Spencer Dawkins <spencerdawkins.ietf@gmai= l.com> wrote:
Dear TRAMsters,

If I might offer a couple of suggestions to a new working group ...

The TSV area diverts QoS discussions to the TSVWG working group, because th= at's where the QoS DSCP expertise lives.

RTCWeb and TSVWG are having a robust and so-far productive discussion about= QoS for RTCWeb now (by "robust", I mean "involving chairs a= nd ADs for both working groups"). That discussion is more likely to be= productive if RTCWeb QoS topics don't start popping up on other workin= g group mailing lists, like this one.

I'll let your working group chairs actually run the working group, but = I note as more than an interested observer that the TRAM agenda at https://datatracker.ietf.org/meeting/89/agenda/tram/ is really = tight, and I would really be happier if the working group focuses on the cu= rrently chartered milestones and demonstrates that you can deliver what you= 're already signed up to deliver, before adding more milestones. The re= st of the IESG would be happier as well.

Thanks, and see you in London.

Spencer, as your responsible AD

On 02/18/2014 03:33 PM, Simon Perreault wrote:
Le 2014-02-18 16:12, Oleg Moskalenko a =E9crit :
How to handle the DS and ECN fields is a part of TURN server RFC (see
the section 12):

http://tools.ietf.org/search/rfc5766#section-12

And a good TURN server is supposed to implement that.
Well, the RFC just says that the TURN server should copy the DSCP from
one side to the other when doing en/de-capsulation. It doesn't say that=
the server should actually do QoS based on the DSCP. My point is that
there's nothing preventing the server from actually doing it.

Anyway, I was expecting responses along the lines of "DiffServ doesn&#= 39;t
work on the Internet in general." To which I would have replied: "= ;then
couldn't we define a STUN attribute for transporting the DSCP in the payload?" Instead of inventing a new taxonomy (audio, video, slides, etc.), why not reuse DSCP?

Simon

_______________________________________________
tram mailing list
tram@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/tram

--001a11c38e7011b7b304f33edaef-- From nobody Tue Feb 25 12:58:33 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81561A020C; Tue, 25 Feb 2014 12:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 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, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 zkrCSZMpb60q; Tue, 25 Feb 2014 12:44:36 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 602D21A0054; Tue, 25 Feb 2014 12:44:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3193; q=dns/txt; s=iport; t=1393361075; x=1394570675; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=sjcTkqHTXSGEPol5tyVSOoOPvsWb4O/ctlB5eSqa8AI=; b=jFZ8tQCl5WRB1x5DWzmUQaFyXHtlEa3czVgv2D0RQd/DI+gvMwe3BXUf X9E//iMkIULUR+NPP/xSMWfXfBgGiovtHdEgf2wAlO8MEIpFOk8X20V37 4r7PhnuKeCmOWocNY1PzHdKOq6MKAfeVaLdt32nx03tOFwDJi7GBB3Vs/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAHD/DFOrRDoH/2dsb2JhbABZgwY7wieBGhZ0giUBAQEEAQEBNTMDCxAHBBgJHgcPCggGHxEGARKHcQMQDsBpDYcwF4w8gUAhMweEOASJETiNAIMfiy+FR4NMHQ X-IronPort-AV: E=Sophos;i="4.97,542,1389744000"; d="scan'208";a="104486967" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 25 Feb 2014 20:44:35 +0000 Received: from jmpolk-WS.cisco.com (sjc-vpn7-1609.cisco.com [10.21.150.73]) (authenticated bits=0) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1PKiYNH011099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Feb 2014 20:44:34 GMT Message-Id: <201402252044.s1PKiYNH011099@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 25 Feb 2014 14:44:32 -0600 To: Mary Barnes , Spencer Dawkins From: James Polk In-Reply-To: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> <530CD45E.5010306@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-User: jmpolk Archived-At: http://mailarchive.ietf.org/arch/msg/tram/2PTJcGxFWrGGP8UJdQIl-Kd5fGE X-Mailman-Approved-At: Tue, 25 Feb 2014 12:58:28 -0800 Cc: "tsvwg-chairs@ietf.org" , rai-ads@ietf.org, tram@ietf.org, "tsv-ads@ietf.org" , "rtcweb-chairs@tools.ietf.org" Subject: Re: [tram] A note from your (so far) friendly AD ... X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 20:44:40 -0000 But that didn't happen here. Only Certain ADs and=20 certain WG chairs were cc'd. You surely don't have a problem with that...? James At 11:59 AM 2/25/2014, Mary Barnes wrote: >It would also be extremely helpful in cases=20 >where it's not entirely clear whether the=20 >discussion belongs in TRAM, RTCWEB, etc. to=20 >please avoid cross-posting. Please check with=20 >the chairs about what list they think is most=20 >appropriate and then just send a note to other=20 >lists that might care that the discussion is=20 >happening on a specific mailing list. It's=20 >extremely confusing for those of us on multiple=20 >lists that try to sort and follow threads by working groups. > > >On Tue, Feb 25, 2014 at 11:35 AM, Spencer=20 >Dawkins=20 ><spencerdawkins.ietf@gmail.com>= wrote: >Dear TRAMsters, > >If I might offer a couple of suggestions to a new working group ... > >The TSV area diverts QoS discussions to the=20 >TSVWG working group, because that's where the QoS DSCP expertise lives. > >RTCWeb and TSVWG are having a robust and so-far=20 >productive discussion about QoS for RTCWeb now=20 >(by "robust", I mean "involving chairs and ADs=20 >for both working groups"). That discussion is=20 >more likely to be productive if RTCWeb QoS=20 >topics don't start popping up on other working=20 >group mailing lists, like this one. > >I'll let your working group chairs actually run=20 >the working group, but I note as more than an=20 >interested observer that the TRAM agenda at=20 >https://datatracker.i= etf.org/meeting/89/agenda/tram/=20 >is really tight, and I would really be happier=20 >if the working group focuses on the currently=20 >chartered milestones and demonstrates that you=20 >can deliver what you're already signed up to=20 >deliver, before adding more milestones. The rest=20 >of the IESG would be happier as well. > >Thanks, and see you in London. > >Spencer, as your responsible AD > >On 02/18/2014 03:33 PM, Simon Perreault wrote: >Le 2014-02-18 16:12, Oleg Moskalenko a =E9crit : >How to handle the DS and ECN fields is a part of TURN server RFC (see >the section 12): > >http://tools.ietf.org/sear= ch/rfc5766#section-12 > >And a good TURN server is supposed to implement that. > >Well, the RFC just says that the TURN server should copy the DSCP from >one side to the other when doing en/de-capsulation. It doesn't say that >the server should actually do QoS based on the DSCP. My point is that >there's nothing preventing the server from actually doing it. > >Anyway, I was expecting responses along the lines of "DiffServ doesn't >work on the Internet in general." To which I would have replied: "then >couldn't we define a STUN attribute for transporting the DSCP in the >payload?" Instead of inventing a new taxonomy (audio, video, slides, >etc.), why not reuse DSCP? > >Simon > > >_______________________________________________ >tram mailing list >tram@ietf.org >https://www.ietf.org/mailman/listinfo/tram > From nobody Tue Feb 25 13:29:05 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3451A0786; Tue, 25 Feb 2014 13:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 KrAem6JbRlJc; Tue, 25 Feb 2014 13:28:58 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3B19E1A0745; Tue, 25 Feb 2014 13:28:56 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id w61so925856wes.19 for ; Tue, 25 Feb 2014 13:28:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lLizZyB/3MieCms7Dgx4JE88ajCKLTk5FMuVuUMzRlo=; b=Yu2Xjocy31oo0Q2RT5DRXoZp6Hu2f56tJVELVBvZYohcM7SPltcFmSsiAp10ajBbz+ gac/YNbliqxgQfiQ6OXpPfwOOqYtdRCWXdcvFR0pI21T7hS0Fk+S+zh+r6HhEp9NsE42 se8VG8mAdRC9vsQqRPJ5rEI/YW/VTMzsXN8infeKglAON5yAShcIVq9EXksb3gLkO2LS iEazIcYTZ1PGocuiiLQBYSSaQwtGMkMbjZ/6gu4MgDvxX2So9JGR/AxD1Ii3xPK0JcOi TubGbMsngRltBFx2PNHz7m5gB2PVauszvnYQzOJHAVp2lc29MVJLAtZHbXUeCRi3WTif MjfA== MIME-Version: 1.0 X-Received: by 10.194.63.228 with SMTP id j4mr27314225wjs.34.1393363734864; Tue, 25 Feb 2014 13:28:54 -0800 (PST) Received: by 10.217.96.195 with HTTP; Tue, 25 Feb 2014 13:28:54 -0800 (PST) In-Reply-To: <201402252044.s1PKiYNH011099@mtv-core-2.cisco.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> <530CD45E.5010306@gmail.com> <201402252044.s1PKiYNH011099@mtv-core-2.cisco.com> Date: Tue, 25 Feb 2014 15:28:54 -0600 Message-ID: From: Mary Barnes To: James Polk Content-Type: multipart/alternative; boundary=047d7ba97f3a75a93f04f341c698 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/7wzEtG4cnGU-WLv36SAjh1ZbfWE Cc: "rtcweb-chairs@tools.ietf.org" , rai-ads@ietf.org, tram@ietf.org, "tsvwg-chairs@ietf.org" , "tsv-ads@ietf.org" , Spencer Dawkins Subject: Re: [tram] A note from your (so far) friendly AD ... X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 21:29:02 -0000 --047d7ba97f3a75a93f04f341c698 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable James, Correct. This current email thread was not cross posted but it was posted to the TRAM mailing list and not just some WG chairs as you noted. My point was that one of the threads of discussion which triggered this email involved cross posting. For some of us that are subscribed to all the lists involved, it gets crazy trying to follow these threads. Mary. On Tue, Feb 25, 2014 at 2:44 PM, James Polk wrote: > But that didn't happen here. Only Certain ADs and certain WG chairs were > cc'd. You surely don't have a problem with that...? > > James > > > At 11:59 AM 2/25/2014, Mary Barnes wrote: > >> It would also be extremely helpful in cases where it's not entirely clea= r >> whether the discussion belongs in TRAM, RTCWEB, etc. to please avoid >> cross-posting. Please check with the chairs about what list they think = is >> most appropriate and then just send a note to other lists that might car= e >> that the discussion is happening on a specific mailing list. It's >> extremely confusing for those of us on multiple lists that try to sort a= nd >> follow threads by working groups. >> >> >> On Tue, Feb 25, 2014 at 11:35 AM, Spencer Dawkins <> spencerdawkins.ietf@gmail.com>spencerdawkins.ietf@gmail.com> wrote: >> Dear TRAMsters, >> >> If I might offer a couple of suggestions to a new working group ... >> >> The TSV area diverts QoS discussions to the TSVWG working group, because >> that's where the QoS DSCP expertise lives. >> >> RTCWeb and TSVWG are having a robust and so-far productive discussion >> about QoS for RTCWeb now (by "robust", I mean "involving chairs and ADs = for >> both working groups"). That discussion is more likely to be productive i= f >> RTCWeb QoS topics don't start popping up on other working group mailing >> lists, like this one. >> >> I'll let your working group chairs actually run the working group, but I >> note as more than an interested observer that the TRAM agenda at < >> https://datatracker.ietf.org/meeting/89/agenda/tram/>https: >> //datatracker.ietf.org/meeting/89/agenda/tram/ is really tight, and I >> would really be happier if the working group focuses on the currently >> chartered milestones and demonstrates that you can deliver what you're >> already signed up to deliver, before adding more milestones. The rest of >> the IESG would be happier as well. >> >> >> Thanks, and see you in London. >> >> Spencer, as your responsible AD >> >> On 02/18/2014 03:33 PM, Simon Perreault wrote: >> Le 2014-02-18 16:12, Oleg Moskalenko a =E9crit : >> How to handle the DS and ECN fields is a part of TURN server RFC (see >> the section 12): >> >> http:// >> tools.ietf.org/search/rfc5766#section-12 >> >> >> And a good TURN server is supposed to implement that. >> >> Well, the RFC just says that the TURN server should copy the DSCP from >> one side to the other when doing en/de-capsulation. It doesn't say that >> the server should actually do QoS based on the DSCP. My point is that >> there's nothing preventing the server from actually doing it. >> >> Anyway, I was expecting responses along the lines of "DiffServ doesn't >> work on the Internet in general." To which I would have replied: "then >> couldn't we define a STUN attribute for transporting the DSCP in the >> payload?" Instead of inventing a new taxonomy (audio, video, slides, >> etc.), why not reuse DSCP? >> >> Simon >> >> >> _______________________________________________ >> tram mailing list >> tram@ietf.org >> https://www.ietf.org/mailman/listinfo/tram >> >> > --047d7ba97f3a75a93f04f341c698 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
James,

Correct. This current email thre= ad was not cross posted but it was posted to the TRAM mailing list and not = just some WG chairs as you noted. My point was that one of the threads of d= iscussion which triggered this email involved cross posting. =A0 For some o= f us that are subscribed to all the lists involved, it gets crazy trying to= follow these threads.=A0

Mary.=A0


=
On Tue, Feb 25, 2014 at 2:44 PM, James Polk <jmp= olk@cisco.com> wrote:
But that didn't happen here. Only Certai= n ADs and certain WG chairs were cc'd. You surely don't have a prob= lem with that...?

James


At 11:59 AM 2/25/2014, Mary Barnes wrote:
It would also be extremely helpful in cases where it's not entirely cle= ar whether the discussion belongs in TRAM, RTCWEB, etc. to please avoid cro= ss-posting. =A0Please check with the chairs about what list they think is m= ost appropriate and then just send a note to other lists that might care th= at the discussion is happening on a specific mailing list. =A0It's extr= emely confusing for those of us on multiple lists that try to sort and foll= ow threads by working groups.


On Tue, Feb 25, 2014 at 11:35 AM, Spencer Dawkins <<mailto:spencerdawkins.iet= f@gmail.com>spencerdawkins.ietf@gmail.com> wrote:
Dear TRAMsters,

If I might offer a couple of suggestions to a new working group ...

The TSV area diverts QoS discussions to the TSVWG working group, because th= at's where the QoS DSCP expertise lives.

RTCWeb and TSVWG are having a robust and so-far productive discussion about= QoS for RTCWeb now (by "robust", I mean "involving chairs a= nd ADs for both working groups"). That discussion is more likely to be= productive if RTCWeb QoS topics don't start popping up on other workin= g group mailing lists, like this one.

I'll let your working group chairs actually run the working group, but = I note as more than an interested observer that the TRAM agenda at <https://datatracker.ietf.org/meeting/89/agenda/tram/>https://datatracker.ietf.org/meeting/89/agenda/tram/ = is really tight, and I would really be happier if the working group focuses= on the currently chartered milestones and demonstrates that you can delive= r what you're already signed up to deliver, before adding more mileston= es. The rest of the IESG would be happier as well.


Thanks, and see you in London.

Spencer, as your responsible AD

On 02/18/2014 03:33 PM, Simon Perreault wrote:
Le 2014-02-18 16:12, Oleg Moskalenko a =E9crit :
How to handle the DS and ECN fields is a part of TURN server RFC (see
the section 12):

<http://tools.ietf.org/search/rfc5766#section-12>htt= p://tools.ietf.org/search/rfc5766#section-12


And a good TURN server is supposed to implement that.

Well, the RFC just says that the TURN server should copy the DSCP from
one side to the other when doing en/de-capsulation. It doesn't say that=
the server should actually do QoS based on the DSCP. My point is that
there's nothing preventing the server from actually doing it.

Anyway, I was expecting responses along the lines of "DiffServ doesn&#= 39;t
work on the Internet in general." To which I would have replied: "= ;then
couldn't we define a STUN attribute for transporting the DSCP in the payload?" Instead of inventing a new taxonomy (audio, video, slides, etc.), why not reuse DSCP?

Simon


_______________________________________________
tram mailing list
<mailto:tram@ietf.org= >tram@ietf= .org
ht= tps://www.ietf.org/mailman/listinfo/tram



--047d7ba97f3a75a93f04f341c698-- From nobody Tue Feb 25 15:49:38 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DFF1A030E; Tue, 25 Feb 2014 15:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001] autolearn=ham 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 1F-y2RmQwFoJ; Tue, 25 Feb 2014 15:49:15 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 576671A07A3; Tue, 25 Feb 2014 15:49:14 -0800 (PST) Received: from [81.187.2.149] (port=47374 helo=[192.168.0.15]) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WIRkG-0002ra-A0; Tue, 25 Feb 2014 23:49:09 +0000 Content-Type: multipart/alternative; boundary="Apple-Mail=_B2EC0CF9-4C12-4B53-B965-573E2AE51D13" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Colin Perkins In-Reply-To: <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> Date: Tue, 25 Feb 2014 23:49:01 +0000 Message-Id: References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> To: Karl Stahl X-Mailer: Apple Mail (2.1874) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Gxb8AJ5AyJWnHMT8Qf4tS4wM_ws Cc: Magnus Westerlund , rtcweb@ietf.org, tram@ietf.org, Harald Alvestrand Subject: Re: [tram] [rtcweb] Payload Types assignments X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 23:49:20 -0000 --Apple-Mail=_B2EC0CF9-4C12-4B53-B965-573E2AE51D13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Karl, I sympathise with your goal, but I really do not think RTP header = extensions are appropriate for this purpose. Ignoring the semantic mismatch, in order to identify an RTP header = extension, you need access to the signalling data, and if you have = access to the signalling, you can signal the QoS parameters without = using RTP.=20 You state that only the payload is encrypted in SRTP. That is not = necessarily true. RTP header extensions can be encrypted when RFC 6904 = is in use, and rtcweb-rtp-usage draft recommends this be done in some = cases. The signalling channel is also likely encrypted end-to-end in new = applications, so making it difficult to extract the information you need = to parse the RTP header extension, even if it is unencrypted.=20 Besides these focussed issues, I would also urge you to consider the = much broader comments Magnus made. The QoS problem is broad, and a point = solution based on RTP header extensions - even if it were workable, = which I doubt - would address only a small part of the problem space. Colin On 25 Feb 2014, at 01:45, Karl Stahl wrote: > Colin, > =20 > If the below were the case, it would be =93DPI guesswork=94 that I = also advice against. RTP doesn=92t even have unique protocol header = within UDP =96 it can even be confused with other UDP payload. > =20 > However, if the RTP is captured in a TURN-flow, as in TRAM Milestone = 3, the network point that this flow is directed to and can apply QoS = methods relevant to the network (which is not diffserve in Mobile OTT = and Cable Networks) has not a too difficult tasks. Linking each RTP-flow = by its ID and sequence number, and picking exactly the right traffic = type and bandwidth parameters is doable (see inline below, we at Ingate = do it already)! > =20 > Also DiffServ DSCP-bits are seldom maintained crossing network = boundaries, thus carrying no relevant information at the receiving end, = while the RTP extension header remains unchanged end-to-end. In = DSCP-bits, there is no bandwidth requirement information when entering = networks requiring reservation. That is always (and dynamically set) = available in the RTP extension header for each packet. > =20 > And, I am sure you are aware of the difficulties of getting DSCP-bits = through OS sockets, which is even worse with multiple streams over the = same UDP-port > =20 > Further, defining the QoS RTP extension header as in RFC5285, does not = in anyway conflict with other RTP extension headers or DSCP transfer or = settings. > =20 > /Karl > =20 > Fr=E5n: Colin Perkins [mailto:csp@csperkins.org]=20 > Skickat: den 24 februari 2014 23:52 > Till: Karl Stahl > Kopia: rtcweb@ietf.org; Magnus Westerlund; tram@ietf.org; Harald = Alvestrand > =C4mne: Re: [rtcweb] [tram] Payload Types assignments > =20 > Karl, > =20 > I strongly disagree with this suggestion. An RTP header extension, = located at an unknown and variable offset into a packet that does not = have a well-defined magic number in the header, > This is how to find the traffic info: > The payload of the classifier header extension element can be = encoded > using either the one-byte or two-byte header defined in [rfc5285] = and > shown below in Figure 1 and 2 below. > =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ID | len=3D1 | Namespace | Value | 0 (pad) = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > Figure 1: Classifier Using the One-Byte Header > =20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ID | len=3D2 | Namespace | Value = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > =20 > =20 > Figure 2: Classifier Using the Two-Byte Header > =20 > indicated using a dynamically assigned identifier that is conveyed in = an out-of-band > --- It is the TURN flow!!! Requested by the ICE protocol for the = specific media to come! > and encrypted signalling channel, > --- Only the payload is encrypted in SRTP =96 leaving id, seq no and = header ext to be used as intended! > --- Thus being the appropriate place=85 > is not an appropriate place to put QoS information that has to be = processed on a per-packet basis. > If you want DiffServ, you know where to find it. > --- True, but if it cannot be used=85 > Colin > =20 > =20 > On 24 Feb 2014, at 22:09, Karl Stahl wrote: > I suggest to the RTCWEB WG that the below from the September and = October discussions on the relevant [rtcweb] [avtext] [mmusic] lists = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is = introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC 5285, to = allow: > =20 > (1) WebRTC applications to directly convey QoS related real-time = traffic info to the network at points where RTP flow is directed to by = TRAM Milstone 3, to be used by *any network element implementing any = suitable QoS methods for the particular network* for > (2) *all* WebRTC browsers *and* clients, under *all* OSs, and *all* = current and future IP network, to achieve best QoE > (3) *without* having to force WebRTC into application specific = networks (such as IMS) instead of using the Internet (including OTT). > =20 > The only further activity required, is to call for ISPs=92 to review = whether the traffic information transferred by RFC 5285 is sufficient = for current and future needs in their network as suggested in below = repeated = http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html > > =85two parameters (e.g. two bytes each) are encoded into the RTP = header extension: > =20 > A) The maximum bandwidth requirement: Two bytes could contain = everything from some bps for real-time text to Gbps for future 3D = supersize telepresence=85 on a logarithmic scale. > =20 > B) The quality characteristics for the stream, with the highest bit = set to 1, we could allocate a bit each for quality type e.g: > Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay = Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = Prioritize X, Variation Y, that could be combined as required to = describe the stream. > =20 > And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the = individual bits. > > =20 > Then this could be assigned numbers to have an RFC in place. > =20 > With TRAM milestone 3 also place, > market forces will drive ISPs and browser makers to implement just = this, without even having it MUST-established. > =20 > =93Who does not want a =93WebRTC-Ready=94 Internet access?=94 and > =93Who wants to use Chrome, if Firefox, Internet Explorer or Safari = comes with much better QoE?=94 and vice versa. > =20 > Please see further emails soon following this one, for details and = history. > =20 > /Karl > =20 > =20 > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Karl Stahl > Skickat: den 22 oktober 2013 16:37 > Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus Westerlund' > Kopia: 'Colin Perkins' > =C4mne: [rtcweb] [avtext] Payload Types assignments was Re: SV: = [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 > =20 > Harald, I mostly agree with the quality requirements of different = real-time traffic that the WebRTC browser/application may use. But = rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it. =20 > =20 > There is actually a good way to show these needs to the network = (without using the PT, or diffserv bits, which aren=92t sufficient = anyway). > =20 > Let's use the RTP header extension field that also is visible outside = the encrypted payload. A week ago came = http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 that = outlines the usage of the extension field for classification of traffic! = This document does not yet outline what to put in there and how to = encode it though. > =20 > Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 = discusses other webrtc usages of the RTP header extension in 5.2 (there = can be many header extensions according to RFC 5285) and in 9 there is = "WebRTC Use of RTP: Future Extensions". > =20 > So, it looks obvious to use the RTP header extension to show the = characteristics and bandwidth requirements to the network. It should not = introduce any backward incompatibilities either. > =20 > Such marking is done in every RTP packet so it can be set individually = for each stream and could even be changed during a session (e.g. when = limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies = how RTP extension header usage can be negotiated in SDP. I think this = could be easily done by the WebRTC browser for "all current and future = needs" if properly specified now. > =20 > I suggest that two parameters (e.g. two bytes each) are encoded into = the RTP header extension: > =20 > A) The maximum bandwidth requirement: Two bytes could contain = everything from some bps for real-time text to Gbps for future 3D = supersize telepresence=85 on a logarithmic scale. > =20 > B) The quality characteristics for the stream, with the highest bit = set to 1, we could allocate a bit each quality e.g: > Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay = Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = Prioritize X, Variation Y, that could be combined as required to = describe the stream. > =20 > And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the = individual bits. > =20 > Please note the totally different requirements a diffserv and an RSVP = network have to know, so let=92s put all into these bytes. (E.g. a = diffserv network don't need the bandwidth usage, but RSVP reservation = networks (e.g. cable and 3G/4G OTT) do. There one should initially = reserve the maximum bandwidth indicated, but can later re-reserve.) > =20 > /Karl > =20 > PS Microsoft seems to have done work in this field, defining a = proprietary attribute =93MS Service Quality=94; > However that seems to apply to the TURN server allocation request and = would therefore: > --- Apply to the whole UDP flow, and could not be set for each stream = individually (with different requirements), and > --- Does not handle the bandwidth requirement for incoming real-time = traffic (required to reserve in RSVP type of networks) > However the quality attributes conveyed and their encoding may be = considered. > =20 > This is 2.2.2.19 MS-Service Quality Attribute from > http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx=20= > =20 > MS-Service Quality Attribute > The MS-Service Quality attribute is used to convey information about = the data stream that the protocol client is intending to transfer over = an allocated port. The protocol client SHOULD<21> include this attribute = as part of an Allocate request message. A TURN server SHOULD use the = information in this attribute to make decisions about resource = allocation, bandwidth prioritization, and data delivery methods. If the = attribute is not present in the Allocate request message, the TURN = server SHOULD assume that the data stream is audio with best effort = delivery. The format of this attribute is as follows... > ... > The following stream types are supported in this extension. All other = stream types are reserved for future use. > =A7 "0x0001": Audio > =A7 "0x0002": Video > =A7 "0x0003": Supplemental Video > =A7 "0x0004": Data > Service Quality (2 bytes): The service quality level required by the = protocol client for the stream. > The following service quality levels are supported in this extension. = All other service quality levels are reserved for future use. > =A7 "0x0000": Best effort delivery. > =A7 "0x0001": Reliable delivery. > =20 > =20 > -----Ursprungligt meddelande----- > Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] F=F6r = Harald Alvestrand > Skickat: den 8 oktober 2013 13:01 > Till: rtcweb@ietf.org > =C4mne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] = WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 > =20 > On 10/08/2013 09:17 AM, Karl Stahl wrote: > > Hej Magnus, > >=20 > >> Also, are you really interested in knowing that it is VP9 vs H.264,=20= > >> isn't > > the questions this is video of this priority that is important? > >> I think you need to more carefully consider what are the goals you > >> try to > > achieve them. > >=20 > > Actually, my concern is to get an idea of the maximum bandwidth that > > could be required for a WebRTC (ICE) setup media flow. Both voice = and > > video should be prioritized over data (their individual priority is = of > > less importance as long as there is sufficient bandwidth for both). > =20 > You don't know that without knowing what the application is for. > In, for instance, a shooter game with voice backchannels, the movement = and event information (data) is MORE time sensitive than the voice data. > =20 > >=20 > > With diffserv you don=92t need to know the bandwidth requirement, = but=20 > > with RSVP reservation (like in cable and mobile networks) you need = to > > know how much to reserve. Voice is like 100's kbit/s, video VP8 or > > H.264 is like 3,5 mbps. > =20 > Again, without knowing the application, you don't know that. > The application could decide to use QCIF or HD, and the bandwidth = variation of screencast (semi-static with sudden, large changes) is = completely different from that of a talking head, which is again = completely different from a high-movement scene. > =20 > >=20 > > To add to the complication of codec variants, the video codecs in=20 > > question for WebRTC have variable bandwidth, and when there is a = poor=20 > > connection we see Chrome reducing the video window size to reduce = the bandwidth used... > >=20 > > I think the payload type field at best can reflect a maximum = bandwidth > > to initially reserve bandwidth for, and thereafter make new > > reservations if the bandwidth changes during the call. So could we > > change RTP to show maximum bandwidth instead of payload type in that > > field outside the encrypted payload :) ... Or maybe that is not a = joke? > =20 > I think these ruminations only lead to one conclusion: > =20 > You can't tell what the needed bandwidth is up front without asking = the application. > You can't tell what the right priority ranking is without asking the = application. > =20 > If you need to know the bandwidth or the priority up front, the = application has to tell you. Anything else is pure heuristics. > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > =20 > =20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ > =20 > =20 > =20 --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_B2EC0CF9-4C12-4B53-B965-573E2AE51D13 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Karl,

I sympathise with your = goal, but I really do not think RTP header extensions are appropriate = for this purpose.

Ignoring the semantic = mismatch, in order to identify an RTP header extension, you need access = to the signalling data, and if you have access to the signalling, you = can signal the QoS parameters without using = RTP. 

You state that only the payload is = encrypted in SRTP. That is not necessarily true. RTP header extensions = can be encrypted when RFC 6904 is in use, and rtcweb-rtp-usage draft = recommends this be done in some cases. The signalling channel is also = likely encrypted end-to-end in new applications, so making it difficult = to extract the information you need to parse the RTP header extension, = even if it is unencrypted. 

Besides these = focussed issues, I would also urge you to consider the much broader = comments Magnus made. The QoS problem is broad, and a point solution = based on RTP header extensions - even if it were workable, which I doubt = - would address only a small part of the problem = space.

Colin


<= div>

On 25 Feb 2014, at 01:45, Karl Stahl = <karl.stahl@intertex.se> = wrote:

Colin,

 

If the below were the case, it would be =93DPI = guesswork=94 that I also advice against. RTP doesn=92t even have unique = protocol header within UDP =96 it can even be confused with other UDP = payload.

 

However, if the RTP is captured in a TURN-flow, as in = TRAM Milestone 3, the network point that this flow is directed to and = can apply QoS methods relevant to the network (which is not diffserve in = Mobile OTT and Cable Networks) has not a too difficult tasks. Linking = each RTP-flow by its ID and sequence number, and picking exactly the = right traffic type and bandwidth parameters is doable (see inline below, = we at Ingate do it already)!

 

Also DiffServ DSCP-bits are seldom maintained crossing = network boundaries, thus carrying no relevant information at the = receiving end, while the RTP extension header remains unchanged = end-to-end. In DSCP-bits, there is no bandwidth requirement information = when entering networks requiring reservation. That is always (and = dynamically set) available in the RTP extension header for each = packet.

 

And, I am sure you are aware of the difficulties of = getting DSCP-bits through OS sockets, which is even worse with multiple = streams over the same UDP-port

 

Further, defining the QoS RTP extension header as in = RFC5285, does not in anyway conflict with other RTP extension headers or = DSCP transfer or settings.

 

/Karl

 

Fr=E5n: Colin Perkins [mailto:csp@csperkins.org] =
Skickat: den 24 februari 2014 23:52
Till: Karl = Stahl
Kopia: rtcweb@ietf.org; Magnus Westerlund; = tram@ietf.org; Harald = Alvestrand
=C4mne: Re: [rtcweb] [tram] Payload Types = assignments

 

Karl,

 

I strongly disagree with this suggestion. An RTP = header extension, located at an unknown and variable offset into a = packet that does not have a well-defined magic number in the header, =

This is how to find the traffic info:

   The payload of the classifier header extension = element can be encoded

   using either the one-byte or two-byte header = defined in [rfc5285] and

   shown below in Figure 1 and 2 = below.

 

      = 0            &= nbsp;      = 1            &= nbsp;      = 2            &= nbsp;      3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |  ID   | len=3D1 = |   Namespace   |    = Value      |    0 = (pad)    |

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

          &nb= sp;  Figure 1: Classifier Using the One-Byte = Header

 

      0     =             &n= bsp; 1          &nb= sp;        = 2            &= nbsp;      3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |      = ID       |    = len=3D2      |   = Namespace   |    = Value      |

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

          &nb= sp;  Figure 2: Classifier Using the Two-Byte = Header

 

indicated using a dynamically assigned identifier that is = conveyed in an out-of-band

--- It is the TURN flow!!! Requested by the ICE = protocol for the specific media to come!

and encrypted signalling = channel,

--- Only the payload is encrypted in SRTP =96 leaving = id, seq no and header ext to be used as = intended!

--- Thus being the appropriate = place=85

is not an appropriate place to put QoS information that = has to be processed on a per-packet basis.

If you want DiffServ, you know = where to find it.

--- True, = but if it cannot be used=85

Colin

 

 

On 24 Feb 2014, at 22:09, Karl Stahl <karl.stahl@intertex.se> = wrote:

I suggest to the RTCWEB WG that the below from the = September and October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html = is introduced into draft-ietf-rtcweb-rtp-usage= for usage of RFC 5285, to = allow:

 

(1) WebRTC applications to directly convey QoS related = real-time traffic info to the network at points where RTP flow is = directed to by TRAM Milstone 3, to be used by *any network element = implementing any suitable QoS methods for the particular network* = for

(2) *all* WebRTC browsers *and* clients, = under *all* OSs, and *all* current and future IP network, = to achieve best QoE

(3) *without* having to force WebRTC into application specific = networks (such as IMS) instead of using the Internet (including = OTT).

 

The only further activity required, is to call for = ISPs=92 to review whether the traffic information transferred by RFC = 5285 is sufficient for current and future needs in their network as = suggested in below repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip>

=85two parameters (e.g. two bytes each) are encoded into the RTP = header extension:

 

A) The maximum bandwidth requirement: Two bytes could contain = everything from some bps for real-time text to Gbps for future 3D = supersize telepresence=85 on a logarithmic = scale.

 

B) The quality characteristics for the stream, with the highest = bit set to 1, we could allocate a bit each for quality type = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay = Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, = Prioritize X, Variation Y, that could be combined as required to = describe the stream.

 

And with highest bit set to 0, there could instead be a number for = special usage that does not fit the general description of the = individual bits.

</snip>

 

Then this could be assigned numbers to have an RFC in = place.

 

With TRAM milestone 3 also place, =

market forces will drive ISPs and browser makers to = implement just this, without even having it = MUST-established.

 

=93Who does not want a =93WebRTC-Ready=94 Internet = access?=94 and

=93Who wants to use Chrome, if Firefox, Internet = Explorer or Safari comes with much better QoE?=94 and vice = versa.

 

Please see further emails soon following this one, for = details and history.

 

/Karl

 

 

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org= ] F=F6r Karl Stahl
Skickat: den 22 oktober 2013 = 16:37
Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus = Westerlund'
Kopia: 'Colin Perkins'
=C4mne: [rtcweb] = [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

Harald, I mostly agree with the quality requirements of = different real-time traffic that the WebRTC browser/application may use. = But rather than asking the application, let's convey the bandwidth and = priority requirements to the network. Just like with the Payload type = (that is hard to squeeze that information into) it must be visible to = the network (and not changed by the network, like diffserv bits are). = Such marking must also be available for incoming traffic, which is = especially important in RSVP type of networks, that has to reserve = bandwidth for it.  

 

There is actually a good = way to show these needs to the network (without using the PT, or = diffserv bits, which aren=92t sufficient anyway). =

 

Let's use the RTP header extension field that also is = visible outside the encrypted payload. A week ago came ht= tp://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 =  that outlines the usage of the extension field for classification = of traffic! This document does not yet outline what to put in there and = how to encode it though.

 

Today's http://= tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other = webrtc usages of the RTP header extension in 5.2 (there can be many = header extensions according to RFC 5285) and in 9 there is "WebRTC Use = of RTP: Future Extensions".

 

So, it looks obvious to use = the RTP header extension to show the characteristics and bandwidth = requirements to the network. It should not introduce any backward = incompatibilities either.

 

Such marking is done in = every RTP packet so it can be set individually for each stream and could = even be changed during a session (e.g. when limiting the bandwidth based = on RTCP feedback). RFC 5286 also specifies how RTP extension header = usage can be negotiated in SDP. I think this could be easily done by the = WebRTC browser for "all current and future needs" if properly specified = now.

 

I suggest that two parameters (e.g. two bytes each) are = encoded into the RTP header extension:

 

A) The maximum bandwidth = requirement: Two bytes could contain everything from some bps for = real-time text to Gbps for future 3D supersize telepresence=85 on a = logarithmic scale.

 

B) The quality characteristics for the stream, with the = highest bit set to 1, we could allocate a bit each quality = e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, = Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable = Delivery, Prioritize X, Variation Y, that could be combined as required = to describe the stream.

 

And with highest bit set to = 0, there could instead be a number for special usage that does not fit = the general description of the individual bits.

 

Please note the totally = different requirements a diffserv and an RSVP network have to know, so = let=92s put all into these bytes. (E.g. a diffserv network don't need = the bandwidth usage, but RSVP reservation networks (e.g. cable and 3G/4G = OTT) do. There one should initially reserve the maximum bandwidth = indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft= seems to have done work in this field, defining a proprietary attribute = =93MS Service Quality=94;

However = that seems to apply to the TURN server allocation request and would = therefore:

--- = Apply to the whole UDP flow, and could not be set for each stream = individually (with different requirements), and

--- = Does not handle the bandwidth requirement for incoming real-time traffic = (required to reserve in RSVP type of networks)

However = the quality attributes conveyed and their encoding may  be = considered.

 

This is = 2.2.2.19 MS-Service Quality Attribute from

http://msdn.microsoft.com/en-us/library/cc431507(v=3Doffice.12).aspx<= /a> 

 

MS-Servic= e Quality Attribute

The = MS-Service Quality attribute is used to convey information about the = data stream that the protocol client is intending to transfer over an = allocated port. The protocol client SHOULD<21> include this = attribute as part of an Allocate request message. A TURN server SHOULD = use the information in this attribute to make = decisions about resource allocation, bandwidth prioritization, and data = delivery methods. If the attribute is not present in the Allocate = request message, the TURN server SHOULD assume that the data stream is = audio with best effort delivery. The format of this attribute is as = follows...

...

The = following stream types are supported in this extension. All other stream = types are reserved for future use.

=A7 = "0x0001":= Audio

=A7 "0x0002":= Video

=A7 "0x0003":= Supplemental Video

=A7 = "0x0004":= Data

Service = Quality (2 bytes): The service quality level required by the protocol = client for the stream.

The = following service quality levels are supported in this extension. All = other service quality levels are reserved for future = use.

=A7 "0x0000":= Best effort delivery.

=A7 = "0x0001":= Reliable delivery.

 

 

-----Ursprungligt = meddelande-----

Fr=E5n: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org= ] F=F6r Harald Alvestrand

Skickat:= den 8 oktober 2013 13:01

Till: = rtcweb@ietf.org

=C4mne: Re: [rtcweb] Payload = Types assignments was Re: SV: [mmusic] WGLC of = draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, = Karl Stahl wrote:

> Hej Magnus,

> 

>> Also, are you = really interested in knowing that it is VP9 vs H.264, =

>> isn't

> the questions this is = video of this priority that is important?

>> I think you need to = more carefully consider what are the goals you

>> try = to

> achieve them.

> 

> Actually, my concern is = to get an idea of the maximum bandwidth that

> could be required for a = WebRTC (ICE) setup media flow. Both voice and

> video should be = prioritized over data (their individual priority is of =

> = less importance as long as there is sufficient bandwidth for = both).

 

You don't know that without knowing what the application = is for.

In, for instance, a shooter game with voice backchannels, = the movement and event information (data) is MORE time sensitive than = the voice data.

 

> 

> With diffserv you don=92t= need to know the bandwidth requirement, but

> with RSVP reservation = (like in cable and mobile networks) you need to

> know how much to = reserve. Voice is like 100's kbit/s, video VP8 or =

> = H.264 is like 3,5 mbps.

 

Again, without knowing the = application, you don't know that.

The application could decide = to use QCIF or HD, and the bandwidth variation of screencast = (semi-static with sudden, large changes) is completely different from = that of a talking head, which is again completely different from a = high-movement scene.

 

> 

> To add to the = complication of codec variants, the video codecs in =

> = question for WebRTC have variable bandwidth, and when there is a poor =

> = connection we see Chrome reducing the video window size to reduce the = bandwidth used...

> 

> I think the payload = type field at best can reflect a maximum bandwidth =

> = to initially reserve bandwidth for, and thereafter make new =

> = reservations if the bandwidth changes during the call. So could we =

> = change RTP to show maximum bandwidth instead of payload type in that =

> = field outside the encrypted payload :) ... Or maybe that is not a = joke?

 

I think these ruminations only lead to one = conclusion:

 

You can't tell what the needed bandwidth is up front = without asking the application.

You can't tell what the = right priority ranking is without asking the = application.

 

If you need to know the bandwidth or the priority up = front, the application has to tell you. Anything else is pure = heuristics.

 

_______________________________________________=

rtcweb mailing = list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb

 

 

-- 

Colin = Perkins

 

 

 




-- 
Colin Perkins



= --Apple-Mail=_B2EC0CF9-4C12-4B53-B965-573E2AE51D13-- From nobody Tue Feb 25 17:05:53 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FD81A07C2; Tue, 25 Feb 2014 17:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 cxSYv_cbsDCK; Tue, 25 Feb 2014 17:05:42 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id D3B1C1A02B7; Tue, 25 Feb 2014 17:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=935; q=dns/txt; s=iport; t=1393376741; x=1394586341; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=yNIMfGZtx/M87S1vSY2rtv3mckbqwIPScAeDpkRjC0Q=; b=GNlDzGs3ZLtwtLpQkSTSFSBWU6QrKg2GDd0FWWw+swdfdJ7Io13j4q7n EYbUnI7XCpa/s14Q2pW1KeipCAw7n2bm1WcKDHvitntpt2XRhdZgQ7zGB EQKFMJxm8ghNBR6wNEKn4F1mKGPTgfWJe5DxYHHDN2T0g48sBUbgdKzNO s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAKo8DVOtJV2Y/2dsb2JhbABZgwaBEsEAgRYWdIIlAQEBAwF5BQsCAQg7CzIlAgQBDQWHfQjITxeOHTMHgySBFAEDiRGPJZIogW+BPoIq X-IronPort-AV: E=Sophos;i="4.97,543,1389744000"; d="scan'208";a="23188606" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 26 Feb 2014 01:05:38 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q15dO2015243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 01:05:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 19:05:38 -0600 From: "Cullen Jennings (fluffy)" To: Karl Stahl , IESG IESG Thread-Topic: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqA Date: Wed, 26 Feb 2014 01:05:38 +0000 Message-ID: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> In-Reply-To: <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.131] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <92E892439623E54DB28673572FBE9B78@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/V8-XIMxXuA_vTCOGTtwV1JWSfy4 Cc: Magnus Westerlund , Ted Hardie , "tram@ietf.org" , Simon Perreault , Gonzalo Camarillo , Spencer Dawkins , "rtcweb@ietf.org" Subject: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 01:05:45 -0000 On Feb 25, 2014, at 7:02 AM, Karl Stahl wrote: > To the TRAM WG and RTCWEB WG and ADs: > =20 > It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed an= d encouraged to route quality demanding WebRTC media into their IP pipes th= at are capable of transporting real-time traffic without quality issues, us= ing TURN servers. > =20 Reading the charter, the above is *not* at all a clear objective of the WG = (note I am not the chair of this WG or the responsible AD).=20 That said, I think you have pointed out this charter is abysmally vague - i= t does not say what the WG is not going to do. If I decided to do BGP for r= outing updates over TURN it would be within the scope of this charter.=20 My advice to the responsible AD is recharter this WG before IETF 90 or clos= e it. I would be glad to help write a charter that is not an infinite blank= cheque.=20 From nobody Tue Feb 25 17:08:22 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E781A081D; Tue, 25 Feb 2014 17:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 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, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 FyYRhFPCjTe1; Tue, 25 Feb 2014 17:08:10 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 250671A07E6; Tue, 25 Feb 2014 17:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1168; q=dns/txt; s=iport; t=1393376889; x=1394586489; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4Qs9+nTll9I033HCkpX0hQUbPUAzdcmj8dLGg2AZ5uE=; b=N5lGxS8zpkIFbHbCUFYd+v7U/1mYWf32n1gXsCgZfXKDOysGUH9sib60 KWJxF0meuqoJbBT3kVG+tsnqGXrIQa3KYAm4I+cePd0xzcZiZ3hCsgYTw T+1FC7kb7WLNwEvpXGGsjTB7/tqA8Zwsby52lSYZBL4Xdb7xhuAAJAaeQ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAIo9DVOtJV2Z/2dsb2JhbABZgwiBDbx7gRcWAXSDfQEBAQMBeRACAQgYIwsyJQIEAQ0Fh3wIwCUXjkEBARwzB4MjgRMBA4kLjwuSFIFtgT6BcTk X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208";a="303476557" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 26 Feb 2014 01:08:09 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q188Jb029714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 01:08:09 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 19:08:08 -0600 From: "Cullen Jennings (fluffy)" To: Karl Stahl , IESG IESG Thread-Topic: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqAgAAAs4A= Date: Wed, 26 Feb 2014 01:08:08 +0000 Message-ID: <6031F972-6ECA-4E56-A36C-E2F4A336B718@cisco.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.131] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8A70C41710040141BF2BD55E91D0D999@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/m0JfsyWIeCUTZUOHaUs1Brrrd9k Cc: "rtcweb@ietf.org" , "tram@ietf.org" , Spencer Dawkins Subject: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 01:08:15 -0000 resend because the IETF mail lists said I had to many people in the to line= =20 On Feb 26, 2014, at 9:05 AM, Cullen Jennings wrote: >=20 >=20 > On Feb 25, 2014, at 7:02 AM, Karl Stahl wrote: >=20 >> To the TRAM WG and RTCWEB WG and ADs: >>=20 >> It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed a= nd encouraged to route quality demanding WebRTC media into their IP pipes t= hat are capable of transporting real-time traffic without quality issues, u= sing TURN servers. >>=20 >=20 > Reading the charter, the above is *not* at all a clear objective of the W= G (note I am not the chair of this WG or the responsible AD).=20 >=20 > That said, I think you have pointed out this charter is abysmally vague -= it does not say what the WG is not going to do. If I decided to do BGP for= routing updates over TURN it would be within the scope of this charter.=20 >=20 > My advice to the responsible AD is recharter this WG before IETF 90 or cl= ose it. I would be glad to help write a charter that is not an infinite bla= nk cheque.=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Tue Feb 25 17:08:38 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819C41A0831; Tue, 25 Feb 2014 17:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 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, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 38nDPWu6tkvS; Tue, 25 Feb 2014 17:08:23 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id AC1491A0829; Tue, 25 Feb 2014 17:08:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1168; q=dns/txt; s=iport; t=1393376903; x=1394586503; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4Qs9+nTll9I033HCkpX0hQUbPUAzdcmj8dLGg2AZ5uE=; b=Wcdar7//LJrHkn6IceQ6MzmPjqFBAzxteBbpt0ALWB1ixx4Qbg8yR2MS iFtiSXQLSNh6dUbpiVTVQ+WnkJjM+hNvEi9zSjCWb+Nyxmw7WvUZfv98Z jcFvCArKUTKaSDOBVYGux2JutHQjPxt8UrAaeNA3inGgQHUdo2Amyyvjv M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAEQ+DVOtJXG9/2dsb2JhbABZgwaBEsEAgRYWdIIlAQEBAwF5EAIBCBgjCzIlAgQBDQWHfQjITReNfwEBHDMHgySBFAEDiRGPJZIogW+BPoFxOQ X-IronPort-AV: E=Sophos;i="4.97,543,1389744000"; d="scan'208";a="306512571" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 26 Feb 2014 01:08:10 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q18AGn008805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 01:08:10 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 19:08:09 -0600 From: "Cullen Jennings (fluffy)" To: Karl Stahl , IESG IESG Thread-Topic: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqAgAAAtAA= Date: Wed, 26 Feb 2014 01:08:09 +0000 Message-ID: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <04ff01cf31b4$8eb73780$ac25a680$@stahl@intertex.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.131] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <69D38DADC55F7E41B295F9A389A878BF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Z9lHDrru0Rr1hEwvVEAyypkgyKA Cc: "rtcweb@ietf.org" , "tram@ietf.org" , Spencer Dawkins Subject: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 01:08:27 -0000 resend because the IETF mail lists said I had to many people in the to line= =20 On Feb 26, 2014, at 9:05 AM, Cullen Jennings wrote: >=20 >=20 > On Feb 25, 2014, at 7:02 AM, Karl Stahl wrote: >=20 >> To the TRAM WG and RTCWEB WG and ADs: >>=20 >> It must be a clear objective of the TRAM WG that ISPs/NSPs are allowed a= nd encouraged to route quality demanding WebRTC media into their IP pipes t= hat are capable of transporting real-time traffic without quality issues, u= sing TURN servers. >>=20 >=20 > Reading the charter, the above is *not* at all a clear objective of the W= G (note I am not the chair of this WG or the responsible AD).=20 >=20 > That said, I think you have pointed out this charter is abysmally vague -= it does not say what the WG is not going to do. If I decided to do BGP for= routing updates over TURN it would be within the scope of this charter.=20 >=20 > My advice to the responsible AD is recharter this WG before IETF 90 or cl= ose it. I would be glad to help write a charter that is not an infinite bla= nk cheque.=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Wed Feb 26 05:04:01 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4251A0347; Tue, 25 Feb 2014 16:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.048 X-Spam-Level: X-Spam-Status: No, score=-115.048 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, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 69nlIGbNGkxe; Tue, 25 Feb 2014 16:49:21 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC4F1A0344; Tue, 25 Feb 2014 16:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7561; q=dns/txt; s=iport; t=1393375760; x=1394585360; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Gjr1/S77deWA/P5Y9rYPPKXF5CccXvn4E/jwoNHIrAE=; b=Hw1jv74wPj3BuhRnQIdYG6p9ZtgXL8ouUIsa2oA79jAUTaUHYpqMmm0L 5R1i9wqsd4mVPuFM7nqxu1Vyta1G9nTy5MDCiS2Xfc+UyXzEaRvqmINWM ck9C+3DCwD6lwtLfed+ZRzA9zfNufc2F0+CmYQTHLiR4T0YpNlAdVvegw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAJc5DVOtJV2d/2dsb2JhbABWA4MGO1fAMU+BFRZ0giUBAQEDAQEBAWQHCwULAgEIEQQBAQEnByEGCxQJCAIEDgUJh2gDCQgNwHcNh0AXjDyBMhACARwjEAIFEYMTgRQElkmBbYEyiy+FR4Mtgio X-IronPort-AV: E=Sophos;i="4.97,543,1389744000"; d="scan'208";a="306473291" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 26 Feb 2014 00:49:19 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q0nJqh007524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 00:49:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 18:49:19 -0600 From: "Cullen Jennings (fluffy)" To: Karl Stahl Thread-Topic: [rtcweb] [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt Thread-Index: AQHPMoyUg60iiUWRskCpUFa2PiKTiQ== Date: Wed, 26 Feb 2014 00:49:18 +0000 Message-ID: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <050401cf31bf$64ae8ff0$2e0bafd0$@stahl@intertex.se> In-Reply-To: <050401cf31bf$64ae8ff0$2e0bafd0$@stahl@intertex.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.131] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/8oD4EmSutu7JUqCOK48Xv9au_lA X-Mailman-Approved-At: Wed, 26 Feb 2014 05:03:41 -0800 Cc: Marc Robins , "tram@ietf.org" , Bernard Aboba , Harald Tveit Alvestrand , "rtcweb@ietf.org" , Eric Burger , Mary Barnes , Alan Johnston , David Singer , Henning Schulzrinne Subject: Re: [tram] [rtcweb] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 00:49:28 -0000 Karl,=20 I am totally lost on this thread. Could you start a new tmead that summariz= e what the issues is, what seems to be the point of debate, and what your v= iew is on what we should do. I think that would help make progress.=20 Thank you,=20 Cullen=20 On Feb 25, 2014, at 8:20 AM, Karl Stahl wrote: > Hi Alan, > =20 > I have in previous email http://www.ietf.org/mail-archive/web/tram/curren= t/msg00304.html suggested that both DISCUSS and draft-thomson-tram-turn-ban= dwidth-00.txt is taken off the TRAM WG, but I think is shall be reintroduce= d after you clarify as you do in > http://www.ietf.org/mail-archive/web/tram/current/msg00300.html : > Hi Karl, Thanks for your comments and feedback on the draft. > You are correct in saying that the BANDWIDTH extension is not about QoS. = It is about fairness between users of a TURN server, and a TURN server bei= ng able to indicate rate limiting policy to users. in the draft. > =20 > The =93confusion=94 (to say least, see below) surrounding QoS within IETF= has lead me to protest and address the TRAM WG and RTCWEB WG and ADs with = the advise in http://www.ietf.org/mail-archive/web/tram/current/msg00304.ht= ml : > =93The TRAM WG and RTCWEB WG chairs and ADs are advised to review whether= IETF standard work in these WGs by contributors having an interest in more= than one of current or emerging: ISPs, carrier equipment vendors or web br= owser makers, may discriminate any with an interest only in one of these. T= he same should apply to non-activity by WG contributors to remedy such disc= rimination opened by allowed proprietary usage of RFCs such as RFC 5285.=94 > =20 > This is because the introduction of the QoS related usage of RFC 5285 int= o draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 objectiv= es of TRAM, immediately would allow for: > (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in addi= tion to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP variants) to qu= ickly allow us to finally enjoy the high quality and connectivity (NAT/fire= wall traversal) of real-time communication services now possible, for =20 > (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), und= er *all* OSs, and *all* current and future IP networks > (3) *without* having to be forced into application specific networks (PST= N, IMS) instead of the Internet (including OTT). > =20 > While the =93confusion=94 surrounding the QoS discussion in TRAM and RTCW= EB combined with thegeneral QoS attitude within IETF =93it is all about ban= dwidth=94 and =93it will go away with time=94 otherwise: > (i) will *not allow* ISP=92s to use already available and currently deplo= yable quality IP pipes for real-time traffic to also be used for WebRTC gen= erated real-time traffic. > (ii) will *not allow* some network types (e.g. Cable Networks and Mobile = OTT) to borrow bandwidth from data traffic and QoS insensitive streaming vi= deo and file sharing. That all networks *will be inhibited* from the very c= ommon and used method of simply providing an extra IP pipe (often provided = over the same wire but level-2 separated) dedicated for real-time usage > (*by resisting TRAM implementation of step B*) > *while* newer, fiber only type of networks, still can borrow bandwidth at= no extra cost, *by proprietary usage* of RFC 5285 by browsers. > (iii) will leave most ISPs to *only use* raw bandwidth capacity increase = that may have to be 10-folded to reach sufficient QoE when WebRTC usage bec= omes popular (if at all possible, since unmanaged IP pipes intermittently a= re filled, whatever bandwidth is available). > =20 > As Good doers, we should not allow this to happen. > =20 > /Karl > =20 > =20 > Fr=E5n: Alan Johnston [mailto:alan.b.johnston@gmail.com]=20 > Skickat: den 21 februari 2014 18:59 > Till: Pal Martinsen (palmarti) > Kopia: tram@ietf.org; Oleg Moskalenko; Karl Stahl; Yoakum, John H (John) > =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt > =20 > I guess the way I would expect this to progress is for QoS discussions to= happen in another working group. Once that other working group came to co= nsensus on an approach, and if that approach required STUN or TURN extensio= ns, then we would discuss mechanisms and possible milestones in TRAM. > =20 > - Alan - > =20 >=20 > On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) wrote: > Hi, > =20 > I agree the full QoS discussion should _not_ happen in TRAM. If you are i= nterested in helping out in that area I suggest you looking into the AEON m= ailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are curre= ntly working on a problem-statement draft and a use-case draft, any input t= o those would be very helpful. (http://tools.ietf.org/html/draft-eckel-aeon= -use-cases-01, http://tools.ietf.org/html/draft-eckel-aeon-problem-statemen= t-00). > =20 > That said, STUN have a few nice characteristics that makes it a perfect c= andidate for transporting some of the QoS information. IMHO that would be = extending the STUN spec and should be within the TRAM charter. The main go= al of draft-martinsen-tram-discuss was to show how already existing QoS mec= hanisms could be transported with STUN to provide more value, and to start = the discussion if TRAM is the appropriate place to have those on the wire f= ormat discussions. > =20 > .-. > P=E5l-Erik > =20 > =20 > On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) wro= te: >=20 >=20 > +1 > I fully agree with the comments that QOS should be a low priority for the= initial focus of the TRAM efforts. There are other groups doing QOS work = and frankly I engage in WebRTC multimedia interactions daily over the Inter= net, enterprise VPNs, and various combinations and seldom suffer egregious = quality issues. I am more concerned about carriers doing things to regulat= e or degrade WebRTC flows than a failure of existing Internet mechanisms to= enable them. > =20 > Significant focus on QOS before we better enable TURN to be easily used i= n a browser environment taking advantage or normal web characteristics (as = opposed to historic telephony constructs) would seem to be highly distracti= ng at this point. > =20 > =20 > Cheers, > John > =20 > AVAYA > 1.919.425.8446 > =20 > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko > Sent: Thursday, February 20, 2014 12:43 PM > To: Alan Johnston > Cc: Karl Stahl; tram@ietf.org > Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00= .txt > =20 > =20 > =20 >=20 > On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston wrote: > =20 > =20 > =20 > Personally, I am not sure how much QoS is actually in scope for TRAM. Hav= e you been following RMCAT where congestion avoidance for RTP is being deve= loped? I see some overlap in your goals and the goals of that work. > - > =20 > =20 > I'd concentrate on the TURN application-level functionality, for now, and= I'd leave QoS for the future discussions. >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram > =20 > =20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Wed Feb 26 05:04:08 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C551A0822; Tue, 25 Feb 2014 17:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 W3SlUKD4UVDH; Tue, 25 Feb 2014 17:12:22 -0800 (PST) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id DFD351A0283; Tue, 25 Feb 2014 17:12:21 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id o15so1414883qap.35 for ; Tue, 25 Feb 2014 17:12:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=m52AtfZmXJfdLbH8hMpd0VTqlEjehN8vxgrzWGiG0m4=; b=hERUOWuLALRwJXWoEt4PZlXuRm/s7eb+geJOWP3HtDiva7NHuxlEpri8ZJe0AtfChM jA+eL9OkToUavWWMhshErE0N9NjjSBfsfkevFJWbHZbHzeCN9MKMplOBIhj3eLqiZMdr lbwBCk813OOGnSl80GYs504urxA8ZfrN2OpFOHl8MzF/ilLKI8NHtJdfZVMHGZ4XAe6t 3TODPaYwc3VHYdA+xQRCVWp43ZRJ4ZE0Zx2QZBC1nZnYG9ld27bmRoPmat4nq5chJtiq F78DqRjvxARTO6jICefZ7c1P5gOpoRcsGfZTNf4o48fXUwjYKq/323MkWBWkJkMFBW3T PM2g== MIME-Version: 1.0 X-Received: by 10.140.93.111 with SMTP id c102mr3894557qge.53.1393377140691; Tue, 25 Feb 2014 17:12:20 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.224.26.11 with HTTP; Tue, 25 Feb 2014 17:12:20 -0800 (PST) In-Reply-To: References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> Date: Tue, 25 Feb 2014 17:12:20 -0800 X-Google-Sender-Auth: 51AuCbqYBAnnfdQ7jMCJq3rhkKs Message-ID: From: Barry Leiba To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/iHBmnR8wY4VFnJ0tZkStXFAeoXs X-Mailman-Approved-At: Wed, 26 Feb 2014 05:03:42 -0800 Cc: Simon Perreault , Ted Hardie , "tram@ietf.org" , Magnus Westerlund , Gonzalo Camarillo , Spencer Dawkins , "rtcweb@ietf.org" , IESG IESG , Karl Stahl Subject: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 01:12:23 -0000 > That said, I think you have pointed out this charter is abysmally > vague - it does not say what the WG is not going to do. If I > decided to do BGP for routing updates over TURN it would be > within the scope of this charter. Cullen, is it your opinion that a working group is always free to do anything that's not explicitly forbidden in its charter? I think that a working group is limited to doing what *is* in its charter, and we sometimes explicitly forbid things for emphasis. The TRAM charter says this: The work will include the addition of DTLS as an additional transport, authentication mechanisms, and extensions to TURN and STUN. I don't think that would support, for example, BGP over TURN. Barry From nobody Wed Feb 26 05:04:10 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB301A0364; Tue, 25 Feb 2014 18:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 1Zt8hiCEdGYN; Tue, 25 Feb 2014 18:52:44 -0800 (PST) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id C78081A02F2; Tue, 25 Feb 2014 18:52:43 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id i11so225226oag.9 for ; Tue, 25 Feb 2014 18:52:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=zLwzm6rB6pZoVQvxqPfiQ4QoV+UwTXzcE1OyKtpPtHE=; b=PT+9tUJ9iCO/McJ1cuqhKntwiIO9+76/Ua71QkvQk6Ln9uy6Y/lsH4f1C3okr+oQ/3 k6yKjV1IDlRx7NzqZuxfety2E0/affwEk+CYyZPBEC76RemSTvHF99DKOPtr0y/TvCEw T3eWo/xZ0vOjGedF1aimVSbXGJ6xJ5pS+QUHh0wXNIKNNxbTLqZfuSeqKtKlV2NS9hoq voVVUkEqLV+FJjADzA8aO1tVtvWYTCcovK3Ln8Je0uVlhezg89A2rUyIF775tIcZKE9A Vd99BWiJmukZksq2Iyhetss9fD6lcwjsqoQxPUrY2dEu9xzLa6D7Ca0Oznq+cDz25rMC nmCQ== X-Received: by 10.182.233.228 with SMTP id tz4mr592395obc.56.1393383162646; Tue, 25 Feb 2014 18:52:42 -0800 (PST) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id u4sm50324342oev.1.2014.02.25.18.52.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Feb 2014 18:52:42 -0800 (PST) Message-ID: <530D56F7.5070900@gmail.com> Date: Tue, 25 Feb 2014 20:52:39 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Barry Leiba , "Cullen Jennings (fluffy)" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ZSSJB-X8VwuCgGfEXSF68VJFi48 X-Mailman-Approved-At: Wed, 26 Feb 2014 05:03:43 -0800 Cc: Simon Perreault , Ted Hardie , "tram@ietf.org" , Magnus Westerlund , Gonzalo Camarillo , Spencer Dawkins , "rtcweb@ietf.org" , IESG IESG , Karl Stahl Subject: [tram] BCP over TURN will not be in scope ... and MPLS over UDP over TURN will not be in scope ... and ... X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 02:52:45 -0000 So ... TRAM was chartered last Thursday ... I'm gonna let Gonzalo (Yet Another Soon-to-be Former AD Serving as WG Chair) and Simon actually chair their working group for at least a full week before intruding further, but for now, let's assume that the working group wants to work on the milestones they signed up for last week, and see how badly that assumption blows up, rather than talk about rechartering every time someone proposes a topic that's out of scope. I look forward to attending the first working group session next week, and to balloting on six TRAM drafts before IETF 92. Thanks, Spencer, as the responsible AD From nobody Wed Feb 26 05:04:11 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB981A0268; Tue, 25 Feb 2014 19:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham 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 RFbE-E2-0y0x; Tue, 25 Feb 2014 19:48:58 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF9B1A0258; Tue, 25 Feb 2014 19:48:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 6A1A27C4EA3; Wed, 26 Feb 2014 04:48:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJjqyfYCr8UE; Wed, 26 Feb 2014 04:48:51 +0100 (CET) Received: from [172.20.4.61] (unknown [64.129.1.15]) by mork.alvestrand.no (Postfix) with ESMTPSA id 3E85D7C4EA1; Wed, 26 Feb 2014 04:48:49 +0100 (CET) Message-ID: <530D641F.6010504@alvestrand.no> Date: Wed, 26 Feb 2014 04:48:47 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Colin Perkins , Karl Stahl References: <5238446D.8050700@ericsson.com> <9F33F40F6F2CD847824537F3C4E37DDF17BCF581@MCHP04MSX.global-ad.net> <07a601ceb64e$5caaba00$16002e00$@stahl@intertex.se> <07b001ceb65f$ce3f0cf0$6abd26d0$@stahl@intertex.se> <07e401ceb713$bef87a60$3ce96f20$@stahl@intertex.se> <524AB730.7040809@ericsson.com> <00b001cebfc1$ba8e89e0$2fab9da0$@stahl@intertex.se> <525272E8.5050300@ericsson.com> <050801cec3f6$6172aec0$24580c40$@stahl@intertex.se> <5253E5EB.8030608@alvestrand.no> <02bf01cecf34$35e174a0$a1a45de0$@stahl@intertex.se> <04dd01cf31ad$0fe62d00$2fb28700$@stahl@intertex.se> <580B467D-4679-4DE1-96DE-CA37DE755563@csperkins.org> <052e01cf31cb$5311a0a0$f934e1e0$@stahl@intertex.se> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------040103040302090507080803" Archived-At: http://mailarchive.ietf.org/arch/msg/tram/nZ7ImF5jdiBAdct-mYquEaHOaRw X-Mailman-Approved-At: Wed, 26 Feb 2014 05:03:42 -0800 Cc: Magnus Westerlund , rtcweb@ietf.org, tram@ietf.org Subject: Re: [tram] [rtcweb] Payload Types assignments X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 03:49:06 -0000 This is a multi-part message in MIME format. --------------040103040302090507080803 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Karl, what on Earth does TRAM milestone 3 have to do with whatever it is you're proposing? TRAM milestone 3 is: Sep 2014 - Send new proposed standard TURN server discovery mechanism for enterprises and ISPs to IESG There's no (zero, nada, none) mention of QoS within that charter. On 02/26/2014 12:49 AM, Colin Perkins wrote: > Karl, > > I sympathise with your goal, but I really do not think RTP header > extensions are appropriate for this purpose. > > Ignoring the semantic mismatch, in order to identify an RTP header > extension, you need access to the signalling data, and if you have > access to the signalling, you can signal the QoS parameters without > using RTP. > > You state that only the payload is encrypted in SRTP. That is not > necessarily true. RTP header extensions can be encrypted when RFC 6904 > is in use, and rtcweb-rtp-usage draft recommends this be done in some > cases. The signalling channel is also likely encrypted end-to-end in > new applications, so making it difficult to extract the information > you need to parse the RTP header extension, even if it is unencrypted. > > Besides these focussed issues, I would also urge you to consider the > much broader comments Magnus made. The QoS problem is broad, and a > point solution based on RTP header extensions - even if it were > workable, which I doubt - would address only a small part of the > problem space. > > Colin > > > > > On 25 Feb 2014, at 01:45, Karl Stahl > wrote: >> >> Colin, >> >> >> >> If the below were the case, it would be “DPI guesswork” that I also >> advice against. RTP doesn’t even have unique protocol header within >> UDP – it can even be confused with other UDP payload. >> >> >> >> However, if the RTP is captured in a TURN-flow, as in TRAM Milestone >> 3, the network point that this flow is directed to and can apply QoS >> methods relevant to the network (which is not diffserve in Mobile OTT >> and Cable Networks) has not a too difficult tasks. Linking each >> RTP-flow by its ID and sequence number, and picking exactly the right >> traffic type and bandwidth parameters is doable (see inline below, we >> at Ingate do it already)! >> >> >> >> Also DiffServ DSCP-bits are seldom maintained crossing network >> boundaries, thus carrying no relevant information at the receiving >> end, while the RTP extension header remains unchanged end-to-end. In >> DSCP-bits, there is no bandwidth requirement information when >> entering networks requiring reservation. That is always (and >> dynamically set) available in the RTP extension header for each packet. >> >> >> >> And, I am sure you are aware of the difficulties of getting DSCP-bits >> through OS sockets, which is even worse with multiple streams over >> the same UDP-port >> >> >> >> Further, defining the QoS RTP extension header as in RFC5285, does >> not in anyway conflict with other RTP extension headers or DSCP >> transfer or settings. >> >> >> >> /Karl >> >> >> >> *Från:*Colin Perkins [mailto:csp@csperkins.org] >> *Skickat:* den 24 februari 2014 23:52 >> *Till:* Karl Stahl >> *Kopia:* rtcweb@ietf.org ; Magnus Westerlund; >> tram@ietf.org ; Harald Alvestrand >> *Ämne:* Re: [rtcweb] [tram] Payload Types assignments >> >> >> >> Karl, >> >> >> >> I strongly disagree with this suggestion. An RTP header extension, >> located at an unknown and variable offset into a packet that does not >> have a well-defined magic number in the header, >> >> This is how to find the traffic info: >> >> The payload of the classifier header extension element can be encoded >> >> using either the one-byte or two-byte header defined in [rfc5285 >> ] and >> >> shown below in Figure 1 and 2 below. >> >> >> >> 0 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | ID | len=1 | Namespace | Value | 0 (pad) | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> Figure 1: Classifier Using the One-Byte Header >> >> >> >> 0 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | ID | len=2 | Namespace | Value | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> >> >> Figure 2: Classifier Using the Two-Byte Header >> >> >> >> indicated using a dynamically assigned identifier that is conveyed in >> an out-of-band >> >> --- It is the TURN flow!!! Requested by the ICE protocol for the >> specific media to come! >> >> and encrypted signalling channel, >> >> --- Only the payload is encrypted in SRTP – leaving id, seq no and >> header ext to be used as intended! >> >> --- Thus being the appropriate place… >> >> is not an appropriate place to put QoS information that has to be >> processed on a per-packet basis. >> >> If you want DiffServ, you know where to find it. >> >> --- True, but if it cannot be used… >> >> Colin >> >> >> >> >> >> On 24 Feb 2014, at 22:09, Karl Stahl > > wrote: >> >> I suggest to the RTCWEB WG that the below from the September and >> October discussions on the relevant [rtcweb] [avtext] >> [mmusic]lists >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html >> is introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC >> 5285, to allow: >> >> >> >> (1) WebRTC applications to directly convey QoS related real-time >> traffic info to the network at points where RTP flow is directed >> to by TRAM Milstone 3, to be used by **any network element >> implementing any suitable QoS methods for the particular >> network** for >> >> (2) **all** WebRTC browsers **and** clients, under **all** OSs, >> and **all** current and future IP network, to achieve best QoE >> >> *(3) *without* *having to force WebRTC into application specific >> networks (such as IMS) instead of using the Internet (including OTT). >> >> >> >> The only further activity required, is to call for ISPs’ to >> review whether the traffic information transferred by RFC 5285 is >> sufficient for current and future needs in their network as >> suggested in below repeated >> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html >> >> >> >> …two parameters (e.g. two bytes each) are encoded into the RTP >> header extension: >> >> >> >> A) The maximum bandwidth requirement: Two bytes could contain >> everything from some bps for real-time text to Gbps for future 3D >> supersize telepresence… on a logarithmic scale. >> >> >> >> B) The quality characteristics for the stream, with the highest >> bit set to 1, we could allocate a bit each for quality type e.g: >> >> Best Effort, Audio, Video, Supplemental Video, Gaming, Data, >> Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable >> Delivery, Prioritize X, Variation Y, that could be combined as >> required to describe the stream. >> >> >> >> And with highest bit set to 0, there could instead be a number >> for special usage that does not fit the general description of >> the individual bits. >> >> >> >> >> >> Then this could be assigned numbers to have an RFC in place. >> >> >> >> With TRAM milestone 3 also place, >> >> market forces will drive ISPs and browser makers to implement >> just this, without even having it MUST-established. >> >> >> >> “Who does not want a “WebRTC-Ready” Internet access?” and >> >> “Who wants to use Chrome, if Firefox, Internet Explorer or Safari >> comes with much better QoE?” and vice versa. >> >> >> >> Please see further emails soon following this one, for details >> and history. >> >> >> >> /Karl >> >> >> >> >> >> *Från:*rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] *För *Karl Stahl >> *Skickat:* den 22 oktober 2013 16:37 >> *Till:* 'Harald Alvestrand'; rtcweb@ietf.org >> ; 'Magnus Westerlund' >> *Kopia:* 'Colin Perkins' >> *Ämne:* [rtcweb] [avtext] Payload Types assignments was Re: SV: >> [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 >> >> >> >> Harald, I mostly agree with the quality requirements of different >> real-time traffic that the WebRTC browser/application may use. >> But rather than asking the application, let's convey the >> bandwidth and priority requirements to the network. Just like >> with the Payload type (that is hard to squeeze that information >> into) it must be visible to the network (and not changed by the >> network, like diffserv bits are). Such marking must also be >> available for incoming traffic, which is especially important in >> RSVP type of networks, that has to reserve bandwidth for it. >> >> >> >> There is actually a good way to show these needs to the network >> (without using the PT, or diffserv bits, which aren’t sufficient >> anyway). >> >> >> >> Let's use the RTP header extension field that also is visible >> outside the encrypted payload. A week ago came >> http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00 >> that outlines the usage of the extension field for >> classification of traffic! This document does not yet outline >> what to put in there and how to encode it though. >> >> >> >> Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 >> discusses other webrtc usages of the RTP header extension in 5.2 >> (there can be many header extensions according to RFC 5285) and >> in 9 there is "WebRTC Use of RTP: Future Extensions". >> >> >> >> So, it looks obvious to use the RTP header extension to show the >> characteristics and bandwidth requirements to the network. It >> should not introduce any backward incompatibilities either. >> >> >> >> Such marking is done in every RTP packet so it can be set >> individually for each stream and could even be changed during a >> session (e.g. when limiting the bandwidth based on RTCP >> feedback). RFC 5286 also specifies how RTP extension header usage >> can be negotiated in SDP. I think this could be easily done by >> the WebRTC browser for "all current and future needs" if properly >> specified now. >> >> >> >> I suggest that two parameters (e.g. two bytes each) are encoded >> into the RTP header extension: >> >> >> >> A) The maximum bandwidth requirement: Two bytes could contain >> everything from some bps for real-time text to Gbps for future 3D >> supersize telepresence… on a logarithmic scale. >> >> >> >> B) The quality characteristics for the stream, with the highest >> bit set to 1, we could allocate a bit each quality e.g: >> >> Best Effort, Audio, Video, Supplemental Video, Gaming, Data, >> Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable >> Delivery, Prioritize X, Variation Y, that could be combined as >> required to describe the stream. >> >> >> >> And with highest bit set to 0, there could instead be a number >> for special usage that does not fit the general description of >> the individual bits. >> >> >> >> Please note the totally different requirements a diffserv and an >> RSVP network have to know, so let’s put all into these bytes. >> (E.g. a diffserv network don't need the bandwidth usage, but RSVP >> reservation networks (e.g. cable and 3G/4G OTT) do. There one >> should initially reserve the maximum bandwidth indicated, but can >> later re-reserve.) >> >> >> >> /Karl >> >> >> >> PS Microsoft seems to have done work in this field, defining a >> proprietary attribute “MS Service Quality”; >> >> However that seems to apply to the TURN server allocation request >> and would therefore: >> >> --- Apply to the whole UDP flow, and could not be set for each >> stream individually (with different requirements), and >> >> --- Does not handle the bandwidth requirement for incoming >> real-time traffic (required to reserve in RSVP type of networks) >> >> However the quality attributes conveyed and their encoding may >> be considered. >> >> >> >> This is 2.2.2.19 MS-Service Quality Attribute from >> >> http://msdn.microsoft.com/en-us/library/cc431507(v=office.12).aspx >> >> >> >> /MS-Service Quality Attribute/ >> >> /The MS-Service Quality attribute is used to convey information >> about the data stream that the protocol client is intending to >> transfer over an allocated port. The protocol client SHOULD<21> >> include this attribute as part of an Allocate request message. A >> TURN server SHOULD use the information in this attribute to make >> decisions about resource allocation, bandwidth prioritization, >> and data delivery methods. If the attribute is not present in the >> Allocate request message, the TURN server SHOULD assume that the >> data stream is audio with best effort delivery. The format of >> this attribute is as follows... / >> >> /.../ >> >> /The following stream types are supported in this extension. All >> other stream types are reserved for future use./ >> >> /§ //"0x0001": Audio/ >> >> /§ //"0x0002": Video/ >> >> /§ //"0x0003": Supplemental Video/ >> >> /§ //"0x0004": Data/ >> >> /Service Quality (2 bytes): The service quality level required by >> the protocol client for the stream./ >> >> /The following service quality levels are supported in this >> extension. All other service quality levels are reserved for >> future use./ >> >> /§ //"0x0000": Best effort delivery./ >> >> /§ //"0x0001": Reliable delivery./ >> >> >> >> >> >> -----Ursprungligt meddelande----- >> >> Från: rtcweb-bounces@ietf.org >> [mailto:rtcweb-bounces@ietf.org] För Harald Alvestrand >> >> Skickat: den 8 oktober 2013 13:01 >> >> Till: rtcweb@ietf.org >> >> Ämne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] >> WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11 >> >> >> >> On 10/08/2013 09:17 AM, Karl Stahl wrote: >> >> > Hej Magnus, >> >> > >> >> >> Also, are you really interested in knowing that it is VP9 vs H.264, >> >> >> isn't >> >> > the questions this is video of this priority that is important? >> >> >> I think you need to more carefully consider what are the goals you >> >> >> try to >> >> > achieve them. >> >> > >> >> > Actually, my concern is to get an idea of the maximum bandwidth >> that >> >> > could be required for a WebRTC (ICE) setup media flow. Both >> voice and >> >> > video should be prioritized over data (their individual priority >> is of >> >> > less importance as long as there is sufficient bandwidth for both). >> >> >> >> You don't know that without knowing what the application is for. >> >> In, for instance, a shooter game with voice backchannels, the >> movement and event information (data) is MORE time sensitive than >> the voice data. >> >> >> >> > >> >> > With diffserv you don’t need to know the bandwidth requirement, but >> >> > with RSVP reservation (like in cable and mobile networks) you >> need to >> >> > know how much to reserve. Voice is like 100's kbit/s, video VP8 or >> >> > H.264 is like 3,5 mbps. >> >> >> >> Again, without knowing the application, you don't know that. >> >> The application could decide to use QCIF or HD, and the bandwidth >> variation of screencast (semi-static with sudden, large changes) >> is completely different from that of a talking head, which is >> again completely different from a high-movement scene. >> >> >> >> > >> >> > To add to the complication of codec variants, the video codecs in >> >> > question for WebRTC have variable bandwidth, and when there is a >> poor >> >> > connection we see Chrome reducing the video window size to >> reduce the bandwidth used... >> >> > >> >> > I think the payload type field at best can reflect a maximum >> bandwidth >> >> > to initially reserve bandwidth for, and thereafter make new >> >> > reservations if the bandwidth changes during the call. So could we >> >> > change RTP to show maximum bandwidth instead of payload type in >> that >> >> > field outside the encrypted payload :) ... Or maybe that is not >> a joke? >> >> >> >> I think these ruminations only lead to one conclusion: >> >> >> >> You can't tell what the needed bandwidth is up front without >> asking the application. >> >> You can't tell what the right priority ranking is without asking >> the application. >> >> >> >> If you need to know the bandwidth or the priority up front, the >> application has to tell you. Anything else is pure heuristics. >> >> >> >> _______________________________________________ >> >> rtcweb mailing list >> >> rtcweb@ietf.org >> >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> >> >> >> >> -- >> >> Colin Perkins >> >> http://csperkins.org/ >> >> >> >> >> >> >> > > > > -- > Colin Perkins > http://csperkins.org/ > > > -- Surveillance is pervasive. Go Dark. --------------040103040302090507080803 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Karl,

what on Earth does TRAM milestone 3 have to do with whatever it is you're proposing?

TRAM milestone 3 is:

Sep 2014 - Send new proposed standard TURN server discovery mechanism for enterprises and ISPs to IESG

There's no (zero, nada, none) mention of QoS within that charter.


On 02/26/2014 12:49 AM, Colin Perkins wrote:
Karl,

I sympathise with your goal, but I really do not think RTP header extensions are appropriate for this purpose.

Ignoring the semantic mismatch, in order to identify an RTP header extension, you need access to the signalling data, and if you have access to the signalling, you can signal the QoS parameters without using RTP. 

You state that only the payload is encrypted in SRTP. That is not necessarily true. RTP header extensions can be encrypted when RFC 6904 is in use, and rtcweb-rtp-usage draft recommends this be done in some cases. The signalling channel is also likely encrypted end-to-end in new applications, so making it difficult to extract the information you need to parse the RTP header extension, even if it is unencrypted. 

Besides these focussed issues, I would also urge you to consider the much broader comments Magnus made. The QoS problem is broad, and a point solution based on RTP header extensions - even if it were workable, which I doubt - would address only a small part of the problem space.

Colin




On 25 Feb 2014, at 01:45, Karl Stahl <karl.stahl@intertex.se> wrote:

Colin,

 

If the below were the case, it would be “DPI guesswork” that I also advice against. RTP doesn’t even have unique protocol header within UDP – it can even be confused with other UDP payload.

 

However, if the RTP is captured in a TURN-flow, as in TRAM Milestone 3, the network point that this flow is directed to and can apply QoS methods relevant to the network (which is not diffserve in Mobile OTT and Cable Networks) has not a too difficult tasks. Linking each RTP-flow by its ID and sequence number, and picking exactly the right traffic type and bandwidth parameters is doable (see inline below, we at Ingate do it already)!

 

Also DiffServ DSCP-bits are seldom maintained crossing network boundaries, thus carrying no relevant information at the receiving end, while the RTP extension header remains unchanged end-to-end. In DSCP-bits, there is no bandwidth requirement information when entering networks requiring reservation. That is always (and dynamically set) available in the RTP extension header for each packet.

 

And, I am sure you are aware of the difficulties of getting DSCP-bits through OS sockets, which is even worse with multiple streams over the same UDP-port

 

Further, defining the QoS RTP extension header as in RFC5285, does not in anyway conflict with other RTP extension headers or DSCP transfer or settings.

 

/Karl

 

Från: Colin Perkins [mailto:csp@csperkins.org]
Skickat: den 24 februari 2014 23:52
Till: Karl Stahl
Kopia: rtcweb@ietf.org; Magnus Westerlund; tram@ietf.org; Harald Alvestrand
Ämne: Re: [rtcweb] [tram] Payload Types assignments

 

Karl,

 

I strongly disagree with this suggestion. An RTP header extension, located at an unknown and variable offset into a packet that does not have a well-defined magic number in the header,

This is how to find the traffic info:

   The payload of the classifier header extension element can be encoded

   using either the one-byte or two-byte header defined in [rfc5285] and

   shown below in Figure 1 and 2 below.

 

      0                   1                   2                   3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |  ID   | len=1 |   Namespace   |    Value      |    0 (pad)    |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

             Figure 1: Classifier Using the One-Byte Header

 

      0                   1                   2                   3

      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     |      ID       |    len=2      |   Namespace   |    Value      |

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

 

             Figure 2: Classifier Using the Two-Byte Header

 

indicated using a dynamically assigned identifier that is conveyed in an out-of-band

--- It is the TURN flow!!! Requested by the ICE protocol for the specific media to come!

and encrypted signalling channel,

--- Only the payload is encrypted in SRTP – leaving id, seq no and header ext to be used as intended!

--- Thus being the appropriate place…

is not an appropriate place to put QoS information that has to be processed on a per-packet basis.

If you want DiffServ, you know where to find it.

--- True, but if it cannot be used…

Colin

 

 

On 24 Feb 2014, at 22:09, Karl Stahl <karl.stahl@intertex.se> wrote:

I suggest to the RTCWEB WG that the below from the September and October discussions on the relevant [rtcweb] [avtext] [mmusic] lists http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html is introduced into draft-ietf-rtcweb-rtp-usage for usage of RFC 5285, to allow:

 

(1) WebRTC applications to directly convey QoS related real-time traffic info to the network at points where RTP flow is directed to by TRAM Milstone 3, to be used by *any network element implementing any suitable QoS methods for the particular network* for

(2) *all* WebRTC browsers *and* clients, under *all* OSs, and *all* current and future IP network, to achieve best QoE

(3) *without* having to force WebRTC into application specific networks (such as IMS) instead of using the Internet (including OTT).

 

The only further activity required, is to call for ISPs’ to review whether the traffic information transferred by RFC 5285 is sufficient for current and future needs in their network as suggested in below repeated http://www.ietf.org/mail-archive/web/rtcweb/current/msg09129.html

<snip>

…two parameters (e.g. two bytes each) are encoded into the RTP header extension:

 

A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence… on a logarithmic scale.

 

B) The quality characteristics for the stream, with the highest bit set to 1, we could allocate a bit each for quality type e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to describe the stream.

 

And with highest bit set to 0, there could instead be a number for special usage that does not fit the general description of the individual bits.

</snip>

 

Then this could be assigned numbers to have an RFC in place.

 

With TRAM milestone 3 also place,

market forces will drive ISPs and browser makers to implement just this, without even having it MUST-established.

 

“Who does not want a “WebRTC-Ready” Internet access?” and

“Who wants to use Chrome, if Firefox, Internet Explorer or Safari comes with much better QoE?” and vice versa.

 

Please see further emails soon following this one, for details and history.

 

/Karl

 

 

Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Karl Stahl
Skickat: den 22 oktober 2013 16:37
Till: 'Harald Alvestrand'; rtcweb@ietf.org; 'Magnus Westerlund'
Kopia: 'Colin Perkins'
Ämne: [rtcweb] [avtext] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

 

Harald, I mostly agree with the quality requirements of different real-time traffic that the WebRTC browser/application may use. But rather than asking the application, let's convey the bandwidth and priority requirements to the network. Just like with the Payload type (that is hard to squeeze that information into) it must be visible to the network (and not changed by the network, like diffserv bits are). Such marking must also be available for incoming traffic, which is especially important in RSVP type of networks, that has to reserve bandwidth for it.  

 

There is actually a good way to show these needs to the network (without using the PT, or diffserv bits, which aren’t sufficient anyway).

 

Let's use the RTP header extension field that also is visible outside the encrypted payload. A week ago came http://tools.ietf.org/html/draft-carlberg-avtext-classifier-00  that outlines the usage of the extension field for classification of traffic! This document does not yet outline what to put in there and how to encode it though.

 

Today's http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-10 discusses other webrtc usages of the RTP header extension in 5.2 (there can be many header extensions according to RFC 5285) and in 9 there is "WebRTC Use of RTP: Future Extensions".

 

So, it looks obvious to use the RTP header extension to show the characteristics and bandwidth requirements to the network. It should not introduce any backward incompatibilities either.

 

Such marking is done in every RTP packet so it can be set individually for each stream and could even be changed during a session (e.g. when limiting the bandwidth based on RTCP feedback). RFC 5286 also specifies how RTP extension header usage can be negotiated in SDP. I think this could be easily done by the WebRTC browser for "all current and future needs" if properly specified now.

 

I suggest that two parameters (e.g. two bytes each) are encoded into the RTP header extension:

 

A) The maximum bandwidth requirement: Two bytes could contain everything from some bps for real-time text to Gbps for future 3D supersize telepresence… on a logarithmic scale.

 

B) The quality characteristics for the stream, with the highest bit set to 1, we could allocate a bit each quality e.g:

Best Effort, Audio, Video, Supplemental Video, Gaming, Data, Delay Insensitive (e.g. video streaming), Minimum Delay, Reliable Delivery, Prioritize X, Variation Y, that could be combined as required to describe the stream.

 

And with highest bit set to 0, there could instead be a number for special usage that does not fit the general description of the individual bits.

 

Please note the totally different requirements a diffserv and an RSVP network have to know, so let’s put all into these bytes. (E.g. a diffserv network don't need the bandwidth usage, but RSVP reservation networks (e.g. cable and 3G/4G OTT) do. There one should initially reserve the maximum bandwidth indicated, but can later re-reserve.)

 

/Karl

 

PS Microsoft seems to have done work in this field, defining a proprietary attribute “MS Service Quality”;

However that seems to apply to the TURN server allocation request and would therefore:

--- Apply to the whole UDP flow, and could not be set for each stream individually (with different requirements), and

--- Does not handle the bandwidth requirement for incoming real-time traffic (required to reserve in RSVP type of networks)

However the quality attributes conveyed and their encoding may  be considered.

 

This is 2.2.2.19 MS-Service Quality Attribute from

http://msdn.microsoft.com/en-us/library/cc431507(v=office.12).aspx 

 

MS-Service Quality Attribute

The MS-Service Quality attribute is used to convey information about the data stream that the protocol client is intending to transfer over an allocated port. The protocol client SHOULD<21> include this attribute as part of an Allocate request message. A TURN server SHOULD use the information in this attribute to make decisions about resource allocation, bandwidth prioritization, and data delivery methods. If the attribute is not present in the Allocate request message, the TURN server SHOULD assume that the data stream is audio with best effort delivery. The format of this attribute is as follows...

...

The following stream types are supported in this extension. All other stream types are reserved for future use.

§ "0x0001": Audio

§ "0x0002": Video

§ "0x0003": Supplemental Video

§ "0x0004": Data

Service Quality (2 bytes): The service quality level required by the protocol client for the stream.

The following service quality levels are supported in this extension. All other service quality levels are reserved for future use.

§ "0x0000": Best effort delivery.

§ "0x0001": Reliable delivery.

 

 

-----Ursprungligt meddelande-----

Från: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] För Harald Alvestrand

Skickat: den 8 oktober 2013 13:01

Till: rtcweb@ietf.org

Ämne: Re: [rtcweb] Payload Types assignments was Re: SV: [mmusic] WGLC of draft-ietf-rtcweb-use-cases-and-requirements-11

 

On 10/08/2013 09:17 AM, Karl Stahl wrote:

> Hej Magnus,

> 

>> Also, are you really interested in knowing that it is VP9 vs H.264,

>> isn't

> the questions this is video of this priority that is important?

>> I think you need to more carefully consider what are the goals you

>> try to

> achieve them.

> 

> Actually, my concern is to get an idea of the maximum bandwidth that

> could be required for a WebRTC (ICE) setup media flow. Both voice and

> video should be prioritized over data (their individual priority is of

> less importance as long as there is sufficient bandwidth for both).

 

You don't know that without knowing what the application is for.

In, for instance, a shooter game with voice backchannels, the movement and event information (data) is MORE time sensitive than the voice data.

 

> 

> With diffserv you don’t need to know the bandwidth requirement, but

> with RSVP reservation (like in cable and mobile networks) you need to

> know how much to reserve. Voice is like 100's kbit/s, video VP8 or

> H.264 is like 3,5 mbps.

 

Again, without knowing the application, you don't know that.

The application could decide to use QCIF or HD, and the bandwidth variation of screencast (semi-static with sudden, large changes) is completely different from that of a talking head, which is again completely different from a high-movement scene.

 

> 

> To add to the complication of codec variants, the video codecs in

> question for WebRTC have variable bandwidth, and when there is a poor

> connection we see Chrome reducing the video window size to reduce the bandwidth used...

> 

> I think the payload type field at best can reflect a maximum bandwidth

> to initially reserve bandwidth for, and thereafter make new

> reservations if the bandwidth changes during the call. So could we

> change RTP to show maximum bandwidth instead of payload type in that

> field outside the encrypted payload :) ... Or maybe that is not a joke?

 

I think these ruminations only lead to one conclusion:

 

You can't tell what the needed bandwidth is up front without asking the application.

You can't tell what the right priority ranking is without asking the application.

 

If you need to know the bandwidth or the priority up front, the application has to tell you. Anything else is pure heuristics.

 

_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb

 

 

-- 

Colin Perkins

 

 

 




-- 
Colin Perkins





-- 
Surveillance is pervasive. Go Dark.
--------------040103040302090507080803-- From nobody Wed Feb 26 05:04:13 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FCE1A008E; Wed, 26 Feb 2014 00:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 gxcBHsSR8hik; Wed, 26 Feb 2014 00:05:42 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 92CFA1A0092; Wed, 26 Feb 2014 00:05:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1290; q=dns/txt; s=iport; t=1393401939; x=1394611539; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Lfr0m5MtyKVpXpY0pLAOIHsWRsnUcdjSKX/sL6ChiiI=; b=TOnDc5CkQwfuyNnA0FgeKXbaI9BghPxzHjPM2sGhTwWPeA70TT5CX1Zn tKlbFChRN+8CUqjjE5eQrsgvWTLrDQNg99+JPmug7dLgGRkuZzL2J8Uri Y3RPBwa9gEcV5Y41NL25ICqQIobhoVGuVR4EWqAv1Ba0ETw/tJD7mY9Ve s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAC2gDVOtJV2a/2dsb2JhbABYgwaBEsEFgRoWdIIlAQEBAwF5EAIBCDsLMiUCBA4Fh30IyGwXjXglMweDJIEUAQOYNpIogW+BPoFoQg X-IronPort-AV: E=Sophos;i="4.97,546,1389744000"; d="scan'208";a="23261635" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 26 Feb 2014 08:05:31 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q85VV8017950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 08:05:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 02:05:30 -0600 From: "Cullen Jennings (fluffy)" To: Barry Leiba Thread-Topic: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs Thread-Index: AQHPMbSdf/e29IVb6Eq4DfCgCp5RAprHHxqAgAABqQCAAHOcgA== Date: Wed, 26 Feb 2014 08:05:30 +0000 Message-ID: <055BC233-8C90-4A07-9AFC-FB178586AA0B@cisco.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.234] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5C592798698FF940BAABC2723F2E1FA5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/ODtv_iEcYfCG8eivR44-ULavNJ8 X-Mailman-Approved-At: Wed, 26 Feb 2014 05:03:42 -0800 Cc: Simon Perreault , Ted Hardie , "tram@ietf.org" , Magnus Westerlund , Gonzalo Camarillo , Spencer Dawkins , "rtcweb@ietf.org" , IESG IESG , Karl Stahl Subject: Re: [tram] [RTCWEB] [TRAM] Protesting: Requesting TRAM Charter Clarification regardig Milestone 3: TURN server auto-discovery mechanism for enterprise and ISPs X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 08:05:48 -0000 On Feb 26, 2014, at 9:12 AM, Barry Leiba wrote: >> That said, I think you have pointed out this charter is abysmally >> vague - it does not say what the WG is not going to do. If I >> decided to do BGP for routing updates over TURN it would be >> within the scope of this charter. >=20 > Cullen, is it your opinion that a working group is always free to do > anything that's not explicitly forbidden in its charter? >=20 > I think that a working group is limited to doing what *is* in its > charter, and we sometimes explicitly forbid things for emphasis. >=20 > The TRAM charter says this: >=20 > The work will include the addition of DTLS > as an additional transport, authentication mechanisms, and > extensions to TURN and STUN. >=20 > I don't think that would support, for example, BGP over TURN. >=20 > Barry BGP over TURN sounds like a turn extension to me. Now you might think that = is a silly one and I would agree but I assure you Karl does not think the Q= oS extensions are silly extensions to TURN.=20 So in your opinion are they in scope or out, I think that is the heart of t= he issue right now. I=92m of the opinion they are in scope so I look forwar= d to agenda time be allocated for them.=20 Cullen From nobody Wed Feb 26 05:04:14 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0383E1A00A7; Wed, 26 Feb 2014 00:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.048 X-Spam-Level: X-Spam-Status: No, score=-110.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 XApoWPBuFByj; Wed, 26 Feb 2014 00:26:19 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 3590E1A00BF; Wed, 26 Feb 2014 00:26:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1122; q=dns/txt; s=iport; t=1393403175; x=1394612775; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xZRM/jW19U+oUVmhHSS+Qhf4EjaTjljk44Pg/k4dSRM=; b=BP5/ZrUrk8D2Mh73bYg0+GyGfMIfIC2WKZjHpT1idcQF6ipsJkI1BkoY HwRasBGfSAexCY2tnb+Y1dYZWFvKtspJgFTrBb35iT+jACAfohmTrZBJ6 E34x9rcMpRnauGANyxbwcVj6IZgJnnuamFopxLLOVz/HgrR+IM1U/lj7l w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAM+kDVOtJV2d/2dsb2JhbABYgwaBEsBzgRoWdIIlAQEBAwF5BQsCAQg7CyERJQIEDgWHcQMJCMEiDYdAF4w8gWEzB4MkgRQBA4kRjTiBbYxhhUeBb4E+gio X-IronPort-AV: E=Sophos;i="4.97,546,1389744000"; d="scan'208";a="23275197" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 26 Feb 2014 08:26:14 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1Q8QEC3013649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 08:26:14 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 02:26:14 -0600 From: "Cullen Jennings (fluffy)" To: Spencer Dawkins Thread-Topic: BCP over TURN will not be in scope ... and MPLS over UDP over TURN will not be in scope ... and ... Thread-Index: AQHPMp3TlavW55iFXk6oBDPcpW1UwZrHmFiA Date: Wed, 26 Feb 2014 08:26:13 +0000 Message-ID: <55FF8505-78C7-483B-B923-368ED01CE37A@cisco.com> References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <530D56F7.5070900@gmail.com> In-Reply-To: <530D56F7.5070900@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.205] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/J1GJ5Uj2Hh4VF8FQ5rkYvb1qLEg X-Mailman-Approved-At: Wed, 26 Feb 2014 05:03:42 -0800 Cc: Simon Perreault , Ted Hardie , "tram@ietf.org" , Magnus Westerlund , Gonzalo Camarillo , Spencer Dawkins , "rtcweb@ietf.org" , IESG IESG , Karl Stahl , Barry Leiba Subject: Re: [tram] BCP over TURN will not be in scope ... and MPLS over UDP over TURN will not be in scope ... and ... X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 08:26:22 -0000 On Feb 26, 2014, at 10:52 AM, Spencer Dawkins wrote: > So ... TRAM was chartered last Thursday ... >=20 > I'm gonna let Gonzalo (Yet Another Soon-to-be Former AD Serving as WG Cha= ir) and Simon actually chair their working group for at least a full week b= efore intruding further, but for now, let's assume that the working group w= ants to work on the milestones they signed up for last week, and see how ba= dly that assumption blows up, rather than talk about rechartering every tim= e someone proposes a topic that's out of scope. >=20 > I look forward to attending the first working group session next week, an= d to balloting on six TRAM drafts before IETF 92. >=20 > Thanks, >=20 > Spencer, as the responsible AD Makes sense - I get the desire to let some work get done.=20 I worry that every time someone says something is is not in scope of this W= G, it is not going to feel like an open consensus decisions but is instead = going to feel like a arbitrary fiat decisions by a chair or IESG made in a = dark and smoky room - I hope I am wrong.=20 From nobody Wed Feb 26 05:11:13 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC0CD1A02B6 for ; Wed, 26 Feb 2014 05:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 rAoyn9n6Du38 for ; Wed, 26 Feb 2014 05:11:03 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8B65E1A02FE for ; Wed, 26 Feb 2014 05:11:03 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1197146907; Wed, 26 Feb 2014 08:11:02 -0500 (EST) Message-ID: <530DE7E5.4030807@viagenie.ca> Date: Wed, 26 Feb 2014 08:11:01 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Spencer Dawkins , Barry Leiba , "Cullen Jennings (fluffy)" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <530D56F7.5070900@gmail.com> In-Reply-To: <530D56F7.5070900@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/Cptls8u069KxQbbzql-xtuW7Pv0 Cc: "tram@ietf.org" , Gonzalo Camarillo Subject: Re: [tram] BCP over TURN will not be in scope ... and MPLS over UDP over TURN will not be in scope ... and ... X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 13:11:06 -0000 Thanks, Spencer. Please everyone also keep in mind that there's a big difference between what is allowed to be discussed on the mailing list, where a very liberal view of what is "on topic" usually applies, and what actually gets agenda time, milestones, and adopted drafts, which is handled much more strictly. Simon Le 2014-02-25 21:52, Spencer Dawkins a écrit : > So ... TRAM was chartered last Thursday ... > > I'm gonna let Gonzalo (Yet Another Soon-to-be Former AD Serving as WG > Chair) and Simon actually chair their working group for at least a full > week before intruding further, but for now, let's assume that the > working group wants to work on the milestones they signed up for last > week, and see how badly that assumption blows up, rather than talk about > rechartering every time someone proposes a topic that's out of scope. > > I look forward to attending the first working group session next week, > and to balloting on six TRAM drafts before IETF 92. > > Thanks, > > Spencer, as the responsible AD -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Wed Feb 26 05:34:42 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05681A032E; Wed, 26 Feb 2014 05:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001] autolearn=ham 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 t7ReDfjSGkhG; Wed, 26 Feb 2014 05:34:27 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 39C9D1A02F5; Wed, 26 Feb 2014 05:34:27 -0800 (PST) Received: by mail-yk0-f174.google.com with SMTP id 20so2483889yks.5 for ; Wed, 26 Feb 2014 05:34:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ylsHWTJ9P44z5H1YfXuRCSvUk6qcBhAYAVvyFwsWzqg=; b=iJqh7Fg0ASNGJWRkFz1YTWitex+5mk2pntF38ez+ppF6KCJdwM2e4RcoQQPF9DEzsI xJ98ZMGAGfojfkwaVVmkc9gIxm9iiF/vK5dVtQs4njNF4gEov/ngp+ZOSGXWuHz2z+ig brbVq6AAMu96WIrh30rnmjthkaSF14Waq3IqTSW3PfPpJh1TThnXMevtxOwHaZ95peZC x+Y2njIXroZpVKhhBHuNVnGOPK/ZS9xnunjFpX4/YhNLFh2NG++Ru2EgysIljfm+TZ1s +UMm/nxNpBEgJbN1SrXYff+UHxet5leBLcETC7lSisQ0GgHEt/DXCrxGHvW3Bvqe4Mvs CVLQ== MIME-Version: 1.0 X-Received: by 10.236.175.161 with SMTP id z21mr7596580yhl.80.1393421665857; Wed, 26 Feb 2014 05:34:25 -0800 (PST) Received: by 10.170.96.215 with HTTP; Wed, 26 Feb 2014 05:34:25 -0800 (PST) Date: Wed, 26 Feb 2014 07:34:25 -0600 Message-ID: From: Spencer Dawkins at IETF To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=20cf303f672e6a778604f34f4302 Archived-At: http://mailarchive.ietf.org/arch/msg/tram/8BPARA8FIPKQ4sD3v6TA9YmRf54 Cc: Karl Stahl , "rtcweb@ietf.org" , "tram@ietf.org" , "tsv-ads@ietf.org" Subject: [tram] Last note about QoS from the responsible AD before the rant ... X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 13:34:37 -0000 --20cf303f672e6a778604f34f4302 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Using smaller words (since we're all very busy): QoS is out of scope for TRAM. It is in scope for TSVWG. It will not be necessary helpful to continue to talk about QoS in TRAM. Thanks for taking the conversation to a mailing list where it's in scope. Spencer, as responsible AD On Tuesday, February 25, 2014, Cullen Jennings (fluffy) wrote: > > Karl, > > I am totally lost on this thread. Could you start a new tmead that > summarize what the issues is, what seems to be the point of debate, and > what your view is on what we should do. I think that would help make > progress. > > Thank you, > > Cullen > > > On Feb 25, 2014, at 8:20 AM, Karl Stahl > > wrote: > > > Hi Alan, > > > > I have in previous email > http://www.ietf.org/mail-archive/web/tram/current/msg00304.html suggested > that both DISCUSS and draft-thomson-tram-turn-bandwidth-00.txt is taken o= ff > the TRAM WG, but I think is shall be reintroduced after you clarify as yo= u > do in > > http://www.ietf.org/mail-archive/web/tram/current/msg00300.html : > > Hi Karl, Thanks for your comments and feedback on the draft. > > You are correct in saying that the BANDWIDTH extension is not about QoS= . > It is about fairness between users of a TURN server, and a TURN server > being able to indicate rate limiting policy to users. in the draft. > > > > The "confusion" (to say least, see below) surrounding QoS within IETF > has lead me to protest and address the TRAM WG and RTCWEB WG and ADs with > the advise in > http://www.ietf.org/mail-archive/web/tram/current/msg00304.html : > > "The TRAM WG and RTCWEB WG chairs and ADs are advised to review whether > IETF standard work in these WGs by contributors having an interest in mor= e > than one of current or emerging: ISPs, carrier equipment vendors or web > browser makers, may discriminate any with an interest only in one of thes= e. > The same should apply to non-activity by WG contributors to remedy such > discrimination opened by allowed proprietary usage of RFCs such as RFC > 5285." > > > > This is because the introduction of the QoS related usage of RFC 5285 > into draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 > objectives of TRAM, immediately would allow for: > > (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in > addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP variants) > to quickly allow us to finally enjoy the high quality and connectivity > (NAT/firewall traversal) of real-time communication services now possible= , > for > > (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), > under *all* OSs, and *all* current and future IP networks > > (3) *without* having to be forced into application specific networks > (PSTN, IMS) instead of the Internet (including OTT). > > > > While the "confusion" surrounding the QoS discussion in TRAM and RTCWEB > combined with thegeneral QoS attitude within IETF "it is all about > bandwidth" and "it will go away with time" otherwise: > > (i) will *not allow* ISP's to use already available and currently > deployable quality IP pipes for real-time traffic to also be used for > WebRTC generated real-time traffic. > > (ii) will *not allow* some network types (e.g. Cable Networks and Mobil= e > OTT) to borrow bandwidth from data traffic and QoS insensitive streaming > video and file sharing. That all networks *will be inhibited* from the ve= ry > common and used method of simply providing an extra IP pipe (often provid= ed > over the same wire but level-2 separated) dedicated for real-time usage > > (*by resisting TRAM implementation of step B*) > > *while* newer, fiber only type of networks, still can borrow bandwidth > at no extra cost, *by proprietary usage* of RFC 5285 by browsers. > > (iii) will leave most ISPs to *only use* raw bandwidth capacity increas= e > that may have to be 10-folded to reach sufficient QoE when WebRTC usage > becomes popular (if at all possible, since unmanaged IP pipes > intermittently are filled, whatever bandwidth is available). > > > > As Good doers, we should not allow this to happen. > > > > /Karl > > > > > > Fr=E5n: Alan Johnston [mailto:alan.b.johnston@gmail.com ] > > Skickat: den 21 februari 2014 18:59 > > Till: Pal Martinsen (palmarti) > > Kopia: tram@ietf.org ; Oleg Moskalenko; Karl Stahl; > Yoakum, John H (John) > > =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.txt > > > > I guess the way I would expect this to progress is for QoS discussions > to happen in another working group. Once that other working group came t= o > consensus on an approach, and if that approach required STUN or TURN > extensions, then we would discuss mechanisms and possible milestones in > TRAM. > > > > - Alan - > > > > > > On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) < > palmarti@cisco.com > wrote: > > Hi, > > > > I agree the full QoS discussion should _not_ happen in TRAM. If you are > interested in helping out in that area I suggest you looking into the AEO= N > mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are > currently working on a problem-statement draft and a use-case draft, any > input to those would be very helpful. ( > http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01, > http://tools.ietf.org/html/draft-eckel-aeon-problem-statement-00). > > > > That said, STUN have a few nice characteristics that makes it a perfect > candidate for transporting some of the QoS information. IMHO that would = be > extending the STUN spec and should be within the TRAM charter. The main > goal of draft-martinsen-tram-discuss was to show how already existing QoS > mechanisms could be transported with STUN to provide more value, and to > start the discussion if TRAM is the appropriate place to have those on th= e > wire format discussions. > > > > .-. > > P=E5l-Erik > > > > > > On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) > > wrote: > > > > > > +1 > > I fully agree with the comments that QOS should be a low priority for > the initial focus of the TRAM efforts. There are other groups doing QOS > work and frankly I engage in WebRTC multimedia interactions daily over th= e > Internet, enterprise VPNs, and various combinations and seldom suffer > egregious quality issues. I am more concerned about carriers doing thing= s > to regulate or degrade WebRTC flows than a failure of existing Internet > mechanisms to enable them. > > > > Significant focus on QOS before we better enable TURN to be easily used > in a browser environment taking advantage or normal web characteristics (= as > opposed to historic telephony constructs) would seem to be highly > distracting at this point. > > > > > > Cheers, > > John > > > > AVAYA > > 1.919.425.8446 > > > > From: tram [mailto:tram-bounces@ietf.org ] On Behalf Of > Oleg Moskalenko > > Sent: Thursday, February 20, 2014 12:43 PM > > To: Alan Johnston > > Cc: Karl Stahl; tram@ietf.org > > Subject: Re: [tram] Fwd: I-D Action: > draft-thomson-tram-turn-bandwidth-00.txt > > > > > > > > > > On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston < > alan.b.johnston@gmail.com > wrote: > > > > > > > > Personally, I am not sure how much QoS is actually in scope for TRAM. > Have you been following RMCAT where congestion avoidance for RTP is being > developed? I see some overlap in your goals and the goals of that work. > > - > > > > > > I'd concentrate on the TURN application-level functionality, for now, > and I'd leave QoS for the future discussions. > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org > > https://www.ietf.org/mailman/listinfo/rtcweb > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --20cf303f672e6a778604f34f4302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Using smaller words (since we're all very busy): 

QoS is out of scope for TRAM.

It is in scope fo= r TSVWG.

It will not be necessary helpful to = continue to talk about QoS in TRAM.

Thanks for taking the conversation to a mailing list wh= ere it's in scope.

Spencer, as responsible AD<= /div>

On Tuesday, February 25, 2014, Cullen Jennings (fluffy) <<= a href=3D"mailto:fluffy@cisco.com">fluffy@cisco.com> wrote:

Karl,

I am totally lost on this thread. Could you start a new tmead that summariz= e what the issues is, what seems to be the point of debate, and what your v= iew is on what we should do. I think that would help make progress.

Thank you,

Cullen


On Feb 25, 2014, at 8:20 AM, Karl Stahl <karl.stah= l@intertex.se> wrote:

> Hi Alan,
>
> I have in previous email http://www.ietf.org/mail-a= rchive/web/tram/current/msg00304.html suggested that both DISCUSS and d= raft-thomson-tram-turn-bandwidth-00.txt is taken off the TRAM WG, but I thi= nk is shall be reintroduced after you clarify as you do in
> http://www.ietf.org/mail-archive/web/tram/current/m= sg00300.html :
> Hi Karl, Thanks for your comments and feedback on the draft.
> You are correct in saying that the BANDWIDTH extension is not about Qo= S.  It is about fairness between users of a TURN server, and a TURN se= rver being able to indicate rate limiting policy to users. in the draft. >
> The “confusion” (to say least, see below) surrounding QoS = within IETF has lead me to protest and address the TRAM WG and RTCWEB WG an= d ADs with the advise in http://www.ietf.org/mail-archiv= e/web/tram/current/msg00304.html :
> “The TRAM WG and RTCWEB WG chairs and ADs are advised to review = whether IETF standard work in these WGs by contributors having an interest = in more than one of current or emerging: ISPs, carrier equipment vendors or= web browser makers, may discriminate any with an interest only in one of t= hese. The same should apply to non-activity by WG contributors to remedy su= ch discrimination opened by allowed proprietary usage of RFCs such as RFC 5= 285.”
>
> This is because the introduction of the QoS related usage of RFC 5285 = into draft-ietf-rtcweb-rtp-usage in combinations with the Milestone 3 objec= tives of TRAM, immediately would allow for:
> (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in a= ddition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP variants) to= quickly allow us to finally enjoy the high quality and connectivity (NAT/f= irewall traversal) of real-time communication services now possible, for > (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks
> (3) *without* having to be forced into application specific networks (= PSTN, IMS) instead of the Internet (including OTT).
>
> While the “confusion” surrounding the QoS discussion in TR= AM and RTCWEB combined with thegeneral QoS attitude within IETF “it i= s all about bandwidth” and “it will go away with time” ot= herwise:
> (i) will *not allow* ISP’s to use already available and currentl= y deployable quality IP pipes for real-time traffic to also be used for Web= RTC generated real-time traffic.
> (ii) will *not allow* some network types (e.g. Cable Networks and Mobi= le OTT) to borrow bandwidth from data traffic and QoS insensitive streaming= video and file sharing. That all networks *will be inhibited* from the ver= y common and used method of simply providing an extra IP pipe (often provid= ed over the same wire but level-2 separated) dedicated for real-time usage<= br> > (*by resisting TRAM implementation of step B*)
> *while* newer, fiber only type of networks, still can borrow bandwidth= at no extra cost, *by proprietary usage* of RFC 5285 by browsers.
> (iii) will leave most ISPs to *only use* raw bandwidth capacity increa= se that may have to be 10-folded to reach sufficient QoE when WebRTC usage = becomes popular (if at all possible, since unmanaged IP pipes intermittentl= y are filled, whatever bandwidth is available).
>
> As Good doers, we should not allow this to happen.
>
> /Karl
>
>
> Fr=E5n: Alan Johnston [mailto:alan.b.johnston= @gmail.com]
> Skickat: den 21 februari 2014 18:59
> Till: Pal Martinsen (palmarti)
> Kopia: tram@ietf.org; Oleg Moskalenko; Karl Stahl; Yo= akum, John H (John)
> =C4mne: Re: [tram] I-D Action: draft-thomson-tram-turn-bandwidth-00.tx= t
>
> I guess the way I would expect this to progress is for QoS discussions= to happen in another working group.  Once that other working group ca= me to consensus on an approach, and if that approach required STUN or TURN = extensions, then we would discuss mechanisms and possible milestones in TRA= M.
>
> - Alan -
>
>
> On Fri, Feb 21, 2014 at 3:37 AM, Pal Martinsen (palmarti) <palmarti@cisco.com> wrote:
> Hi,
>
> I agree the full QoS discussion should _not_ happen in TRAM. If you ar= e interested in helping out in that area I suggest you looking into the AEO= N mailing list at: https://www.ietf.org/mailman/listinfo/aeon . They are = currently working on a problem-statement draft and a use-case draft, any in= put to those would be very helpful. (http://tools.ietf.org/html= /draft-eckel-aeon-use-cases-01, http://tools.ietf.o= rg/html/draft-eckel-aeon-problem-statement-00).
>
> That said, STUN have a few nice characteristics that makes it a perfec= t candidate for transporting some of the QoS information.  IMHO that w= ould be extending the STUN spec and should be within the TRAM charter. &nbs= p;The main goal of draft-martinsen-tram-discuss was to show how already exi= sting QoS mechanisms could be transported with STUN to provide more value, = and to start the discussion if TRAM is the appropriate place to have those = on the wire format discussions.
>
> .-.
> P=E5l-Erik
>
>
> On 20 Feb 2014, at 19:55 pm, Yoakum, John H (John) <yoakum@avaya.com> wrote:
>
>
> +1
> I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts.  There are other groups doing Q= OS work and frankly I engage in WebRTC multimedia interactions daily over t= he Internet, enterprise VPNs, and various combinations and seldom suffer eg= regious quality issues.  I am more concerned about carriers doing thin= gs to regulate or degrade WebRTC flows than a failure of existing Internet = mechanisms to enable them.
>
> Significant focus on QOS before we better enable TURN to be easily use= d in a browser environment taking advantage or normal web characteristics (= as opposed to historic telephony constructs) would seem to be highly distra= cting at this point.
>
>
> Cheers,
> John
>
> AVAYA
> 1.919.425.8446
>
> From: tram [mailto:tram-bounces@ietf.org] On = Behalf Of Oleg Moskalenko
> Sent: Thursday, February 20, 2014 12:43 PM
> To: Alan Johnston
> Cc: Karl Stahl; tram@ietf.org
> Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth= -00.txt
>
>
>
>
> On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <alan.b.johnston@gmail.com> wrote:
>
>
>
> Personally, I am not sure how much QoS is actually in scope for TRAM. = Have you been following RMCAT where congestion avoidance for RTP is being d= eveloped?  I see some overlap in your goals and the goals of that work= .
> -
>
>
> I'd concentrate on the TURN application-level functionality, for n= ow, and I'd leave QoS for the future discussions.
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb
--20cf303f672e6a778604f34f4302-- From nobody Wed Feb 26 05:46:25 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8511A02F5; Wed, 26 Feb 2014 05:46:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.24 X-Spam-Level: X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 wjrEEyzk9nn7; Wed, 26 Feb 2014 05:46:19 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id F065D1A0348; Wed, 26 Feb 2014 05:46:14 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-da-530df0258e29 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 51.E1.04853.520FD035; Wed, 26 Feb 2014 14:46:13 +0100 (CET) Received: from [131.160.126.202] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.2.347.0; Wed, 26 Feb 2014 14:46:12 +0100 Message-ID: <530DF024.8030502@ericsson.com> Date: Wed, 26 Feb 2014 15:46:12 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mary Barnes , James Polk References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <5303A4DE.8090500@viagenie.ca> <5303D18C.5030705@viagenie.ca> <530CD45E.5010306@gmail.com> <201402252044.s1PKiYNH011099@mtv-core-2.cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUyM+Jvja7qB95gg8Y2YYsdawotPu/fz2wx 58RLFos5ux4wWSybsofZ4sPaC2wWU1r2slo09N1ldeDwmPJ7I6vHzll32T2WLPnJ5PHl8me2 AJYoLpuU1JzMstQifbsEroyulztZCg6rVTRfX8nWwPhEuouRk0NCwETi3rF+RghbTOLCvfVs XYxcHEICJxglZry7zALhrGWU+LBhCZDDwcEroC3R3cAM0sAioCox9dYOdhCbTcBCYsut+ywg tqhAlMTPKwvA4rwCghInZz4BaxUR8Ja4f14bZCSzwFdGicfTtoPVCAvYSvR9PMsEsWsJi8TX hr1gCzgFAiWmL/gK1iwhIC7R0xgEEmYW0JOYcrWFEcKWl2jeOhusXAjotOXPWlgmMArNQrJ6 FpKWWUhaFjAyr2KULE4tLs5NNzLQy03PLdFLLcpMLi7Oz9MrTt3ECIyOg1t+G+1gPLnH/hCj NAeLkjjvddaaICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MW67eUbzPei3KduralweSZ6x+ WHTk4zk5D9X09beWNlqsYf+jtXTBFc78H49WNi180Ps/wa60MvbAd7ZfnFGX4raf/DlNXFv3 R/3rHr/KWY4rpA8mVJucLHl/7DkHi+/nI4+2CkUxuDvu9FrkUveW32VpVk73yz+iLoWGj/nr V5VO/rlupnfafiWW4oxEQy3mouJEAPUFQwVcAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/tram/IQwzXrGmCHmQpD1f_GJxfYGCwaI Cc: "rtcweb-chairs@tools.ietf.org" , rai-ads@ietf.org, tram@ietf.org, "tsvwg-chairs@ietf.org" , "tsv-ads@ietf.org" , Spencer Dawkins Subject: Re: [tram] A note from your (so far) friendly AD ... X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 13:46:21 -0000 Hi, Mary is right. People should avoid cross-posting to several mailing lists because it increases the chances of people missing messages because of their email filters. Cheers, Gonzalo On 25/02/2014 11:28 PM, Mary Barnes wrote: > James, > > Correct. This current email thread was not cross posted but it was > posted to the TRAM mailing list and not just some WG chairs as you > noted. My point was that one of the threads of discussion which > triggered this email involved cross posting. For some of us that are > subscribed to all the lists involved, it gets crazy trying to follow > these threads. > > Mary. > > > On Tue, Feb 25, 2014 at 2:44 PM, James Polk > wrote: > > But that didn't happen here. Only Certain ADs and certain WG chairs > were cc'd. You surely don't have a problem with that...? > > James > > > At 11:59 AM 2/25/2014, Mary Barnes wrote: > > It would also be extremely helpful in cases where it's not > entirely clear whether the discussion belongs in TRAM, RTCWEB, > etc. to please avoid cross-posting. Please check with the > chairs about what list they think is most appropriate and then > just send a note to other lists that might care that the > discussion is happening on a specific mailing list. It's > extremely confusing for those of us on multiple lists that try > to sort and follow threads by working groups. > > > On Tue, Feb 25, 2014 at 11:35 AM, Spencer Dawkins > < >spencerdawkins.ietf@__gmail.com > > wrote: > Dear TRAMsters, > > If I might offer a couple of suggestions to a new working group ... > > The TSV area diverts QoS discussions to the TSVWG working group, > because that's where the QoS DSCP expertise lives. > > RTCWeb and TSVWG are having a robust and so-far productive > discussion about QoS for RTCWeb now (by "robust", I mean > "involving chairs and ADs for both working groups"). That > discussion is more likely to be productive if RTCWeb QoS topics > don't start popping up on other working group mailing lists, > like this one. > > I'll let your working group chairs actually run the working > group, but I note as more than an interested observer that the > TRAM agenda at > >https:__//datatracker.ietf.org/__meeting/89/agenda/tram/ > is really > tight, and I would really be happier if the working group > focuses on the currently chartered milestones and demonstrates > that you can deliver what you're already signed up to deliver, > before adding more milestones. The rest of the IESG would be > happier as well. > > > Thanks, and see you in London. > > Spencer, as your responsible AD > > On 02/18/2014 03:33 PM, Simon Perreault wrote: > Le 2014-02-18 16:12, Oleg Moskalenko a écrit : > How to handle the DS and ECN fields is a part of TURN server RFC > (see > the section 12): > > >http://__tools.ietf.org/search/rfc5766#__section-12 > > > > And a good TURN server is supposed to implement that. > > Well, the RFC just says that the TURN server should copy the > DSCP from > one side to the other when doing en/de-capsulation. It doesn't > say that > the server should actually do QoS based on the DSCP. My point is > that > there's nothing preventing the server from actually doing it. > > Anyway, I was expecting responses along the lines of "DiffServ > doesn't > work on the Internet in general." To which I would have replied: > "then > couldn't we define a STUN attribute for transporting the DSCP in the > payload?" Instead of inventing a new taxonomy (audio, video, slides, > etc.), why not reuse DSCP? > > Simon > > > _________________________________________________ > tram mailing list > >tram@__ietf.org > > https://www.ietf.org/mailman/__listinfo/tram > > > > From nobody Wed Feb 26 05:54:55 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E740F1A0363; Wed, 26 Feb 2014 05:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.851 X-Spam-Level: X-Spam-Status: No, score=-103.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 cny210KQ_aNY; Wed, 26 Feb 2014 05:53:14 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 348EF1A035E; Wed, 26 Feb 2014 05:53:13 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-37-530df1c6ab57 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 71.69.10875.6C1FD035; Wed, 26 Feb 2014 14:53:10 +0100 (CET) Received: from [131.160.126.202] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.2.347.0; Wed, 26 Feb 2014 14:53:09 +0100 Message-ID: <530DF1C5.60007@ericsson.com> Date: Wed, 26 Feb 2014 15:53:09 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Cullen Jennings (fluffy)" , Spencer Dawkins References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <530D56F7.5070900@gmail.com> <55FF8505-78C7-483B-B923-368ED01CE37A@cisco.com> In-Reply-To: <55FF8505-78C7-483B-B923-368ED01CE37A@cisco.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM+Jvje6xj7zBBne6ZCwOLb7EatExmc1i xp+JzBbvetayWaz9185u0b30P4vFoXkXGC2WTdnDbNE4187iw9oLbA5cHlN+b2T1aFnVy+yx c9Zddo8lS34yeXzaOp/FY90Hc49Pv14xBrBHcdmkpOZklqUW6dslcGV8vNfBWLCEt+LRy2XM DYz7uLoYOTkkBEwkeo5/YYewxSQu3FvP1sXIxSEkcIhRYsuKK0wQzlpGifNNG9hAqngFNCVW zNrG0sXIwcEioCrxryESJMwmYCGx5dZ9FhBbVCBK4ueVBewQ5YISJ2c+AYuLCKRItH2FmMks 8IpJ4v3sw4wgc4QFiiT6XnBD7JrIKrHoXyfYLk4BW4lvt+czgdRICIhL9DQGgYSZBfQkplxt YYSw5SW2v53DDGILCWhLLH/WwjKBUWgWktWzkLTMQtKygJF5FSN7bmJmTnq54SZGYJwc3PJb dwfjqXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDoXPLyismZuItX w0K2TPveLNzKKc7iF3+7hbP2hMJpab6HmrW39IzE9ztfbF7LO6f0Wt8ynsIbIof5/5vUplTx qV6Ru3ahg/GXy1IPq5tXmd8UHZm1cG3j0U0Zq2yLS4X3Fyj8e3yN65dif59aTm7cnUmCF8SW ystKPPEX0Z6oeWvOJfWVG6WVWIozEg21mIuKEwHrU3HeYQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tram/bziH6J_fJ719y_GgUEU4dDoZpHM X-Mailman-Approved-At: Wed, 26 Feb 2014 05:54:53 -0800 Cc: Simon Perreault , Ted Hardie , "tram@ietf.org" , Magnus Westerlund , Spencer Dawkins , "rtcweb@ietf.org" , IESG IESG , Karl Stahl , Barry Leiba Subject: Re: [tram] BCP over TURN will not be in scope ... and MPLS over UDP over TURN will not be in scope ... and ... X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 13:53:17 -0000 Hi Cullen, I am keeping the cc: as is in order to close this thread but let's try and avoid cross-posting in future discussions. Thanks for your input. I agree that explicit charters are better than implicit ones, especially around areas that can be controversial. Given that we are not going to recharter the WG in the next few days, we are going to focus the session in London on items that are *explicitly* chartered. After London, if we need to tighten the charter somehow, we will do that. Cheers, Gonzalo On 26/02/2014 10:26 AM, Cullen Jennings (fluffy) wrote: > > On Feb 26, 2014, at 10:52 AM, Spencer Dawkins wrote: > >> So ... TRAM was chartered last Thursday ... >> >> I'm gonna let Gonzalo (Yet Another Soon-to-be Former AD Serving as WG Chair) and Simon actually chair their working group for at least a full week before intruding further, but for now, let's assume that the working group wants to work on the milestones they signed up for last week, and see how badly that assumption blows up, rather than talk about rechartering every time someone proposes a topic that's out of scope. >> >> I look forward to attending the first working group session next week, and to balloting on six TRAM drafts before IETF 92. >> >> Thanks, >> >> Spencer, as the responsible AD > > Makes sense - I get the desire to let some work get done. > > I worry that every time someone says something is is not in scope of this WG, it is not going to feel like an open consensus decisions but is instead going to feel like a arbitrary fiat decisions by a chair or IESG made in a dark and smoky room - I hope I am wrong. > > From nobody Wed Feb 26 07:48:17 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076EC1A066E; Wed, 26 Feb 2014 07:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=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 FIILXOMzJZY8; Wed, 26 Feb 2014 07:48:01 -0800 (PST) Received: from smtp.it-norr.com (smtp.it-norr.com [80.244.64.162]) by ietfa.amsl.com (Postfix) with ESMTP id A03741A01EF; Wed, 26 Feb 2014 07:47:59 -0800 (PST) Received: from ([90.229.134.75]) by smtp.it-norr.com (Telecom3 SMTP service) with ASMTP id 201402261647536755; Wed, 26 Feb 2014 16:47:53 +0100 From: "Karl Stahl" To: "'Yoakum, John H \(John\)'" , "'Oleg Moskalenko'" , "'Alan Johnston'" References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> In-Reply-To: <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> Date: Wed, 26 Feb 2014 16:47:50 +0100 Message-ID: <06f801cf330a$1aca7880$505f6980$@stahl@intertex.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06F9_01CF3312.7C8EE080" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPLmMlcJtLqkuUgEmVgUSRCLyaepq+efWAgARzPGA= Content-Language: sv Archived-At: http://mailarchive.ietf.org/arch/msg/tram/E6a6q4Yv6HOvn5JOawuzhIiywkg Cc: rtcweb@ietf.org, tram@ietf.org Subject: [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to inface to lower level's QoS-stuff X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 15:48:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_06F9_01CF3312.7C8EE080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (After having typed this up; I see today=92s charter discussion etc. = that I haven=92t read yet, but it will hopefully will be clearer by pointing at = this entry.) =20 Hi John, and=20 Collin, P=E5l, Magnus, Charles, Simon, =20 In my step A) B) and D) efforts in http://www.ietf.org/mail-archive/web/tram/current/msg00275.html for the =93mission to bring quality to real-time traffic over our best effort = Internet is a huge mission, I am convinced it not a huge task =96 We just have to = be a bit clever here :). I only see these few standard steps required, before = it can happen!=94 =20 To accomplish these (1), (2), (3)-things for: (1) *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP = variants) to quickly allow us to finally enjoy the high quality and connectivity (NAT/firewall traversal) of real-time communication services now = possible, for =20 (2) *all* WebRTC browsers *and* dedicated clients (not using WebRTC), = under *all* OSs, and *all* current and future IP networks=20 (3) *without* having to be forced into application specific networks = (PSTN, IMS) instead of the Internet (including OTT). =20 There are a lot of Mission Impossible, Pointers, Good arguments and = other things to consider in the mails from you guys that I have not (yet) answered. =20 Allow me to come back to those under THIS THREAD/Subject after having figured out how to do it in a structured way, with the aim of collecting = the summary in a new "Interfacing to QoS" thread, that only will relate to = how IP/IETF/WebRTC level 3-5 =96 *can interface* to the QoS-stuff (whether = within IETF, in the telephony world or elsewhere e.g. IEEE Ethernet, mainly relating to lower level). =20 I think this is doable *without* ending up in any of the (i), (ii), (iii)-things=20 (i) will *not allow* ISP=92s to use already available and currently = deployable quality IP pipes for real-time traffic to also be used for WebRTC = generated real-time traffic. (ii) will *not allow* some network types (e.g. Cable Networks and Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive streaming video and file sharing. That all networks *will be inhibited* from the = very common and used method of simply providing an extra IP pipe (often = provided over the same wire but level-2 separated) dedicated for real-time usage (*by resisting TRAM implementation of step B*) *while* newer, fiber only type of networks, still can borrow bandwidth = at no extra cost, *by proprietary usage* of RFC 5285 by browsers.=20 (iii) will leave most ISPs to *only use* raw bandwidth capacity increase that may have to be 10-folded to reach sufficient QoE when WebRTC usage becomes popular (if at all possible, since unmanaged IP pipes = intermittently are filled, whatever bandwidth is available). (?) and possible other Evil -things. =20 I refer to = http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html for these =93-things=94 and further. =20 =20 John, Alan, Henry (Sinnreich), Henning, Richard, Cullen, J=F6rgen = (Bj=F6rkner), Lars (Berggren) and other good friends since the early SIP age (before = SIP was =93hijacked=94 into application specific network and proprietary = usage and nowadays rarely is used the IETF-way):=20 =20 I want to point out how =93confusing=94 the QoS-issue has been and as = hard as I will the fight Mission Impossible attitude, I will also fight the =93it = is all about bandwidth=94 and =93it will go away with time=94 attitude=85 = (also in the above http reference) =20 I agree with parts of what John says below but the remedy to achieve the Good (1), (2), (3)-things instead of the Evil (i), (ii), (iii)-things, = is NOT to ignore QoS-things =96 It is the opposite!=20 =20 For you having more and relevant input =96 That has not been said, and = that you think I will not address anyway =96 in this "Interfacing to QoS" = path, please provide, but I will not be able to process much more than already have been said =96 and I will use http back-pointers for what has = already been discussed in more detail. =20 If you want to point out QoS-stuff Requiring More Input-from/Feedback-to = the level 3 and above stuff IN ADDITION to what already has been discussed = here http://www.ietf.org/mail-archive/web/tram/current/msg00302.html =20 Please also point out WHAT and WHY that can/or cannot be handled by the methods proposed here and whether other existing methods can be used to achieve the mission of "Interfacing to QoS" from IP =3D level 3 to lower levels. =20 I will do some thinking about what LISTs different things shall be = brought to and then split the [TRAM] [WEBRTC] and advice regarding involving = other list will be considered. Such will probably show up and happen during = this mission. =20 =20 Another thing from http://www.ietf.org/mail-archive/web/tram/current/msg00275.html: What = name=20 Footnote **[Karl]* For similar reasons I have started to say things like =93the box containing the TURN server=94. We should not change the TURN = server spec into including specific QoS methods to apply (like reservation, changing DSCP bits or applying traffic shaping mechanism). What is = happening here is that we share the traffic information that the TURN server gets = hold of, with a QoS applying function (that will be different for different networks) in =93the same box=94. With =93the same box=94 I mean that we = for now don=92t care about the interface/commands for sharing information = between the TURN server and the QoS applying function. There may be a future need to specify/standardize this, but if we start doing that now and in TRAM, we risk ending up in a 10-year process before having something in place = (which without a spec automatically will happen in vendor=92s product = development, by putting the TURN server into already available =93QoS applying = function=94 boxes (like firewalls or the mobile DPI/PCRF combination). =20 *What we need to consider and specify, is only what traffic info is = required (to be provided by the application/browser) for =93QoS applying = functions=94 in different networks (including the very common reservation types) to do = job (i.e. giving us good QoE for real-time applications).* =20 And Henry, I will have to continue to use the S(BC)-word and the = I(MS)-word, since you did not succeed to =93eradicate=94 them ;-) Let=92s hope we = find a word for the above box (quite undefined on the QoS-side =96 It is only the = TURN side and traffic info we are up to designing here) that does not need to = be =93eradicated=94. So no WebRTC-SBC I guess (hopefully it will not even = be WebRTC-specific), and ICE-SBC sounds crazy (since ICE was developed to remove the need of SIP SBCs), the same applies to TURN-SBC (which = implies that this box hopefully is not even ICE-specific). TURN-QoS-Interface = box is relevant but long=85=20 =20 /Karl =20 PS: To avoid being stopped by the =93to many recipients=94 spam filter, = the Guys (including Mary) from=20 http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html=20 and the ones mentioned in the email are copied separately. =20 =20 Fr=E5n: Yoakum, John H (John) [mailto:yoakum@avaya.com]=20 Skickat: den 20 februari 2014 19:56 Till: Oleg Moskalenko; Alan Johnston Kopia: Karl Stahl; tram@ietf.org =C4mne: RE: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt +1 I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts. There are other groups doing QOS = work and frankly I engage in WebRTC multimedia interactions daily over the Internet, enterprise VPNs, and various combinations and seldom suffer egregious quality issues. I am more concerned about carriers doing = things to regulate or degrade WebRTC flows than a failure of existing Internet mechanisms to enable them. =20 Significant focus on QOS before we better enable TURN to be easily used = in a browser environment taking advantage or normal web characteristics (as opposed to historic telephony constructs) would seem to be highly distracting at this point. =20 Cheers, John =20 AVAYA 1.919.425.8446=20 =20 From: tram [mailto:tram-bounces@ietf.org] On Behalf Of Oleg Moskalenko Sent: Thursday, February 20, 2014 12:43 PM To: Alan Johnston Cc: Karl Stahl; tram@ietf.org Subject: Re: [tram] Fwd: I-D Action: draft-thomson-tram-turn-bandwidth-00.txt =20 =20 On Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston = wrote: =20 Personally, I am not sure how much QoS is actually in scope for TRAM. = Have you been following RMCAT where congestion avoidance for RTP is being developed? I see some overlap in your goals and the goals of that work. =20 I'd concentrate on the TURN application-level functionality, for now, = and I'd leave QoS for the future discussions. ------=_NextPart_000_06F9_01CF3312.7C8EE080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

(A= fter having typed this up; I see today’s charter discussion etc. = that I haven’t read yet, but it will hopefully will be clearer by = pointing at this entry.)

 

Hi= John, and

Co= llin, P=E5l, Magnus, Charles,=A0 Simon,

 

In= my step A) B) and D) efforts in = http://www.ietf.org/mail-archive/web/tram/current/msg00275.html = fo= r the &#= 8220;mission to bring quality to real-time = traffic over our best effort Internet is a huge mission, I am convinced = it not a huge task – We just have to be a bit clever here :). I = only see these few standard steps required, before it can = happen!&#= 8221;

 

To= accomplish these (1), (2), (3)-things for:

(1= ) = *all* protocols using IETF RTP/SRTP and/or IETF TURN/STU/ICE (in = addition to WebRTC: e.g. SIP, Skype and Facetime, and most VoIP = variants) to quickly allow us to finally enjoy the high quality and = connectivity (NAT/firewall traversal) of real-time communication = services now possible, for  

(2= ) = *all* WebRTC browsers *and* dedicated clients (not using = WebRTC), under *all* OSs, and *all* current and future IP = networks

(3= ) *without* ha= ving to be forced into application specific networks (PSTN, IMS) instead = of the Internet (including OTT).

 

Th= ere are a lot of Mission Impossible, Pointers, Good arguments and other = things to consider in the mails from you guys that I have not (yet) = answered.

 

Al= low me to come back to those under THIS THREAD/Subject after having = figured out how to do it in a structured way, with the aim of collecting = the summary in a new "Interfacing to QoS" thread, that only = will relate to how IP/IETF/WebRTC level 3-5 – *can = interface* to the QoS-stuff (whether within IETF, in the telephony = world or elsewhere e.g. IEEE Ethernet, mainly relating to lower = level).

 

I = think this is doable *without* ending up in any of the = (i= ), = (i= i), = (iii)-t= hings

(i= ) = will *not allow* ISP’s to use already available and = currently deployable quality IP pipes for real-time traffic to also be = used for WebRTC generated real-time traffic.

(i= i) = will *not allow* some network types (e.g. Cable Networks and = Mobile OTT) to borrow bandwidth from data traffic and QoS insensitive = streaming video and file sharing. That all networks *will be = inhibited* from the very common and used method of simply providing = an extra IP pipe (often provided over the same wire but level-2 = separated) dedicated for real-time usage

(<= b>*by resisting TRAM implementation of step = B*)

*<= b>while* newer, fiber only type of networks, still can borrow = bandwidth at no extra cost, *by proprietary usage* of RFC 5285 by = browsers.

(i= ii) = will leave most ISPs to *only use* raw bandwidth capacity = increase that may have to be 10-folded to reach sufficient QoE when = WebRTC usage becomes popular (if at all possible, since unmanaged IP = pipes intermittently are filled, whatever bandwidth is = available).

(?= ) and possible other Evil -things.

 

I = refer to http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html = for these “-things” and further.

 

 

Jo= hn, Alan, Henry (Sinnreich), Henning, Richard, Cullen, J=F6rgen = (Bj=F6rkner), Lars (Berggren) and other good friends since the early SIP = age (before SIP was “hijacked” into application specific = network and proprietary usage and nowadays rarely is used the IETF-way): =

 

I = want to point out how “confusing” the QoS-issue has been and = as hard as I will the fight Mission Impossible attitude, I will also = fight the = “it is all about bandwidth” and “it will go away with = time” = attitude… =A0(also in the above http = reference)

 

I = agree with parts of what John says below but the remedy to achieve the = Good (1), (2), (3)-things instead of the Evil (i= ), = (i= i), = (iii)-t= hings, is NOT to ignore QoS-things – It is the opposite! =

 

Fo= r you having more and relevant input – That has not been said, and = that you think I will not address anyway – in this = "Interfacing to QoS" path, please provide, but I will not be = able to process much more than already have been said – and I will = use http back-pointers for what has already been discussed in more = detail.

 

If= you want to point out QoS-stuff Requiring More Input-from/Feedback-to = the level 3 and above stuff IN ADDITION to what already has been = discussed here = http://www.ietf.org/mail-archive/web/tram/current/msg00302.html = =A0

Pl= ease also point out WHAT and WHY that can/or cannot be handled by the = methods proposed here and whether other existing methods can be used to = achieve the mission of "Interfacing to QoS" from IP =3D level = 3 to lower levels.

 

I = will do some thinking about what LISTs different things shall be brought = to and then split the [TRAM] [WEBRTC] and advice regarding involving = other list will be considered. Such will probably show up and happen = during this mission.

 

 

An= other thing from = http://www.ietf.org/mail-archive/web/tram/current/msg00275.html: = What name 

Footnote =
**[Karl]* For similar reasons I have started to say things like =
“the box containing the TURN server”. We should not change =
the TURN server spec into including specific QoS methods to apply (like =
reservation, changing DSCP bits or applying traffic shaping mechanism). =
What is happening here is that we share the traffic information that the =
TURN server gets hold of, with a QoS applying function (that will be =
different for different networks) in “the same box”. With =
“the same box” I mean that we for now don’t care about =
the interface/commands for sharing information between the TURN server =
and the QoS applying function. There may be a future need to =
specify/standardize this, but if we start doing that now and in TRAM, we =
risk ending up in a 10-year process before having something in place =
(which without a spec automatically will happen in vendor’s =
product development, by putting the TURN server into already available =
“QoS applying function” boxes (like firewalls or the mobile =
DPI/PCRF combination).
 
*What =
we need to consider and specify, is only what traffic info is required =
(to be provided by the application/browser) for “QoS applying =
functions” in different networks (including the very common =
reservation types) to do job (i.e. giving us good QoE for real-time =
applications).*

 

An= d Henry, I will have to continue to use the S(BC)-word and the = I(MS)-word, since you did not succeed to “eradicate” them = ;-) =A0Let’s hope we find a word for the above box (quite = undefined on the QoS-side – It is only the TURN side and traffic = info we are up to designing here) that does not need to be = “eradicated”. So no WebRTC-SBC I guess (hopefully it will = not even be WebRTC-specific), and ICE-SBC sounds crazy (since ICE was = developed to remove the need of SIP SBCs), the same applies to TURN-SBC = (which implies that this box hopefully is not even ICE-specific). = TURN-QoS-Interface box is relevant but long… =

 

/K= arl

 

PS= : To avoid being stopped by the “to many recipients” spam = filter, the Guys (including Mary) from

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11548.html =

an= d the ones mentioned in the email are copied = separately.

 

 

Fr=E5n: Yoakum, = John H (John) [mailto:yoakum@avaya.com]
Skickat: den 20 = februari 2014 19:56
Till: Oleg Moskalenko; Alan = Johnston
Kopia: Karl Stahl; tram@ietf.org
=C4mne: = RE: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

+1

I fully agree with the comments that QOS should be a low priority for = the initial focus of the TRAM efforts.  There are other groups = doing QOS work and frankly I engage in WebRTC multimedia interactions = daily over the Internet, enterprise VPNs, and various combinations and = seldom suffer egregious quality issues.  I am more concerned about = carriers doing things to regulate or degrade WebRTC flows than a failure = of existing Internet mechanisms to enable them.

 

Significant focus on QOS before we better enable TURN to be easily = used in a browser environment taking advantage or normal web = characteristics (as opposed to historic telephony constructs) would seem = to be highly distracting at this point.

 

Ch= eers,

Jo= hn

 

AVAY= A
1.9= 19.425.8446

 

From:= tram [mailto:tram-bounces@ietf.org] = On Behalf Of Oleg Moskalenko
Sent: Thursday, February = 20, 2014 12:43 PM
To: Alan Johnston
Cc: Karl Stahl; = tram@ietf.org
Subject: = Re: [tram] Fwd: I-D Action: = draft-thomson-tram-turn-bandwidth-00.txt

<= div>

 

 

On = Thu, Feb 20, 2014 at 6:26 AM, Alan Johnston <alan.b.johnston@gmail.com> = wrote:

 

Personally, I am not sure how much = QoS is actually in scope for TRAM. Have you been following RMCAT where = congestion avoidance for RTP is being developed?  I see some = overlap in your goals and the goals of that = work.

 

I'd concentrate on the = TURN application-level functionality, for now, and I'd leave QoS for the = future discussions.

------=_NextPart_000_06F9_01CF3312.7C8EE080-- From nobody Wed Feb 26 08:02:15 2014 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CF21A066E for ; Wed, 26 Feb 2014 08:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham 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 qbYbdc9bl8rf for ; Wed, 26 Feb 2014 08:02:07 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC541A0454 for ; Wed, 26 Feb 2014 08:02:07 -0800 (PST) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:b419:c7ff:fe35:ac8e]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EF88C46909; Wed, 26 Feb 2014 11:02:05 -0500 (EST) Message-ID: <530E0FFD.6060307@viagenie.ca> Date: Wed, 26 Feb 2014 11:02:05 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Karl Stahl References: <20140214030712.30321.21888.idtracker@ietfa.amsl.com> <530604ea.c5bf440a.5cfd.ffffde18SMTPIN_ADDED_BROKEN@mx.google.com> <93BEDDC39A54294B9E78C7860516FA4724AA4422@AZ-US1EXMB06.global.avaya.com> <06f801cf330a$1aca7880$505f6980$@stahl@intertex.se> In-Reply-To: <06f801cf330a$1aca7880$505f6980$@stahl@intertex.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tram/OeX0PjpxCOxCMP33TDRK5S0zAl0 Cc: tram@ietf.org Subject: Re: [tram] [rtcweb] The way to "Interfacing to QoS", A level 3-5 IP/IETF/WebRTC-thing how to inface to lower level's QoS-stuff X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 16:02:12 -0000 Karl, It has been made clear that QoS discussion is out of scope for TRAM. This thread has ended. If you continue posting on this topic, we will have to take reactive measures. Please also refrain from cross-posting to multiple lists. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca