From gonzalo.camarillo@ericsson.com Fri May 1 13:06:41 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257C63A6D48 for ; Fri, 1 May 2009 13:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.386 X-Spam-Level: X-Spam-Status: No, score=-5.386 tagged_above=-999 required=5 tests=[AWL=0.863, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxBgk8T+y0ZX for ; Fri, 1 May 2009 13:06:39 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 43DC728C1FE for ; Fri, 1 May 2009 13:06:30 -0700 (PDT) X-AuditID: c1b4fb3c-b7b19ae000006089-94-49fb569859df Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 1B.C5.24713.8965BF94; Fri, 1 May 2009 22:07:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 22:07:39 +0200 Received: from [131.160.126.150] ([131.160.126.150]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 May 2009 22:07:39 +0200 Message-ID: <49FB568B.8040608@ericsson.com> Date: Fri, 01 May 2009 23:07:39 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Geir Arne Sandbakken References: <49DD8DED.3010908@ericsson.com> <49E74FBA.6080600@tandberg.com> In-Reply-To: <49E74FBA.6080600@tandberg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 May 2009 20:07:39.0603 (UTC) FILETIME=[7A833A30:01C9CA98] X-Brightmail-Tracker: AAAAAA== Cc: XCON , xcon-chairs@tools.ietf.org Subject: Re: [XCON] BFCP over UDP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 20:06:41 -0000 Hi, OK, we can do a bis then. I will coordinate this effort together with the authors of the draft below. Cheers, Gonzalo Geir Arne Sandbakken wrote: > Gonzalo, > > The UDP usage draft does utilize transaction ids more and has a few > extra messages to get reliable delivery. The changes are still very > minor to the protocol itself and our implementation of it. > IMHO having a single way of operating the protocol is better than having > two different modes of operation. Also as mentioned in San Francisco it > makes any intermediaries easier to implement only having to forward > messages independent of transport. Can we do a bis? > > Geir Arne > > Gonzalo Camarillo wrote: >> Hi, >> >> the following (expired) draft was presented in the XCON session in San >> Francisco: >> >> http://www.watersprings.org/pub/id/draft-sandbakken-xcon-bfcp-udp-00.txt >> >> The agreement was that given the problems TCP has with NATs (the >> P2PSIP WG is currently discussing the same issue) it would be a good >> idea to define a more NAT-friendly transport for BFCP. The proposal >> was to simply use UDP (this is what existing deployments do). >> >> Since BFCP messages can be rather long, we would need an applicability >> statement saying which types of messages cannot be used over UDP. >> >> In order to specify the new UDP-based transport we can either put >> together a new draft or revise the BFCP specification. I got the >> action point to list the things that could be fixed in a potential >> revised BFCP spec. These are the contents of my notes. Of course, if >> someone knows of more issues, please let us know: >> >> o When a user performs a third-party floor request the beneficiary of >> the floor is not informed when the floor is granted. This may not be a >> problem because endpoints using third-party floor requests probably >> have different means to get in synch but we may want to add some text >> about this. >> >> o We do not have errors for an unsupported version of the protocol or >> for wrong message length. We do not have a general error either. >> >> o When we get more experience on queue management from real >> deployments, it would be nice to explaining it further in the spec. >> >> o UserStatus >> >> UserStatus = (COMMON-HEADER) >> [BENEFICIARY-INFORMATION] >> 1*(FLOOR-REQUEST-INFORMATION) -> remove the 1 >> *[EXTENSION-ATTRIBUTE] >> >> o A message may need to be longer than the maximum message length >> supported by the protocol >> >> o A rather small number of typos >> >> >> As you can see, at this point there are not so many things to fix... >> so, the simplest way forward may be to simply specify a new UDP-based >> transport for BFCP. In any case, I would like to get feedback from >> folks operating BFCP deployments. >> >> A different alternative (the one the P2PSIP WG is looking at) would be >> to either use a UDP encapsulation for TCP or to specify a new >> transport protocol... but these alternatives may be more complex than >> just using UDP. >> >> Comments? >> >> Thanks, >> >> Gonzalo > From jo@netlab.tkk.fi Mon May 18 22:16:19 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7142E3A6E8A for ; Mon, 18 May 2009 22:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZouDa5AhafuT for ; Mon, 18 May 2009 22:16:16 -0700 (PDT) Received: from smtp.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by core3.amsl.com (Postfix) with ESMTP id AD54A3A708A for ; Mon, 18 May 2009 22:15:54 -0700 (PDT) Received: from pc89.netlab.hut.fi (keskus.netlab.hut.fi [130.233.154.176]) by smtp.netlab.hut.fi (Postfix) with ESMTP id 52A35C5101; Tue, 19 May 2009 08:17:24 +0300 (EET DST) Message-ID: <4A1240DC.1070705@netlab.tkk.fi> Date: Tue, 19 May 2009 08:17:16 +0300 From: Joerg Ott User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Gonzalo Camarillo References: <49DD8DED.3010908@ericsson.com> <49E74FBA.6080600@tandberg.com> <49FB568B.8040608@ericsson.com> In-Reply-To: <49FB568B.8040608@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: XCON , xcon-chairs@tools.ietf.org Subject: Re: [XCON] BFCP over UDP X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2009 05:16:19 -0000 Hi, being a co-author of the BFCP spec, I am not really comfortable with this at this point. As I mentioned in a private note before, the draft to date appears to be ignoring some of the potential dangerous issues. UDP was (intended to be) deprecated for SIP for good reasons. Even for BFCP, it brings up quite a few issues of congestion control and security. These critical aspects are not yet mentioned in the draft. The security considerations are empty! I cannot believe that we seriously want to discuss about the textual integration into the main spec if we haven't understood/sorted out these details. Will the proposal MANDATE the use of ICE and STUN to help against attacks? Will it MANDATE DTLS? Will it deal with congestion control? How will this be done? All this could *really* make me nervous. As a WG chair of a MMUSIC I have seen how little interest there may be in certain aspects, so I would not take silence as consent here. I suggest that the authors go ahead to to figure out all the issues in their individual contribution and solve them and, once there is a promise that this can go well, ask for integration with the BFCP spec. This may all go very well, but I would not accept to create perceived facts _before_ it is clear that the approach is a workable one. The current suggestion seems to be taking two steps at once. Cheers, Joerg Gonzalo Camarillo wrote: > Hi, > > OK, we can do a bis then. I will coordinate this effort together with > the authors of the draft below. > > Cheers, > > Gonzalo > > Geir Arne Sandbakken wrote: >> Gonzalo, >> >> The UDP usage draft does utilize transaction ids more and has a few >> extra messages to get reliable delivery. The changes are still very >> minor to the protocol itself and our implementation of it. >> IMHO having a single way of operating the protocol is better than >> having two different modes of operation. Also as mentioned in San >> Francisco it makes any intermediaries easier to implement only having >> to forward messages independent of transport. Can we do a bis? >> >> Geir Arne >> >> Gonzalo Camarillo wrote: >>> Hi, >>> >>> the following (expired) draft was presented in the XCON session in >>> San Francisco: >>> >>> http://www.watersprings.org/pub/id/draft-sandbakken-xcon-bfcp-udp-00.txt >>> >>> The agreement was that given the problems TCP has with NATs (the >>> P2PSIP WG is currently discussing the same issue) it would be a good >>> idea to define a more NAT-friendly transport for BFCP. The proposal >>> was to simply use UDP (this is what existing deployments do). >>> >>> Since BFCP messages can be rather long, we would need an >>> applicability statement saying which types of messages cannot be used >>> over UDP. >>> >>> In order to specify the new UDP-based transport we can either put >>> together a new draft or revise the BFCP specification. I got the >>> action point to list the things that could be fixed in a potential >>> revised BFCP spec. These are the contents of my notes. Of course, if >>> someone knows of more issues, please let us know: >>> >>> o When a user performs a third-party floor request the beneficiary of >>> the floor is not informed when the floor is granted. This may not be >>> a problem because endpoints using third-party floor requests probably >>> have different means to get in synch but we may want to add some text >>> about this. >>> >>> o We do not have errors for an unsupported version of the protocol or >>> for wrong message length. We do not have a general error either. >>> >>> o When we get more experience on queue management from real >>> deployments, it would be nice to explaining it further in the spec. >>> >>> o UserStatus >>> >>> UserStatus = (COMMON-HEADER) >>> [BENEFICIARY-INFORMATION] >>> 1*(FLOOR-REQUEST-INFORMATION) -> remove the 1 >>> *[EXTENSION-ATTRIBUTE] >>> >>> o A message may need to be longer than the maximum message length >>> supported by the protocol >>> >>> o A rather small number of typos >>> >>> >>> As you can see, at this point there are not so many things to fix... >>> so, the simplest way forward may be to simply specify a new UDP-based >>> transport for BFCP. In any case, I would like to get feedback from >>> folks operating BFCP deployments. >>> >>> A different alternative (the one the P2PSIP WG is looking at) would >>> be to either use a UDP encapsulation for TCP or to specify a new >>> transport protocol... but these alternatives may be more complex than >>> just using UDP. >>> >>> Comments? >>> >>> Thanks, >>> >>> Gonzalo >> > > _______________________________________________ > XCON mailing list > XCON@ietf.org > https://www.ietf.org/mailman/listinfo/xcon > From enrico.marocco@telecomitalia.it Fri May 22 00:58:59 2009 Return-Path: X-Original-To: xcon@core3.amsl.com Delivered-To: xcon@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63263A6929; Fri, 22 May 2009 00:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.529 X-Spam-Level: X-Spam-Status: No, score=-0.529 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49sZZANQ0MSK; Fri, 22 May 2009 00:58:58 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by core3.amsl.com (Postfix) with ESMTP id 1323D3A68AA; Fri, 22 May 2009 00:58:55 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 22 May 2009 10:00:29 +0200 Received: from [10.229.8.41] (10.229.8.41) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Fri, 22 May 2009 10:00:28 +0200 Message-ID: <4A165B9F.3020902@telecomitalia.it> Date: Fri, 22 May 2009 10:00:31 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: , X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080301080508080709070102" Subject: [XCON] [Fwd: [dispatch] Yet another problem to dispatch] X-BeenThere: xcon@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Centralized Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2009 07:58:59 -0000 --------------ms080301080508080709070102 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Hi, we have just submitted a problem statement whose solution space probably falls somewhere within the scope of AVT and XCON WGs. Any comments, possibly on the dispatch list, will be extremely appreciated. Enrico -------- Original Message -------- Subject: [dispatch] Yet another problem to dispatch Date: Fri, 22 May 2009 00:45:51 +0200 From: Emil Ivov To: dispatch@ietf.org , Marocco Enrico Hey folks, We have been working on client side conference calls for SIP Communicator lately and were thinking about implementing participant sound level indicators. The feature was inspired by Skype's Mac OS X GUI which you can have a look at over here: http://sip-communicator.org/skypeconf/skypeconf.png Since we couldn't find an existing IETF mechanism for a mixer to dispatch information on sound level to conference participants, Enrico and I thought that this may be an issue that is worth addressing through dispatch. After talking to some of you privately and discussing it among ourselves we have decided to come up with a document presenting the issue in some more detail. We are also including short descriptions of what we consider to be possible approaches for resolving it. http://www.ietf.org/internet-drafts/draft-ivov-dispatch-slic-ps-00.txt Comments are most welcome, as well as any show of interest or indications of what you think would be the right place(s) to work on the subject. Thanks, Emil --------------ms080301080508080709070102 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA1MjIwODAwMzFaMCMG CSqGSIb3DQEJBDEWBBTw7R1AoUmozq2ps6AnjysoDeLdGDBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAB3p1tSf0d1j J61YIQr+G5oiAKybdC0Jis3UYfVV9AxDjT6YlKefSBH883EaTPEl+ZgmfEDNzv2Q8bUrmABH A99Z8HR6sHNqkajLW/oqPNFMVbATLrvJn12rv8nCR0GVulMbdqmEvSFocm/cv8NneGSzalGI srTAjr4R+DZuCV919ZA2Lvf+Hw4yYsFvxmU8659qDsTKUhmHN4GUnrFrZLSOLrtc97CY0jSZ wmHiq8K651uSN9JwI3YAfYdWQdRL0DUzvhREIehITzTMZRxj3xLwxZhOSFWthsSet/WgkERV y0mMGCAEdteZf+SAf9vh3L+rcZ043MNSiWfsum0T49kAAAAAAAA= --------------ms080301080508080709070102--